Re: [Discuss-gnuradio] Mixing multiple streams to audio

[Marcus Müller]

Hi John,

3 to 5 seconds doesn't sound all that much considering that you're doing
stuff at a nominal 7.5 kS/s – compare [1]; the typical buffer size
between two blocks is 8 kB, and with floats (i.e. 32 b = 4 B), that's
2000 S, and at 7.5 kS/s, that's 2/7.5 s = 0.26667 seconds for the
buffers between NBFM demod and add, and between add and resampler. In
fact, NBFM demod internally is a hier block (might have more low-rate
buffers); so, that's half a second for these two buffers alone...

In your very specific use case, using a higher sampling rate might make
the problem more manageable. If you'd share the first half of your flow
graph, we could discuss options for that!

Best regards,

Marcus

[1] http://gnuradio.org/blog/buffers


On 23.05.2017 22:04, John Ackermann N8UR wrote:
> Hi Marcus and Kevin, and thanks for the info.
>
> I've set all squelch gates off.  In that case, I get good audio if "OK
> to block" in the audio sink is set to "yes" but the latency is awful
> -- 3 to 5 seconds!  If "OK to block" is "no", then I get lots of aU
> and unusable audio.
>
> If setting the squelch gates off means that samples are continuously
> sent through the adder to the sink, I don't understand why blocking
> makes the difference, or why the latency builds up so fast.  I'd try
> using 44.1ksps on the sink, but the dropdown doesn't allow that choice.
>
> John
> ----
> On 05/23/2017 02:51 PM, Kevin Reid wrote:
>> On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>>     I'm continuing to work on a multi-channel NBFM receiver using the
>>     polyphase filter.  I have the basic system working, but am hung up
>>     on how to get audio out of the system; most of my attempts end up
>>     either with audio underruns, or stalls that result in overruns.
>>
>>
>> You're using only one RF source hardware device, correct?
>>
>> Even then, /some/ amount of overrun/underrun is inevitable because the
>> RF receiver and the audio output are not using the same clock
>> oscillator, so the resampling rate you've implemented is not the
>> resampling rate you would ideally need (which there is no way in GR to
>> actually detect or implement).
>>
>>
>>     The relevant portion of the flowgraph is attached.  Each channel
>>     ends up at a 15ksps rate and is fed into a power squelch, then a
>>     mult block that's used to mute or unmute the audio, then NBFM
>>     demod.  The demodulated outputs are at 7.5ksps (though I get the
>>     same results with 15ksps) and the seven channels are added.  Then a
>>     rational resample to 48ksps, volume control, and audio sink at
>> 48ksps.
>>
>>     I've tried the "gate" param of the power squelch block both off and
>>     on, and the "OK to block" option of the audio sink in various
>>     combinations, but I'm not able to get clean audio.
>>
>>
>> "Gate" should be off. What that option does is drop samples. The problem
>> is that the Add block requires samples from every input to produce an
>> output, so if any one of the inputs drops samples then eventually your
>> flowgraph will not be able to make progress because some buffers are
>> overfull and some are empty.
>>
>> Any flowgraph that has paths that split (here, polyphase channelizer)
>> and rejoin (here, add) MUST have exactly the same
>> input-samples-to-output-samples ratio on all of the paths, or it will
>> eventually lock up.
>>
>> "OK to block" does not do very much, but in this type of application it
>> should be off. This means that if there is an overrun, the audio sink
>> will discard samples rather than the internal buffers filling up and
>> causing the RF source block to have to discard them instead; while this
>> is very similar in principle, it means a higher input-to-output latency.
>> The time to use "OK to block" is when your source has no clock (e.g. it
>> is a file or an internal signal source of some sort) so the audio sink
>> has to be responsible for deciding when it's time to take more samples.
>>
>>
>>     I'd appreciate any suggestions.  One thing I wonder about is the
>>     placement of the blocks in the stream; would a different order work
>>     better?
>>
>>
>> The ordering should not matter (as long as it is not incorrect in some
>> other way, of course).
>>
>>
>> When you have "Gate" off, which type of misbehavior do you get?
>>
>> Have you confirmed that your sound card/driver actually supports 48 kHz?
>> What happens if you try a different sample rate?
>>
>> Have you tried resampling to a rate slightly under or over 48 kHz, as
>> appropriate? That will help if you actually have a severe clock skew
>> problem.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio