On 11 Dec 2001, Hans Meine wrote: > aRts uses more than just a different "nice value" - in fact it tries > to use no less than what standard OS provide. > > For what "realtime priority" means here, look at > "man sched_setscheduler".
I stand corrected! (well, kinda.. cause if that's linus's idea of "realtime" I want my Amiga back!! :-)) I did note that ALSA has this rtc hack which binds the rtc interrupt to itself. I don't read enough of the kernel mailing list to understand why this still has to be a patch or if there's any drive to make it standard, but it seems happy on my box, not that I noticed a difference! I mean, I don't mind if my apt install takes an extra few milliseconds to run but when XMMS starts sounding like someone's beating my computer with a stick it gets annoying! Or worse still - if I hit "fire" in a game and a bullet appears but the 'bang!' sound occurs 1/4 of a second later. buffers suck :-( It could be that XMMS needs to run as SCHED_FIFO too. I'm guessing that the reason it chops up with artsd but not when talking directly to /dev/dsp is to do with priority of different types of message (again, I'm not an expert on the kernel :-)) and the fact that artsd means there's two data streams instead of one. I suppose the best remedy for my problem is to try and persuade XMMS to talk to alsa0.9 in O_NONBLOCK mode alongside artsd. There's a 0.9 plugin already out but it doesn't work on my debian box and I haven't got round to hacking it yet.
