Hi, I've just installed an M-Audio Audiophile 2496 sound card (Envy24)
with the 2.6.0-test5 kernel (with the preemptible kernel option on),
using the ice1712 alsa driver (although this also happens in 2.4.21
without preemptible kernel).
Music plays fine until I do *anything* - changing windows, scrolling,
pressing buttons, whatever - when it stutters badly. Scrolling in an
anti-aliased terminal is especially fun. However, if I play using XMMS
with the realtime priority option, everything's fine, although that has
the distinct disadvantage that I have to run it as root.
I've tried enabling/disabling ACPI/APM/APIC. The card isn't sharing an
IRQ with anything. It's not a hard drive/IDE related issue, although
that's all using DMA anyway.
I do have both an AGP and a PCI graphics card installed and in use,
although the stuttering happens if I do anything on either. I've found a
few references to this problem on google, but no solutions. It works
fine on Windows ;).
Here's what happens if I try to scroll in gnome-terminal whilst aplaying
something:
rg@russell:~$ aplay < test
Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
xrun!!! (at least 869.990 ms long)
xrun!!! (at least 21.552 ms long)
xrun!!! (at least 17.686 ms long)
xrun!!! (at least 16.482 ms long)
xrun!!! (at least 17.194 ms long)
xrun!!! (at least 17.126 ms long)
xrun!!! (at least 14.123 ms long)
xrun!!! (at least 13.679 ms long)
xrun!!! (at least 12.928 ms long)
[...and so on, for another 20 or so lines]
lspci says:
00:0c.0 Multimedia audio controller: IC Ensemble Inc ICE1712 [Envy24]
(rev 02)
Subsystem: IC Ensemble Inc: Unknown device d634
Flags: bus master, medium devsel, latency 32, IRQ 12
I/O ports at d400 [size=32]
I/O ports at d800 [size=16]
I/O ports at dc00 [size=16]
I/O ports at e000 [size=64]
Capabilities: [80] Power Management version 1
--
Russ Garrett http://russ.garrett.co.uk
[email protected]
At Tue, 09 Sep 2003 15:14:21 +0100,
Russ Garrett wrote:
>
> Hi, I've just installed an M-Audio Audiophile 2496 sound card (Envy24)
> with the 2.6.0-test5 kernel (with the preemptible kernel option on),
> using the ice1712 alsa driver (although this also happens in 2.4.21
> without preemptible kernel).
>
> Music plays fine until I do *anything* - changing windows, scrolling,
> pressing buttons, whatever - when it stutters badly. Scrolling in an
> anti-aliased terminal is especially fun. However, if I play using XMMS
> with the realtime priority option, everything's fine, although that has
> the distinct disadvantage that I have to run it as root.
>
> I've tried enabling/disabling ACPI/APM/APIC. The card isn't sharing an
> IRQ with anything. It's not a hard drive/IDE related issue, although
> that's all using DMA anyway.
>
> I do have both an AGP and a PCI graphics card installed and in use,
> although the stuttering happens if I do anything on either. I've found a
> few references to this problem on google, but no solutions. It works
> fine on Windows ;).
>
> Here's what happens if I try to scroll in gnome-terminal whilst aplaying
> something:
>
> rg@russell:~$ aplay < test
> Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
> xrun!!! (at least 869.990 ms long)
> xrun!!! (at least 21.552 ms long)
> xrun!!! (at least 17.686 ms long)
> xrun!!! (at least 16.482 ms long)
> xrun!!! (at least 17.194 ms long)
> xrun!!! (at least 17.126 ms long)
> xrun!!! (at least 14.123 ms long)
> xrun!!! (at least 13.679 ms long)
> xrun!!! (at least 12.928 ms long)
> [...and so on, for another 20 or so lines]
i guess it's a general scheduler issue.
why you face this problem more severly than others:
the timing on the ice1712 (envy24) chip is quite tight, because it
always needs 32bit * 10 channels interleaved samples even if you want
to play a two-channel mp3 file. more badly, the maximum buffer size
is limited to 64k byte. hence, at most, you can get about 0.1 sec for
the hardware buffer. if the task switching to the audio thread cannot
be done in 0.1 sec, you'll get audio drop outs.
the recent scheduler patch might help...
--
Takashi Iwai <[email protected]> SuSE Linux AG - http://www.suse.de
ALSA Developer ALSA Project - http://www.alsa-project.org
On Wed, 10 Sep 2003, Takashi Iwai wrote:
> At Tue, 09 Sep 2003 15:14:21 +0100,
> Russ Garrett wrote:
> >
> > Hi, I've just installed an M-Audio Audiophile 2496 sound card (Envy24)
> > with the 2.6.0-test5 kernel (with the preemptible kernel option on),
> > using the ice1712 alsa driver (although this also happens in 2.4.21
> > without preemptible kernel).
> >
> > Music plays fine until I do *anything* - changing windows, scrolling,
> > pressing buttons, whatever - when it stutters badly. Scrolling in an
> > anti-aliased terminal is especially fun. However, if I play using XMMS
> > with the realtime priority option, everything's fine, although that has
> > the distinct disadvantage that I have to run it as root.
> >
> > I've tried enabling/disabling ACPI/APM/APIC. The card isn't sharing an
> > IRQ with anything. It's not a hard drive/IDE related issue, although
> > that's all using DMA anyway.
> >
> > I do have both an AGP and a PCI graphics card installed and in use,
> > although the stuttering happens if I do anything on either. I've found a
> > few references to this problem on google, but no solutions. It works
> > fine on Windows ;).
> >
> > Here's what happens if I try to scroll in gnome-terminal whilst aplaying
> > something:
> >
> > rg@russell:~$ aplay < test
> > Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
> > xrun!!! (at least 869.990 ms long)
> > xrun!!! (at least 21.552 ms long)
> > xrun!!! (at least 17.686 ms long)
> > xrun!!! (at least 16.482 ms long)
> > xrun!!! (at least 17.194 ms long)
> > xrun!!! (at least 17.126 ms long)
> > xrun!!! (at least 14.123 ms long)
> > xrun!!! (at least 13.679 ms long)
> > xrun!!! (at least 12.928 ms long)
> > [...and so on, for another 20 or so lines]
>
> i guess it's a general scheduler issue.
>
> why you face this problem more severly than others:
> the timing on the ice1712 (envy24) chip is quite tight, because it
> always needs 32bit * 10 channels interleaved samples even if you want
> to play a two-channel mp3 file. more badly, the maximum buffer size
> is limited to 64k byte. hence, at most, you can get about 0.1 sec for
It's limited to 256kB. And yes, it's only 0.14 sec for 44.1kHz playback.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
At Wed, 10 Sep 2003 15:38:46 +0200 (CEST),
Jaroslav wrote:
>
> On Wed, 10 Sep 2003, Takashi Iwai wrote:
>
> > At Tue, 09 Sep 2003 15:14:21 +0100,
> > Russ Garrett wrote:
> > >
> > > Hi, I've just installed an M-Audio Audiophile 2496 sound card (Envy24)
> > > with the 2.6.0-test5 kernel (with the preemptible kernel option on),
> > > using the ice1712 alsa driver (although this also happens in 2.4.21
> > > without preemptible kernel).
> > >
> > > Music plays fine until I do *anything* - changing windows, scrolling,
> > > pressing buttons, whatever - when it stutters badly. Scrolling in an
> > > anti-aliased terminal is especially fun. However, if I play using XMMS
> > > with the realtime priority option, everything's fine, although that has
> > > the distinct disadvantage that I have to run it as root.
> > >
> > > I've tried enabling/disabling ACPI/APM/APIC. The card isn't sharing an
> > > IRQ with anything. It's not a hard drive/IDE related issue, although
> > > that's all using DMA anyway.
> > >
> > > I do have both an AGP and a PCI graphics card installed and in use,
> > > although the stuttering happens if I do anything on either. I've found a
> > > few references to this problem on google, but no solutions. It works
> > > fine on Windows ;).
> > >
> > > Here's what happens if I try to scroll in gnome-terminal whilst aplaying
> > > something:
> > >
> > > rg@russell:~$ aplay < test
> > > Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
> > > xrun!!! (at least 869.990 ms long)
> > > xrun!!! (at least 21.552 ms long)
> > > xrun!!! (at least 17.686 ms long)
> > > xrun!!! (at least 16.482 ms long)
> > > xrun!!! (at least 17.194 ms long)
> > > xrun!!! (at least 17.126 ms long)
> > > xrun!!! (at least 14.123 ms long)
> > > xrun!!! (at least 13.679 ms long)
> > > xrun!!! (at least 12.928 ms long)
> > > [...and so on, for another 20 or so lines]
> >
> > i guess it's a general scheduler issue.
> >
> > why you face this problem more severly than others:
> > the timing on the ice1712 (envy24) chip is quite tight, because it
> > always needs 32bit * 10 channels interleaved samples even if you want
> > to play a two-channel mp3 file. more badly, the maximum buffer size
> > is limited to 64k byte. hence, at most, you can get about 0.1 sec for
>
> It's limited to 256kB. And yes, it's only 0.14 sec for 44.1kHz playback.
oh yes, thanks for correction :)
Takashi
On Wed, 10 Sep 2003, Takashi Iwai wrote:
> At Wed, 10 Sep 2003 15:38:46 +0200 (CEST),
> Jaroslav wrote:
> >
> > On Wed, 10 Sep 2003, Takashi Iwai wrote:
> >
> > > At Tue, 09 Sep 2003 15:14:21 +0100,
> > > Russ Garrett wrote:
> > > >
> > > > Hi, I've just installed an M-Audio Audiophile 2496 sound card (Envy24)
> > > > with the 2.6.0-test5 kernel (with the preemptible kernel option on),
> > > > using the ice1712 alsa driver (although this also happens in 2.4.21
> > > > without preemptible kernel).
> > > >
> > > > Music plays fine until I do *anything* - changing windows, scrolling,
> > > > pressing buttons, whatever - when it stutters badly. Scrolling in an
> > > > anti-aliased terminal is especially fun. However, if I play using XMMS
> > > > with the realtime priority option, everything's fine, although that has
> > > > the distinct disadvantage that I have to run it as root.
> > > >
> > > > I've tried enabling/disabling ACPI/APM/APIC. The card isn't sharing an
> > > > IRQ with anything. It's not a hard drive/IDE related issue, although
> > > > that's all using DMA anyway.
> > > >
> > > > I do have both an AGP and a PCI graphics card installed and in use,
> > > > although the stuttering happens if I do anything on either. I've found a
> > > > few references to this problem on google, but no solutions. It works
> > > > fine on Windows ;).
> > > >
> > > > Here's what happens if I try to scroll in gnome-terminal whilst aplaying
> > > > something:
> > > >
> > > > rg@russell:~$ aplay < test
> > > > Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
> > > > xrun!!! (at least 869.990 ms long)
> > > > xrun!!! (at least 21.552 ms long)
> > > > xrun!!! (at least 17.686 ms long)
> > > > xrun!!! (at least 16.482 ms long)
> > > > xrun!!! (at least 17.194 ms long)
> > > > xrun!!! (at least 17.126 ms long)
> > > > xrun!!! (at least 14.123 ms long)
> > > > xrun!!! (at least 13.679 ms long)
> > > > xrun!!! (at least 12.928 ms long)
> > > > [...and so on, for another 20 or so lines]
> > >
> > > i guess it's a general scheduler issue.
> > >
> > > why you face this problem more severly than others:
> > > the timing on the ice1712 (envy24) chip is quite tight, because it
> > > always needs 32bit * 10 channels interleaved samples even if you want
> > > to play a two-channel mp3 file. more badly, the maximum buffer size
> > > is limited to 64k byte. hence, at most, you can get about 0.1 sec for
> >
> > It's limited to 256kB. And yes, it's only 0.14 sec for 44.1kHz playback.
>
> oh yes, thanks for correction :)
>
>
> Takashi
>
I don't see the driver in linux-2.4.22/drivers/sound, so I can't
look at it directly, but normally all you have to do is keep
a FIFO full (not empty) during play. There should not be any
scheduling issues with sound chips although I am seeing too
much of that lately. Maybe somebody should look at the driver
before the scheduler is blamed. Perhaps the driver is not
designed properly so it assumes the user-mode code can do
something it can't possibly be expected to do with any
reliability. For instance, perhaps it's the user-mode's
responsibility to keep a FIFO full? And, you can never
guarantee that.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
Note 96.31% of all statistics are fiction.
On Thu, 11 Sep 2003 00:45, Richard B. Johnson wrote:
> I don't see the driver in linux-2.4.22/drivers/sound, so I can't
> look at it directly, but normally all you have to do is keep
> a FIFO full (not empty) during play. There should not be any
> scheduling issues with sound chips although I am seeing too
> much of that lately. Maybe somebody should look at the driver
> before the scheduler is blamed. Perhaps the driver is not
> designed properly so it assumes the user-mode code can do
> something it can't possibly be expected to do with any
> reliability. For instance, perhaps it's the user-mode's
> responsibility to keep a FIFO full? And, you can never
> guarantee that.
That may be the case, but there is a very clear problem with the vanilla
scheduler that can cause too low priority for audio apps for up to 25 seconds
after starting a new thread (eg new song). In turn they will skip madly when
any higher priority task uses a burst of cpu and repeatedly preempts it (X,
mozilla, the neighbour's dog...). Only the largest buffer audio cards wont
skip with the vanilla scheduler, and _no_ amount of single cpu capability
today is enough to avoid the scheduler based starvation. So while it never
hurts to keep an eye on driver performance, the scheduler itself _must_ be
fixed to prevent this happening.
Con
At Wed, 10 Sep 2003 10:45:16 -0400 (EDT),
Richard B. Johnson wrote:
>
> On Wed, 10 Sep 2003, Takashi Iwai wrote:
>
> > At Wed, 10 Sep 2003 15:38:46 +0200 (CEST),
> > Jaroslav wrote:
> > >
> > > On Wed, 10 Sep 2003, Takashi Iwai wrote:
> > >
> > > > At Tue, 09 Sep 2003 15:14:21 +0100,
> > > > Russ Garrett wrote:
> > > > >
> > > > > Hi, I've just installed an M-Audio Audiophile 2496 sound card (Envy24)
> > > > > with the 2.6.0-test5 kernel (with the preemptible kernel option on),
> > > > > using the ice1712 alsa driver (although this also happens in 2.4.21
> > > > > without preemptible kernel).
> > > > >
> > > > > Music plays fine until I do *anything* - changing windows, scrolling,
> > > > > pressing buttons, whatever - when it stutters badly. Scrolling in an
> > > > > anti-aliased terminal is especially fun. However, if I play using XMMS
> > > > > with the realtime priority option, everything's fine, although that has
> > > > > the distinct disadvantage that I have to run it as root.
> > > > >
> > > > > I've tried enabling/disabling ACPI/APM/APIC. The card isn't sharing an
> > > > > IRQ with anything. It's not a hard drive/IDE related issue, although
> > > > > that's all using DMA anyway.
> > > > >
> > > > > I do have both an AGP and a PCI graphics card installed and in use,
> > > > > although the stuttering happens if I do anything on either. I've found a
> > > > > few references to this problem on google, but no solutions. It works
> > > > > fine on Windows ;).
> > > > >
> > > > > Here's what happens if I try to scroll in gnome-terminal whilst aplaying
> > > > > something:
> > > > >
> > > > > rg@russell:~$ aplay < test
> > > > > Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
> > > > > xrun!!! (at least 869.990 ms long)
> > > > > xrun!!! (at least 21.552 ms long)
> > > > > xrun!!! (at least 17.686 ms long)
> > > > > xrun!!! (at least 16.482 ms long)
> > > > > xrun!!! (at least 17.194 ms long)
> > > > > xrun!!! (at least 17.126 ms long)
> > > > > xrun!!! (at least 14.123 ms long)
> > > > > xrun!!! (at least 13.679 ms long)
> > > > > xrun!!! (at least 12.928 ms long)
> > > > > [...and so on, for another 20 or so lines]
> > > >
> > > > i guess it's a general scheduler issue.
> > > >
> > > > why you face this problem more severly than others:
> > > > the timing on the ice1712 (envy24) chip is quite tight, because it
> > > > always needs 32bit * 10 channels interleaved samples even if you want
> > > > to play a two-channel mp3 file. more badly, the maximum buffer size
> > > > is limited to 64k byte. hence, at most, you can get about 0.1 sec for
> > >
> > > It's limited to 256kB. And yes, it's only 0.14 sec for 44.1kHz playback.
> >
> > oh yes, thanks for correction :)
> >
> >
> > Takashi
> >
>
> I don't see the driver in linux-2.4.22/drivers/sound, so I can't
> look at it directly, but normally all you have to do is keep
> a FIFO full (not empty) during play. There should not be any
> scheduling issues with sound chips although I am seeing too
> much of that lately. Maybe somebody should look at the driver
> before the scheduler is blamed. Perhaps the driver is not
> designed properly so it assumes the user-mode code can do
> something it can't possibly be expected to do with any
> reliability. For instance, perhaps it's the user-mode's
> responsibility to keep a FIFO full? And, you can never
> guarantee that.
well, it's possible to have a large intermediate buffer on the kernel
space and do memcpy from it to the hardware audio buffer in the
interrupt handler.
but, in general, we don't want such a heavy job in the interrupt
context. or, using a tasklet? hmm...
anyway, if you want to run a realtime audio application, this
mechanism is nothing but a kludge. this must be swithable somehow.
--
Takashi Iwai <[email protected]> SuSE Linux AG - http://www.suse.de
ALSA Developer ALSA Project - http://www.alsa-project.org
> I don't see the driver in linux-2.4.22/drivers/sound, so I can't
> look at it directly,
It's ALSA, so it isn't in the 2.4 tree - it's in sound/pci/ice1712/ in
2.6. And FWIW, this happens continuously, not just in the 25 seconds (or
whatever) after playback starts.
--
Russ Garrett http://russ.garrett.co.uk
[email protected]
On Wed, 2003-09-10 at 13:47, Russ Garrett wrote:
> It's ALSA, so it isn't in the 2.4 tree - it's in sound/pci/ice1712/ in
> 2.6. And FWIW, this happens continuously, not just in the 25 seconds (or
> whatever) after playback starts.
I have a Envy24 ICE1712 based card also. I have noticed the same
thing. I would say in the first 25 seconds I can't do anything with my
machine without getting a skip. But after 25 seconds, it is pretty
good. Pushing my machine hard, lots of disk or X activity can induce
small skips after that 25 seconds (I've been meaning to try the new
scheduler patches).
I'll agree that larger buffers are not the answer. I sometimes mess
with live audio effects. That is recording some audio, processing it in
some way, and then playing it back. If the buffer is too large, a
noticeable delay would be introduced. Takashi and Jaroslav I'm pretty
sure know the problem this causes with musicians, who need to hear what
they played or sang in a very short period of time, or it messes with
the brain. I'm just not sure all the kernel developers are also aware
of this effect. It is more than just not having to wait a minute to
hear the effects of an EQ change.
--
Chris
At 10 Sep 2003 14:16:28 -0400,
Chris Meadors wrote:
>
> I'll agree that larger buffers are not the answer. I sometimes mess
> with live audio effects. That is recording some audio, processing it in
> some way, and then playing it back. If the buffer is too large, a
> noticeable delay would be introduced. Takashi and Jaroslav I'm pretty
> sure know the problem this causes with musicians, who need to hear what
> they played or sang in a very short period of time, or it messes with
> the brain.
to handle the data in a short period can be never guaranteed if the
process runs without the real-time priority.
the simple and only solution is to run such an application with
RT scheduling, IMO.
(the playback of xmms is a slightly different problem because it's
not designed (purposed) as a real-time process.)
--
Takashi Iwai <[email protected]> SuSE Linux AG - http://www.suse.de
ALSA Developer ALSA Project - http://www.alsa-project.org