Re: [Discuss-gnuradio] Audio latency keeps increasing

[Kevin Reid]

On Sun, Mar 12, 2017 at 11:32 AM, Phil Frost <address@hidden> wrote:

I'm prototyping some software which uses a PulseAudio sink/source pair which I wrote[1]. Even doing something as simple as having the audio source go into a GUI sink and the audio sink, I'm having an issue where as the program runs longer, the latency gets higher. Running for a day the latency will grow to many seconds. This causes issues for the external program generating and receiving the baseband signal, which is unaware of this latency.

I best guess of what's going on is this: the source block is connected to a PulseAudio monitor device. I do this so the audio output of other applications I'm running can be routed into GnuRadio's input. The same audio device is associated with the sink and source, so the clocks are normally synchronized. But as those other applications open and close the audio device, gaps are introduced into the monitor device, requiring GnuRadio's buffers to grow as the clock (temporarily) drift apart.

Sounds plausible from the GNU Radio side of things.

 

So two questions:

1) Is there a way I can inspect the buffer sizes within GnuRadio to confirm my hypothesis?

My understanding is that the Performance Counters feature allows you to do that, but I have not yet seen it in operation myself.

2) Assuming that's what's going on, is there an adjustment I can make (perhaps to the flow graph, or to the PulseAudio blocks) to drop samples instead of buffering?

Modify your sink block's work function to invoke pulseaudio in a non-blocking fashion, and drop the samples if they cannot be immediately written. This is how gr::audio::sink works when the ok_to_block parameter is false.