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

John Crowley jcrowley at screenpc.com
Thu Nov 13 17:10:56 CET 2008


All:

How is the playback data in usbaudio.c synchronized between the application
writing data to the runtime->dma_area buffer and the prepare_playback_urb
function copying this into URBs? 
 
To start, a series of no-data URBs are sent out. The completion routine for
each URB then calls prepare_playback_urb, which copies more data into the
URB, and this URB is then passed to the USB system to be sent to the device.

 
prepare_playback_urb copies data from the runtime->dma_area to the
urb->transfer_buffer area. It maintains subs->hwptr_done to record what data
has been copied, and wraps at runtime->buffer_size since this is a circular
buffer. It also recognizes when runtime->period_size has been exceeded and
invokes snd_pcm_period_elapsed to tell the application that more playback
data is needed. 
 
What I don't understand is how does prepare_playback_urb ensure that more
playback data has actually been written into the buffer? 
 
In our case, we are streaming audio over a WAN, so we increased the number
of URBs to 16, with up to 32 packets per URB, to get a lot of data going
on-the-fly over a high latency link.  
 
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 -- but apparently no playback data has been written
into the buffer yet by the application. If we insert logic to arbitrarily
slow down the prepare_playback_urb logic, then the data appears to be
correct. But this is a (very) weak solution. 
 
We also tried to save the runtime->control->appl_ptr value in order to
calculate how much new application data is available, but discovered that
appl_ptr is evidently not being updated (always zero). (running 2.6.23
kernel). 
 
Are we missing a key concept? Is there a way to reliably determine how much
data the application has actually written into the buffer? 
 
Thanks for your help ...


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.



No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.549 / Virus Database: 270.9.2 - Release Date: 11/11/2008 12:00
AM
 


More information about the Alsa-devel mailing list