On Sun, Mar 12, 2017 at 11:32 AM, Phil Frost <ind...@bitglue.com> 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.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
