discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Audio Sink Buffer


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Audio Sink Buffer
Date: Sat, 5 Dec 2015 10:12:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Hi Kyle,

the GNU Radio audio sink doesn't throw anything away.
Technically, it just uses ALSA to send the audio samples to the specified (or default) sound card. It simply scales the input items, puts them into an internal buffer (d_buffer)[1], and instructs ALSA to write that buffer to the sound card [2]; nothing magical here.

With PulseAudio, that soundcard usually is an emulated sound card, meant to make ALSA applications use pulse rather than directly sending audio to the sound card. So that'd be my focus when seeing such audio oddities. In fact, virtual consoles + pulse kind of ring my alarm bells: On most distributions (aka any I can think of), pulse gets started only when the user logs in to a graphical session (e.g. GNOME, KDE, Xfce, Mate...), and not when logging into a virtual console. I hence conclude that you're running such a graphical UI when you are starting a flow graph, which means Pulse should be there and ready to accept samples. The fact that switching out of and back into your session helps indicates that kicking Pulse out of and back into operation is the key; which probably means this is a pulse-internal issue, or even a sound card hardware issue.

My approach here:
  1. run "aplay -L" to find the name of the physical rather than the emulated Pulse hardware, and try with that name instead of empty or "default" in the audio sink. If that helps -> Pulse is to blame.
  2. Both Pulse and ALSA do internal resampling, and they do that to varying degrees of helpfulness. What sampling rate is your Flow Graph using? Can you get a better result if using a rational resampler that resamples from that rate to another typical audio rate, i.e. 44100 Hz or 48000 Hz?
  3. Maybe the sound card, the USB audio driver or Pulse have problems initializing the USB card just in time. Does it help to (when using pulse) play an audio stream in the background (e.g. make a second flow graph that starts first and streams 0s to the audio sink)?

Hope we can get this out of the world,

Best regards,
Marcus



[1] https://github.com/gnuradio/gnuradio/blob/master/gr-audio/lib/alsa/alsa_sink.cc#L350
[2] https://github.com/gnuradio/gnuradio/blob/master/gr-audio/lib/alsa/alsa_sink.cc#L494
On 03.12.2015 22:08, Kyle Chapman wrote:
Hi,

I’m having trouble getting the audio sink to work well with pulseaudio and a USB soundcard.  It seems the gnuradio audio sink throws the packet away before the usb card has a chance to become ready. This results in a race condition and a stuttering output with audio underruns.  Switching virtual consoles from one to the other using ctrl+alt+fkey allows the program to function normally, as long as the stream is not interrupted.  Making the buffer values accessable should fix this issue.

Other users have reported similar issues in #gnuradio

Thank you.
-- 

Kyle Chapman
Undergraduate Student of German Studies
University of New Mexico
address@hidden
1-505-884-6861


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

[Prev in Thread] Current Thread [Next in Thread]