From: Pavel Machek <pavel@suse.cz>
To: clock@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org
Subject: Re: Inadmissible sound dropouts on 2.2.18
Date: Sat, 10 Feb 2001 23:32:55 +0100 [thread overview]
Message-ID: <20010210233255.H7877@bug.ucw.cz> (raw)
In-Reply-To: <20010204120728.48319@ghost.btnet.cz>
In-Reply-To: <20010204120728.48319@ghost.btnet.cz>; from clock@ghost.btnet.cz on Sun, Feb 04, 2001 at 12:07:28PM +0100
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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2001-02-11 10:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-04 11:07 Inadmissible sound dropouts on 2.2.18 clock
2001-02-04 12:43 ` john slee
2001-02-10 22:32 ` Pavel Machek [this message]
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=20010210233255.H7877@bug.ucw.cz \
--to=pavel@suse.cz \
--cc=clock@atrey.karlin.mff.cuni.cz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.