Re: esound (esd), 2.4.[12] chopped up sound -- solved
David Ford wrote: > > a) not all drivers are created equal > b) esd should check the return value anyway In as much as several people did point out that a write is not guaranteed to be complete and may be short, even when in blocking mode, you are perfectly correct. In as much as this usually is a result of an error condition or inability of the write to be completed, and not a result of a driver refusing to block and complete the write as the caller has requested (which would be the case in a sound driver since the output should be draining, the only exception being if the program had call the SETTRIGGER ioctl to disable the output starting with the first write of a complete oss frag, which esd doesn't do so it isn't a plausible condition) I think drivers that do this are "inferior" (since I can't call them buggy any longer). Amongst other things, it increases the number of traversals through the syscall heirarchy needlessly, wastes both kernel and user space CPU cycles, and negates the whole purpose of having the file opened in blocking mode anyway. So, yes esd should check these conditions to be complete and compliant with specs. Given a decent sound driver though, it shouldn't have to. > -d > > Doug Ledford wrote: > > > David Ford wrote: > > > > > > Actually you probably upgraded to a non-broken version of esd. Stock esd -still- > > > writes to the socket without regard to return value. If the write only accepted > > > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet >at > > > 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. > > > > > > I posted my last patch for esd here and to other places in June of 2000. All it > > > does is check for return value and adjust the writes accordingly. For reference, > > > the patch is at http://stuph.org/esound-audio.c.patch. > > > > Why would esd get a short write() unless it is opening the file in non > > blocking mode (which I didn't see when I was working on the i810 sound > > driver)? If esd is writing to a file in blocking mode and that write is > > returning short, then that sounds like a driver bug to me. -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
a) not all drivers are created equal b) esd should check the return value anyway -d Doug Ledford wrote: > David Ford wrote: > > > > Actually you probably upgraded to a non-broken version of esd. Stock esd -still- > > writes to the socket without regard to return value. If the write only accepted > > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at > > 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. > > > > I posted my last patch for esd here and to other places in June of 2000. All it > > does is check for return value and adjust the writes accordingly. For reference, > > the patch is at http://stuph.org/esound-audio.c.patch. > > Why would esd get a short write() unless it is opening the file in non > blocking mode (which I didn't see when I was working on the i810 sound > driver)? If esd is writing to a file in blocking mode and that write is > returning short, then that sounds like a driver bug to me. -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford <[EMAIL PROTECTED]> wrote: > Why would esd get a short write() unless it is opening the file in non > blocking mode (which I didn't see when I was working on the i810 sound > driver)? If esd is writing to a file in blocking mode and that write is > returning short, then that sounds like a driver bug to me. No, it's not a bug. It would be a bug if esd was writing to a *real* file or if the write() returned -1 and an errno of EAGAIN. But incomplete writes are very much ok. Just try opening /dev/tty and see how it won't take writes of more than 2k (iirc). And that's not just on Linux, I've tested on Solaris and BSD as well -- though it was a while ago. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
On Tue, 20 Mar 2001, Doug Ledford wrote: > Why would esd get a short write() unless it is opening the file in non > blocking mode (which I didn't see when I was working on the i810 sound > driver)? If esd is writing to a file in blocking mode and that write is > returning short, then that sounds like a driver bug to me. Please quote chapter and verse. I'm looking at http://www.opengroup.org/onlinepubs/7908799/xsh/write.html and cannot see anything which states that write may not return having written fewer data than it was asked to. The only vaguely relevant text I see is... Write requests to a pipe or FIFO will be handled the same as a regular file with the following exceptions: <...> * If the O_NONBLOCK flag is clear, a write request may cause the thread to block, but on normal completion it will return nbyte. This being an _exception_ clearly implies that for file descriptors other than pipes and fifos, it is _not_ necessary to return nbyte on normal completion. Applications (and also I believe glibc) which assume otherwise are, technically, broken. Despite being numerous. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
Not necessarily. For a write to a disk file, it would be an error to return a short write except in an error situation. For devices, the rules are looser. Quoting Stevens APUE p.406, "Some devices, notably terminals, networks, and any SVR4 streams devices have the following two properties. ... 2 A write operation can also return less that we specified. This may be caused by flow control constraints by downstream modules, for example. Again it's not an error, and we should continue writing the remainder of the data. (Normally this short return from a write only occurs with a nonblocking descriptor or if a signal is caught." So, whilst I personally find drivers that return a short write without O_NONBLOCK set to be rather obnoxious, it's not illegal, and you have to code accordingly :-) Tim On Tue, Mar 20, 2001 at 03:19:37PM -0500, Doug Ledford wrote: > David Ford wrote: > > > > Actually you probably upgraded to a non-broken version of esd. Stock esd -still- > > writes to the socket without regard to return value. If the write only accepted > > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at > > 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. > > > > I posted my last patch for esd here and to other places in June of 2000. All it > > does is check for return value and adjust the writes accordingly. For reference, > > the patch is at http://stuph.org/esound-audio.c.patch. > > Why would esd get a short write() unless it is opening the file in non > blocking mode (which I didn't see when I was working on the i810 sound > driver)? If esd is writing to a file in blocking mode and that write is > returning short, then that sounds like a driver bug to me. > > -- > > Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford > Please check my web site for aic7xxx updates/answers before > e-mailing me about problems > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
David Ford wrote: > > Actually you probably upgraded to a non-broken version of esd. Stock esd -still- > writes to the socket without regard to return value. If the write only accepted > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at > 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. > > I posted my last patch for esd here and to other places in June of 2000. All it > does is check for return value and adjust the writes accordingly. For reference, > the patch is at http://stuph.org/esound-audio.c.patch. Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. -d Peter Lund wrote: > Pozsar Balazs wrote: > > > Are you sure that the problem isn't at the mp3->raw conversino point? In > > mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2, > > but awfully on 2.4. > > Positive. Anyway, the problem is solved now...I just want to investigate it a > little bit further because I think there is something I can learn from it. > > In my original mail I wrote: > > > I've tested it on a freshly booted machine without X and gnome, only the bare > > essentials for the machine + esd + esdcat (I converted one of my mp3's into raw > > audio for the test). > > 1) mpg123 and XMMS sounded fine under 2.2.18 (which I hope was clear from what I > wrote). > 2) I played the raw sound directly to /dev/dsp -- worked great > 3) I played it through esd on 2.2.18 -- worked great > (the latter two points should have been made explicitly but weren't - sorry) > > so the conclusion is that there is some bad interaction between 2.4.x, the esd > version I was using, and the esdcat version I was using. esdcat seemed pretty > simple, it just > wrote 4K at a time to a Unix socket, blocking as necessary, so I figured the > culprit was elsewhere. > > The problem went away when I upgraded to the esd in Debian unstable (in the > esound package). I was either using an esd binary from Debian stable or one > from one of the Ximian packages. I'm still not sure whether they supply an esd > themselves or just rely on the standard Debian one. > > I took a look at the diff between the stable/testing and unstable versions of > the Debian esound package and there was a change in two or three places that > seems to give a plausible explanation. A simple write() was changed into a loop > that retried the write() in case it was partial with an error code of EAGAIN > (after sleeping 100 microseconds and with an upper bound on the number of > retries). > > My theory now is that the sound driver changed in some way from 2.2.x to 2.4.x > so some writes would only move a limited amount of bytes to the driver. Maybe > the driver only accepts about 4K in each version and the kernel performs the > retries, sleeping in between? Just a theory until I know more. > > Anyway, it works now with 2.4.x, even without the lowlatency patch from Andrew > Morton. > > -Peter > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
Pozsar Balazs wrote: > Are you sure that the problem isn't at the mp3->raw conversino point? In > mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2, > but awfully on 2.4. Positive. Anyway, the problem is solved now...I just want to investigate it a little bit further because I think there is something I can learn from it. In my original mail I wrote: > I've tested it on a freshly booted machine without X and gnome, only the bare > essentials for the machine + esd + esdcat (I converted one of my mp3's into raw > audio for the test). 1) mpg123 and XMMS sounded fine under 2.2.18 (which I hope was clear from what I wrote). 2) I played the raw sound directly to /dev/dsp -- worked great 3) I played it through esd on 2.2.18 -- worked great (the latter two points should have been made explicitly but weren't - sorry) so the conclusion is that there is some bad interaction between 2.4.x, the esd version I was using, and the esdcat version I was using. esdcat seemed pretty simple, it just wrote 4K at a time to a Unix socket, blocking as necessary, so I figured the culprit was elsewhere. The problem went away when I upgraded to the esd in Debian unstable (in the esound package). I was either using an esd binary from Debian stable or one from one of the Ximian packages. I'm still not sure whether they supply an esd themselves or just rely on the standard Debian one. I took a look at the diff between the stable/testing and unstable versions of the Debian esound package and there was a change in two or three places that seems to give a plausible explanation. A simple write() was changed into a loop that retried the write() in case it was partial with an error code of EAGAIN (after sleeping 100 microseconds and with an upper bound on the number of retries). My theory now is that the sound driver changed in some way from 2.2.x to 2.4.x so some writes would only move a limited amount of bytes to the driver. Maybe the driver only accepts about 4K in each version and the kernel performs the retries, sleeping in between? Just a theory until I know more. Anyway, it works now with 2.4.x, even without the lowlatency patch from Andrew Morton. -Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
Pozsar Balazs wrote: Are you sure that the problem isn't at the mp3-raw conversino point? In mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2, but awfully on 2.4. Positive. Anyway, the problem is solved now...I just want to investigate it a little bit further because I think there is something I can learn from it. In my original mail I wrote: I've tested it on a freshly booted machine without X and gnome, only the bare essentials for the machine + esd + esdcat (I converted one of my mp3's into raw audio for the test). 1) mpg123 and XMMS sounded fine under 2.2.18 (which I hope was clear from what I wrote). 2) I played the raw sound directly to /dev/dsp -- worked great 3) I played it through esd on 2.2.18 -- worked great (the latter two points should have been made explicitly but weren't - sorry) so the conclusion is that there is some bad interaction between 2.4.x, the esd version I was using, and the esdcat version I was using. esdcat seemed pretty simple, it just wrote 4K at a time to a Unix socket, blocking as necessary, so I figured the culprit was elsewhere. The problem went away when I upgraded to the esd in Debian unstable (in the esound package). I was either using an esd binary from Debian stable or one from one of the Ximian packages. I'm still not sure whether they supply an esd themselves or just rely on the standard Debian one. I took a look at the diff between the stable/testing and unstable versions of the Debian esound package and there was a change in two or three places that seems to give a plausible explanation. A simple write() was changed into a loop that retried the write() in case it was partial with an error code of EAGAIN (after sleeping 100 microseconds and with an upper bound on the number of retries). My theory now is that the sound driver changed in some way from 2.2.x to 2.4.x so some writes would only move a limited amount of bytes to the driver. Maybe the driver only accepts about 4K in each version and the kernel performs the retries, sleeping in between? Just a theory until I know more. Anyway, it works now with 2.4.x, even without the lowlatency patch from Andrew Morton. -Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. -d Peter Lund wrote: Pozsar Balazs wrote: Are you sure that the problem isn't at the mp3-raw conversino point? In mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2, but awfully on 2.4. Positive. Anyway, the problem is solved now...I just want to investigate it a little bit further because I think there is something I can learn from it. In my original mail I wrote: I've tested it on a freshly booted machine without X and gnome, only the bare essentials for the machine + esd + esdcat (I converted one of my mp3's into raw audio for the test). 1) mpg123 and XMMS sounded fine under 2.2.18 (which I hope was clear from what I wrote). 2) I played the raw sound directly to /dev/dsp -- worked great 3) I played it through esd on 2.2.18 -- worked great (the latter two points should have been made explicitly but weren't - sorry) so the conclusion is that there is some bad interaction between 2.4.x, the esd version I was using, and the esdcat version I was using. esdcat seemed pretty simple, it just wrote 4K at a time to a Unix socket, blocking as necessary, so I figured the culprit was elsewhere. The problem went away when I upgraded to the esd in Debian unstable (in the esound package). I was either using an esd binary from Debian stable or one from one of the Ximian packages. I'm still not sure whether they supply an esd themselves or just rely on the standard Debian one. I took a look at the diff between the stable/testing and unstable versions of the Debian esound package and there was a change in two or three places that seems to give a plausible explanation. A simple write() was changed into a loop that retried the write() in case it was partial with an error code of EAGAIN (after sleeping 100 microseconds and with an upper bound on the number of retries). My theory now is that the sound driver changed in some way from 2.2.x to 2.4.x so some writes would only move a limited amount of bytes to the driver. Maybe the driver only accepts about 4K in each version and the kernel performs the retries, sleeping in between? Just a theory until I know more. Anyway, it works now with 2.4.x, even without the lowlatency patch from Andrew Morton. -Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
David Ford wrote: Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. -- Doug Ledford [EMAIL PROTECTED] http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
Not necessarily. For a write to a disk file, it would be an error to return a short write except in an error situation. For devices, the rules are looser. Quoting Stevens APUE p.406, "Some devices, notably terminals, networks, and any SVR4 streams devices have the following two properties. ... 2 A write operation can also return less that we specified. This may be caused by flow control constraints by downstream modules, for example. Again it's not an error, and we should continue writing the remainder of the data. (Normally this short return from a write only occurs with a nonblocking descriptor or if a signal is caught." So, whilst I personally find drivers that return a short write without O_NONBLOCK set to be rather obnoxious, it's not illegal, and you have to code accordingly :-) Tim On Tue, Mar 20, 2001 at 03:19:37PM -0500, Doug Ledford wrote: David Ford wrote: Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. -- Doug Ledford [EMAIL PROTECTED] http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
On Tue, 20 Mar 2001, Doug Ledford wrote: Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. Please quote chapter and verse. I'm looking at http://www.opengroup.org/onlinepubs/7908799/xsh/write.html and cannot see anything which states that write may not return having written fewer data than it was asked to. The only vaguely relevant text I see is... Write requests to a pipe or FIFO will be handled the same as a regular file with the following exceptions: ... * If the O_NONBLOCK flag is clear, a write request may cause the thread to block, but on normal completion it will return nbyte. This being an _exception_ clearly implies that for file descriptors other than pipes and fifos, it is _not_ necessary to return nbyte on normal completion. Applications (and also I believe glibc) which assume otherwise are, technically, broken. Despite being numerous. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford [EMAIL PROTECTED] wrote: Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. No, it's not a bug. It would be a bug if esd was writing to a *real* file or if the write() returned -1 and an errno of EAGAIN. But incomplete writes are very much ok. Just try opening /dev/tty and see how it won't take writes of more than 2k (iirc). And that's not just on Linux, I've tested on Solaris and BSD as well -- though it was a while ago. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
a) not all drivers are created equal b) esd should check the return value anyway -d Doug Ledford wrote: David Ford wrote: Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
David Ford wrote: a) not all drivers are created equal b) esd should check the return value anyway In as much as several people did point out that a write is not guaranteed to be complete and may be short, even when in blocking mode, you are perfectly correct. In as much as this usually is a result of an error condition or inability of the write to be completed, and not a result of a driver refusing to block and complete the write as the caller has requested (which would be the case in a sound driver since the output should be draining, the only exception being if the program had call the SETTRIGGER ioctl to disable the output starting with the first write of a complete oss frag, which esd doesn't do so it isn't a plausible condition) I think drivers that do this are "inferior" (since I can't call them buggy any longer). Amongst other things, it increases the number of traversals through the syscall heirarchy needlessly, wastes both kernel and user space CPU cycles, and negates the whole purpose of having the file opened in blocking mode anyway. So, yes esd should check these conditions to be complete and compliant with specs. Given a decent sound driver though, it shouldn't have to. -d Doug Ledford wrote: David Ford wrote: Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. -- Doug Ledford [EMAIL PROTECTED] http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
