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

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 <jra@febo.com
> <mailto:jra@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