On 10/9/06, Clemens Ladisch <[EMAIL PROTECTED]> wrote:
> Christopher Monty Montgomery wrote:
> > On 10/6/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> > > According to Clemens, snd-usb-audio can be configured to use or to not use
> > > dummy data, by the application.  If it's doing the wrong thing your
> > > application is therefore at fault.
> >
> > If it uses dummy data, it never reports the xrun.
>
> In that case, it cannot report the xrun immediately because returning an
> error code from snd_pcm_write() (or write()) would mean something
> different.
>
> You can detect an xrun by checking whether the return value of
> snd_pcm_delay() is negative.

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?

Why could the write/read not return an error code?  Again, there's
EINTR and EAGAIN for precedent, which are similar ways of giving
feedback in a blocking call.  EPIPE also already reports non-permanent
errors (in the sense that you can re-prepare and start the stream back
up).

Monty

-------------------------------------------------------------------------
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