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

[Eric Blossom]

On Sat, Aug 14, 2010 at 03:16:38AM +0400, Elvis Dowson wrote:
> Hi Eric,
> 
> On Aug 13, 2010, at 8:38 PM, Eric Blossom wrote:
> 
> > Given the interfaces exported by ALSA, you'd need to figure out how to
> > honor the condition "ok_to_block == False".
> 
> Could you please tell me the intent behind the ok_to_block flag? 

The name could be improved, but when "ok_to_block == False", the
interpretation should be that the GR interface to the audio subsystem
should attempt to rate match the data being consumed or produced by
the GR flow graph to the rate that the audio subsystem wants it.

> By blocking, do you mean a synchronous call, which will block and
> render the subsystem un-responsive, until, it completes?

Yes.  You should think of "ok_to_block == True" means that the audio
device is effectively setting the absolute (real-time) sample rate of
the graph.  This only makes sense when there is no other source or
sink that is also attempting to set the absolute (real-time) sample
rate.  Thus the problem shows up with flow graphs that contain either
a USRP source and a audio sink or an audio source and a USRP sink.
(It doesn't have to be a USRP --- any other i/o device that's tied to
a sample rate clock will show the problem.)

Note also that depending on which clock is faster rate matching requires
either dropping or adding samples on average.

> In this scenario, should the two subsystems be running
> asynchronously, with a buffer in between, so that the two can run at
> different clock rates? e.g. USRP2 running at a particular clock
> rate, and the alsa_audio_sink running at a different clock rate?

Yes.

The relative rates may be mismatched by less than 0.1%.  Even at that
level, on the average you'd need to be adding or dropping 1 sample
every 1000 to match the rates between the two clock domains.

> Or is the whole GNU Radio flow-graph a synchronous system, i.e. it
> completes execution and evaluation of the entire flow graph, every
> clock cycle, reading data from the environment, processing the
> inputs, and computing the output, for every clock cycle?

No, it doesn't work that way.  It buffers a certain amount of data
between blocks before running them.  

Elvis, do you understand the high level source of the problem?
That is, that there are two hardware devices whose clocks are not
synchronized?

Eric