[alsa-devel] How does usbaudio synchronize on playback?

[John Crowley]

Thanks for the quick reply ... I've been digging through the code some more.
Sorry for the excessive length of this response ....

Some additional questions, comments, and tests below, and this is a
completely new area for me, so sorry if I'm being especially obtuse.

Let me know if anyone can point to some documentation or books that I can
reference to get into this area.

Regards to all,

John Crowley
ScreenPC, Inc.
101 Merritt 7, 5th Fl
Norwalk, CT  06851
Office:  203.842.0460 ext 602
Cell:      203.856.2396

This message and any accompanying attachments contains information from
ScreenPC,Inc. that is confidential and/or privileged. The information is
intended to be for the use of the individual or entity named above. If you
are not the intended recipient, be aware that any disclosure, copying,
distribution or use of the contents of this information is prohibited. If
you have received this email in error, please notify the sender immediately
by reply email and destroy all copies of the original email.

 

> -----Original Message-----
> From: Clemens Ladisch [mailto:clemens at ladisch.de] 
> Sent: Friday, November 14, 2008 3:34 AM
> To: John Crowley
> Cc: alsa-devel at alsa-project.org
> Subject: Re: [alsa-devel] How does usbaudio synchronize on playback?
> 
> John Crowley wrote:
> > [...]
> > What I don't understand is how does prepare_playback_urb 
> ensure that 
> > more playback data has actually been written into the buffer?
> 
> It doesn't; the ALSA framework does.
> 
> When the driver calls snd_pcm_period_elapsed(), ALSA calls 
> the .pointer callback and checks if an underrun has happened. 
>  Underrun detection works this way because most sound card 
> hardware reads the data out of the buffer asynchronously.
> 
QUESTION:  Understand about the .pointer callback, and from printk traces
that seems to be functioning as expected.

I dug several layers into snd_pcm_period_elapsed(), and it eventually does a
wake_up() on what I presume is the producer application so that it can write
some more data into the ring buffer.

But I still have the original problem -- How to tell when the data has
actually been written into the buffer?

As I understand it, the wake_up() will just allow the application process to
become runnable again, but (especially on a heavily loaded machine) it may
not be scheduled immediately.  Also, even if it is executed synchronously,
how can you tell how much data has been written into the buffer?  Will it
always write 1 period, 1 milli-second, ???

I put a printk on runtime->control->appl_ptr (which I had hoped to use to
address this problem), but using speaker-test this never changed from zero.
Using Firefox to stream music, it was being updated.  Any idea of what's
happening here?  If appl_ptr was updated consistently, this whole issue
would be resolved.

Also, how does the application itself know where to write the next series of
frames if appl_ptr was not updated?  I'm assuming that the application is
maintaining it's own counters.

> > The problem is that we are getting erroneous data, and 
> suspect that it 
> > is caused by this synchronization issue. When the initial 
> no-data URBs 
> > are completed, the prepare_playback_urb logic copies a lot of data 
> > from the buffer into new URBs
> 
> The initial URBs should complete one by one, not all at once 
> (this is the only reason why the driver uses these initial 
> URBs in the first place).
> 

CONTEXT:  This is probably the nub of the problem -- we have a very
different situation.

If there is a real USB device attached, the data will stream out of the
buffer at a relatively slow rate -- some number of frames per milli-second
in the case of regular speakers.  In this situation, waking up the producer
to write some more data to the buffer has plenty of time to occur.

But we are using USBIP to stream audio data to a device across a network.
The actual device has some buffer space, so we put in a deep queueing
mechanism to have a lot of URBs on-the-fly, and let the terminal device
buffer a few seconds worth (and feed that out to the physical USB device at
the appropriate rate).  This smooths over any network glitches, and when the
buffer at the client is filled, it simply does not Confirm receipt of the
last URB until it has space available to start accepting more data.

TEST CASES:

a) if we setup just 2 URBs, everything works OK.

b) if we setup 16 URBs (32 packets per URB), the sound is totally garbled.
Clearly some packets are out of order, some are duplicated.

c) if we setup 16 URBs (32 packets per) and put an msleep(6) at the end of
the prepare_playback_urb then the sound is perfect again.

THEORY:

With just 2 URBs in use, there is enough natural delay in the round-trip
time that the application has plenty of time to write new data into the
buffer before prepare_playback_urb tries to use it.  In (b) the
synchronization problem shows up -- we're pulling data from areas of the
buffer which have not yet been re-populated by the producing application.

Case (c) just introduces an artificial delay into the process.  A setting of
6 ms is totally arbitrary -- other values may also work.

But this is not really a clean or reliable solution.  I'd much, much rather
have a solid synchronization between the producer and consumer to handle
this.  (A reliably updated appl_ptr would be perfect.)

> > but apparently no playback data has been written into the 
> buffer yet 
> > by the application.
> 
> This should result in an underrun and the stream being 
> stopped, except if your application has disabled this behaviour.
> 

COMMENT:  I suspect that to ALSA, all looks OK.  But with a lot of URBs in
process, several can complete in rapid sequence and in this case we have
tried to pull data from the buffer before it was actually written by the
application.