On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR <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
