Hi
On my home machine playing sound through esd has worked beautifully on various
kernels from 2.2.5 and up to 2.2.18.
On 2.4.1 and 2.4.2 it stinks.
It sounds like there are small pauses or repetitions in the sound, as if esd
doesn't get
the data quickly enough from the client or something. Music and voices
(realaudio radio) still easy to understand but it does get on my nerves after a
few minutes :(
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).
It sounds the same the first, second, and third time I try so I don't think it
is because the hard disk can't keep up. Besides, I stopped after about 10
seconds so it should all be in the cache after the first time.
The machine is a 400 MHz K6-2 with a VIA<something> chipset, the harddisk used
is a Quantum lct10 30 (30 GB). Yes, DMS is enabled, I get a read bandwidth of
about 12.5 MB/s.
I have also tried Andrew Morton's low latency patches for both 2.4.1 and 2.4.2
but that doesn't help. According to Benno's latency tests I get quite good
(low) latencies with just a normal 2.4.[12] kernel as long as DMA transfer is
enabled.
The lmbench results seem pretty normal, too, once the DMA transfer is enabled,
except for one small anomaly: Debian's 2.2.18pre21compact kernel was a bit
faster than the 2.2.18 kernel I compiled myself.
My theory is that this is a "scheduling delay" effect, i.e. esd or the process
sending data to esd is ready to run but some other unrelated process gets there
first and runs for a little while. Any ideas on how to test this? LTT doesn't
have patches for 2.4.[12] yet...
I can't access my home machine from here because it is behind a stupid NAT'ing
router, but I can try whatever you throw at my and/or get more information,
there's just a little timelag because it will have to wait until I'm home (I
/can/ access my work machine from home).
-Peter
> On my home machine playing sound through esd has worked beautifully on various
> kernels from 2.2.5 and up to 2.2.18.
> On 2.4.1 and 2.4.2 it stinks.
>
> It sounds like there are small pauses or repetitions in the sound, as if esd
> doesn't get
> the data quickly enough from the client or something. Music and voices
> (realaudio radio) still easy to understand but it does get on my nerves after a
> few minutes :(
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.
I suggest you trying another (meybe self-compiled) version of mpg123.
bye,
Balazs Pozsar.
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
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
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
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
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
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.
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
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