Hi!
On Mon, Dec 10, 2001 at 12:28:10PM +0000, Giles Constant wrote:
> On Wed, 5 Dec 2001, Stefan Westerfeld wrote:
> > /dev/rtc doesn't have to do anything with the scheduling priority. You need
>
> er..but scheduling priority has nothing to do with realtime. Setting a
> different "nice value" just means the process gets more attention than
> user processes. Disk access is a kernel process and disk access is
> causing the music too chop up because it's getting priority over artsd!
>
> The ALSA driver uses a kernel patch which provides realtime callback
> support which actually binds realtime clock signals to alsa processes.
>
> Can't artsd use this?
Using that wouldn't fix your problems.
There are two differnt things here, which have nothing to do with each other:
1. Timing (which is what /dev/rtc is about): the linux kernel provides a timer
resolution of 10ms, and even at that it is quite unreliable. If you're doing
midi output, and you try to output the events of a song using /dev/midi and
the linux kernel driver, you will end up with a 10ms jitter. Which might be
unacceptable. So you might want to use /dev/rtc to fix the timer precision.
2. Reliable realtime sound production: which we might define as "we create
sound while it is played" (so this is "real time"), using a certain amount
of preproduction of audio, which will get buffered by the hardware. For this
it is necessary that once free space gets available, we'll be called back from
the kernel fast enough, so that no underrun (dropout) occurs.
aRts competes with two things here: other applications and kernel drivers.
While artswrapper fixes the first source of trouble, it doesn't fix the second.
Neither does using /dev/rtc, because IF disk I/O blocks inside the kernel as
long as 500ms (which might happen with IDE non-dma disk access), then if aRts
had buffered only 250ms of audio, the kernel will not consider calling aRts
for 500ms, and a dropout will occur.
In such cases, using the lowlatency patches available for the kernel might
bring an improvement, as it's not really an aRts problem that aRts doesn't
get called here, but a kernel problem (or even hardware problem, which might
lock up the PCI bus for 500ms, in which case neither the kernel nor aRts
can do anything to prevent this).
Dropouts might also be caused by poorly implemented drivers (which is what
you're seeing a lot with OSS drivers), which don't correctly understand or
implement non-blocking I/O. Such might be fixed with the 'toss' threaded
audio output method that will be available optionally in the next release
of aRts.
Quite a few users are seeing problems that artsd is producing dropouts with
the standard 'oss' audio output method, but works nicely with 'toss'.
> > to run artswrapper (which must be installed suid root) to get artsd running
> > with realtime priority.
>
> I don't think you mean "realtime" here, unless I've missed something?
Oh well, "realtime" is probably a minefield in computer terminology, which
might be something else for some people, but given the definition that artsd
needs to create data while it is played with certain restrictions given on
when it needs to happen I find it practical to call that a "realtime"
problem, and if you read "man 2 nice" and "man sched_setscheduler", I find
it practical to call the effect of first one "high priority" and the effect
of the second one "realtime priority".
Cu... Stefan
--
-* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
