Subject: [linux-audio-dev] SCHED_FIFO machine stalls
From: Alexander König (alex_AT_rhlx01.fht-esslingen.de)
Date: pe joulu 10 1999 - 12:32:12 EST
Hi,
I'm currently doing some terminatorX hacking and ran in to some
problems:
I use two (p)threads: one for the gtk+-GUI and one for audio rendering.
As tX has to be near-realtime I have to use really small buffer sizes
(playback is done via write() to /dev/dsp). Now if both threads run with
the same priority operating the GUI causes a lot of audio-dropouts
(especially when using them beautiful gtk+-pixmap-themes ;) Which is why
I decided to use some scheduling-stuff. Now what I do is this:
After creating the audio-thread the GUI-thread task-priority is set to
20 via setpriority(). With pthread_attr_setschedpolicy() the
audio-thread is run with SCHED_FIFO-policy. Additionally I do a
setpriority() to level -20 although this possibly doesn't make much
difference I guess it won't hurt.
The good news is: it actually works! I love this Kernel ;) The
GUI-thread does painting at 486-speed but it doens't hurt the
audio-thread anymore (Although I still get rare audio-dropouts (no
matter whether the GUI-thread is busy or not)). But: running as root (==
with the code described above enabled) tX sometimes causes system
stalls. At first I thought that the cause of this might be some
pthread_mutex-deadlocks() but I guess these should occur in normal
operation mode (not messing with the scheduler at all) too, shouldn't
they?
Well, anyway this problem is somewhat hard to debug so I could really
use some suggestions ;)
Oh, btw, I use a plain 2.2.13 currently.
Bye,
Alex
--
_______________________________________________________________________
Alexander König - alex_AT_42.fht-esslingen.de
http://termX.cjb.net
[From the Homer Quotables:]
If it'll make you feel any better, I've learned that life is one
crushing defeat after another until you just wish Flanders was dead.
-- Homer Simpson
Homer and Apu
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST