Re: [Discuss-gnuradio] Distorted playback of real-time audio on Linux

[Eric Blossom]

On Fri, Aug 13, 2010 at 03:47:12AM +0400, Elvis Dowson wrote:
> Hi Eric,
>                I came across an old thread, 
> http://www.ruby-forum.com/topic/107228
> 
> "There is a general issue related to the fact that when using
> usrp_wfm_rcv and similar applications that there are in fact two clock
> domains, and that they are guaranteed not to match.  There's an osc on
> the USRP and an osc associated with the sound card.  We made an API
> change in the audio interfaces that can specify that it's NOT OK to
> block when accessing the audio interface.  When used in a flow graph 
> that contained both an audio sink or source and a USRP sink or source, this
> would result in the USRP being the master clock, and would dodge the
> "two clocks" problem.  Although the parameter was added to all (most)
> audio interfaces, I believe that it currently only works on the
> portaudio interface.  Please feel free to fix this for gr-audio-alsa,
> gr-audio-oss and gr-audio-osx."

> This could potentially explain the issue I have, with distorted and
> crackling audio. It might also explain the nearly un-reproduceable
> random behaviour when it sometimes works giving clear audio output
> (so far has happened only 4 times in 6 weeks, approx 16 hours a
> day).

> How would one go about fixing this for gr-audio-alsa? Perhaps if you
> can give me some high level tips and pointers, I could try to make
> the changes.

Thanks for being willing to take a look at this!

First off, you'd need to read the docs on ALSA and understand the
interfaces that are available to work with.

I think that fixing it in audio_alsa_sink should be enough.  Once the
sink is working you could go after the source if you like.
Given the interfaces exported by ALSA, you'd need to figure out how to
honor the condition "ok_to_block == False".

There are two cases.  

  (1) audio clock is slower than usrp clock
  (2) audio clock is faster than usrp clock

In (1) you'll want to avoid an ever growing queue of samples by
somehow giving the driver samples when it wants them, but dropping the
excess samples (hopefull in a way that nobody notices) every now and
then.

In (2) you'll need to insert an extra sample every now and then to keep
the audio from underruning.

It's been a long while since I looked at the ALSA docs, but there
may be some kind of callback that you can arrange for the ALSA code
to call when it needs (or provides) samples.  Right now we just
naively block when reading or writing.

You may want to look at audio_portaudio_sink.  It's got at least
partial support for this feature, although the interface to the driver
will be different than ALSA.

Eric