Christopher Monty Montgomery wrote:
> On 10/9/06, Clemens Ladisch <[EMAIL PROTECTED]> wrote:
> > Christopher Monty Montgomery wrote:
> > > Hrm.  that's non-atomic and as such involves a race and is not
> > > reliable.  Or am I missing something in the API? Does the xrun staus
> > > persist until read?
> >
> > The delay gets smaller when the device reads data out of the buffer, and
> > gets larger when the application writes data to the buffer.  In an
> > underrun situation, the delay remains negative until you have written
> > some data (some part of which won't actually be played because it was
> > written too late).
> 
> Still a race.  I could read positive, more data plays and starves
> between that point and when I add data into the buffer.  If there's a
> race, it's not reliable.

You could read the delay just after the write and check that it is at
least as big as the data you've written, but this can, of course, race
in the other way. (Well, you could think of that as a safety margin ...)

The API does not have a way to reliably detect xruns because in the
general case (of a PCI sound card reading directly from the buffer) it's
not possible to atomically compare the hardware position and the
application's position in the buffer.  The USB driver is an exception
because taking data out of the buffer is done by software, too.
(In the PCI case, you would also have to use a safety margin.)

> > I think you want the ALSA API to behave like your implementation of
> > usb_submit_urb(), but this just isn't the way it was designed.  :-)
> 
> No, I want to have more options than "never know anything went wrong"
> and "anything going wrong may be fatal."

All you can do with the current API is to move the uncertainty of the
first option in the other direction, as in "something may have gone
wrong".

> It is especially frustrating that I know the code is perfectly capable
> of doing what I want.

The ALSA API was designed before the USB driver.

It would be possible to add an error counter, and it's possibly required
for OSSv4 compatibility anyway, but it isn't yet there.


Regards,
Clemens

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to