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