Interesting point, Marcus. I'll post the complete flowgraph tomorrow when I am at my development machine. I did revert the audio rate out of the demod to 15ksps and that helped somewhat. So maybe that can go further.
On May 23, 2017, 7:18 PM, at 7:18 PM, "Marcus Müller" <marcus.muel...@ettus.com> wrote: >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 <j...@febo.com >>> <mailto:j...@febo.com>> 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >_______________________________________________ >Discuss-gnuradio mailing list >Discuss-gnuradio@gnu.org >https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
