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.