I found that 2.2.18 probably rudely drops samples (lets ocassionally one sample
be played several times) on the Gravis Ultrasound output device. I use 2.2.18
and the native kernel drivers. I wrote this program that should produce a clean
sine tone. Instead I hear a sine interspaced with crackling. The crackling
repeats at 100Hz I guess. There runs nothing CPU-consuming. The sound process
takes 5% CPU. It's funny Linux drops sound samples just at 5% of CPU load. I
got AMD K6-2 3D 400Mhz at 400Mhz, 4*100MHz, running stably between 20-35 deg C
of case temperature. I got PCI / AGP board FIC VA-503+. There are three serial
ports, none of them was transceiving at that time. There is one ISA NE2000 NIC
which was not sending any packets. There is a ISA Gravis Ultrasound PnP. Two
IDE disks, one of them sleeping, the second spinning but nod reading/writing.
64MB of 100MHz DIMM SDRAM, which runs for years without problems. 1MB L2 cache.
AGP video card ATI. No X server running, no SVGAlib application running. No
USB peripherals.
The crackling is not dependent on the buffer size you can set up in the C code.
The crackling is dependent on the frequency of the sine. It's clearly audible
(read: annoying) at 10kHz, audible at 1kHz, inaudible at 100Hz. So I think
they are sample dropouts - the card stops playing and repeats one sample until
kernel gets the breath and whips itself up to supply next audio data.
There are no custom changes in the drivers - no buffer tweaking, nothing. The
Gravis plays modules, midules and mp3 with nearly no problems (apart from when
Loreena Mc Kennith sings too high and too loud, I hear something that looks like
MP3 frames bounds, but I can't surely tell who's responsible for this - if the
Fraunhofer Institute or Linux Kernel)
root@ghost:/usr/src/linux# cat /proc/version
Linux version 2.2.18 (root@ghost) (gcc version 2.95.2.1 19991024 (release)) #14
Mon Jan 29 15:14:27 MET 2001
Clock
On Sun, Feb 04, 2001 at 12:07:28PM +0100, [email protected] wrote:
> The crackling is not dependent on the buffer size you can set up in the C code.
> The crackling is dependent on the frequency of the sine. It's clearly audible
> (read: annoying) at 10kHz, audible at 1kHz, inaudible at 100Hz. So I think
> they are sample dropouts - the card stops playing and repeats one sample until
> kernel gets the breath and whips itself up to supply next audio data.
hrm, i just ran your test progam. i don't hear this on my gus classic /
celeron 533 / 320mb ram. at least nothing that *sounds* like crackling.
just a high pitched annoying noise. using 2.4.1 + andrew morton's
lowlatency patches. (which are wonderful, thanks andrew!)
jiggle the cable from the GUS to wherever it goes to.
j.
Hi!
> I found that 2.2.18 probably rudely drops samples (lets ocassionally one sample
> be played several times) on the Gravis Ultrasound output device. I use 2.2.18
> and the native kernel drivers. I wrote this program that should produce a clean
> sine tone. Instead I hear a sine interspaced with crackling. The crackling
> repeats at 100Hz I guess. There runs nothing CPU-consuming. The sound process
> takes 5% CPU. It's funny Linux drops sound samples just at 5% of CPU load. I
> got AMD K6-2 3D 400Mhz at 400Mhz, 4*100MHz, running stably between 20-35 deg C
> of case temperature. I got PCI / AGP board FIC VA-503+. There are three serial
> ports, none of them was transceiving at that time. There is one ISA
> NE2000 NIC
And receiving?
There are tools for measuring latency problems. Look at kernel archives.
> The crackling is not dependent on the buffer size you can set up in the C code.
> The crackling is dependent on the frequency of the sine. It's clearly audible
> (read: annoying) at 10kHz, audible at 1kHz, inaudible at 100Hz. So I think
> they are sample dropouts - the card stops playing and repeats one sample until
> kernel gets the breath and whips itself up to supply next audio
> data.
Or it is just Graivs driver bug...
> There are no custom changes in the drivers - no buffer tweaking, nothing. The
> Gravis plays modules, midules and mp3 with nearly no problems (apart from when
> Loreena Mc Kennith sings too high and too loud, I hear something that looks like
> MP3 frames bounds, but I can't surely tell who's responsible for this - if the
> Fraunhofer Institute or Linux Kernel)
;) Or maybe problem is in your application. Can you generate sample
file than "play" it with cat samples > /dev/dsp? You can do it on
different machines to learn if it is gravis or something else.
Pavel
PS: I think it is your app that is buggy. You write to soundcard, then
you do _lots_ of floating point computation, then you write
again.... If your computtation takes too long, you'll hear
cracking... Of course. You wrote latency critical app!
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]