From: Peter Lund <firefly@netgroup.dk>
To: linux-kernel@vger.kernel.org
Subject: esound (esd), 2.4.[12] chopped up sound
Date: Mon, 19 Mar 2001 13:15:42 +0100 [thread overview]
Message-ID: <3AB5F86E.69B3593C@netgroup.dk> (raw)
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
next reply other threads:[~2001-03-19 12:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-19 12:15 Peter Lund [this message]
2001-03-20 17:35 ` esound (esd), 2.4.[12] chopped up sound Pozsar Balazs
2001-03-20 18:34 ` esound (esd), 2.4.[12] chopped up sound -- solved Peter Lund
2001-03-20 19:50 ` David Ford
2001-03-20 20:19 ` Doug Ledford
2001-03-20 22:24 ` Tim Wright
2001-03-20 22:37 ` David Woodhouse
2001-03-20 23:20 ` Ion Badulescu
2001-03-21 3:36 ` David Ford
2001-03-21 6:45 ` Doug Ledford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AB5F86E.69B3593C@netgroup.dk \
--to=firefly@netgroup.dk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox