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 majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 21:00:14 EST