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. I run streams for *hours at a time*. If there's a one in a million chance of failure, I'm going to have several failures in every recording attempt. > > Why could the write/read not return an error code? > > It would indicate a failure of the write/read call, but the while point > of the xrun-ignoring mode is to make xruns a non-failure condition. I'm not suggesting an xrun-ignoring condition. I'm suggesting a condition that doesn't shut down the device in order to report an xrun. Right now I have a choice: get an xrun and have the device potentially unrecoverable, or get no errors even when they happen. > > Again, there's EINTR and EAGAIN for precedent, which are similar ways > > of giving feedback in a blocking call. > > Error codes like these indicate that the call was not able to do its > job, but in an xrun condition, writing/reading is still possible. No, the return does not indicate the call was 'unable' it simply reports that it 'did not' and depending on the code, it may also mean it was unable. When you call read() and get EINTR, that does not mean the read() failed (unable). It means the read returned early (did not). > > EPIPE also already reports non-permanent errors (in the sense that you > > can re-prepare and start the stream back up). > > EPIPE is a permanent error in the sense that you cannot simply call > write()/read() again. (And re-preparing might fail for other reasons, > such as insufficient memory.) Exactly. I currently have the choice offered of any error potentially being truly unrecoverable (eg, for USB devices, snd_pcm_prepare() is not guaranteed to work, in fact, it's very likely to fail second time) or never getting errors. Sir, this is not a choice! > 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." It is especially frustrating that I know the code is perfectly capable of doing what I want. XRUN, as you say, is not a classic error. It is merely a state to be reported. By assuming all return codes are fatal errors, you are eliminating useful functionality. 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
