Messages in this thread | | | Date | Wed, 10 Sep 2003 17:43:08 +0200 | From | Takashi Iwai <> | Subject | Re: Audio skipping with alsa |
| |
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 <tiwai@suse.de> SuSE Linux AG - www.suse.de ALSA Developer ALSA Project - www.alsa-project.org
- 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/
| |