[Openal-devel] Additional patches...
chris.kcat at gmail.com
Mon Jul 23 10:44:15 PDT 2007
On Monday 23 July 2007 10:06:11 am you wrote:
> Chris Robinson wrote:
> > It'll also work if you use the realtime-lsm kernel module or a patched
> > PAM, and give the user/group running the program a non-0 rtprio limit.
> Which is also something not a lot of sysadmins would be willing to do.
> This method is fine for single users running their own systems, but not
> for businesses or other sites that are set up in an organized way. (My
> supervisor would never go for it, for example). Any deviation from a
> standard distro install is going to be hard for some places to deal with.
True, however the patch can silently fail. If the user can't/isn't allowed to
set a rt thread, the function will fail but the mixer will all continue on
normally as if nothing happened.. just without rt priority.
> That said, it does make sense for the mixer thread to be real-time, so
> I'm still open to ideas...
I think the concern is a valid one, though. Under normal circumstances, I
haven't had any issues, although one time recently while debugging I had the
system lock on me from a crash in a realtime thread, and another while I was
testing the DSound backend under Wine (which was the cause for me to send the
_alMicroSleep patch). Those have been the only two occurances ever, though.
There is apparently a watchdog program that can be set up to catch runway
realtime threads like that, but I don't have it installed (which I suppose I
should fix that). The magic sysrq commands were functional, but it still left
me needing to reboot.
It's a tricky situation. I'm not sure I know enough about scheduling and
timing to be able to set up a custom watchdog thread in OpenAL to keep an eye
on the mixer. Though the rt thread could also be set up optionally, so like
if the external watchdog program is detected, it'll set the thread to
realtime.. but not otherwise (and/or perhaps a .openalrc setting to force
it). I'm just not sure how to reliably check for the running program.
> > You may
> > even be able to do it through ulimit -r and .bashrc, but I've not tried.
> ulimit -r doesn't seem to like negative arguments (it tries to read it
> as another option)
You need to set a positive argument. It's 0 to 99, I believe (0 meaning the
user can't set rt threads, others meaning the user can set a rt thread with a
priority up to that value). So the line would be:
ulimit -r 1
> > Latency is already pretty bad (~90ms for me, apparently).. though the
> > mixer is rather inefficient in several places, which I do plan to address
> > after a release can be made (hopefully after the new capture stuff is
> > committed). Fixing the inefficiencies can help, but it still can only go
> > so far.
> Yeah, that's not good. I wonder, though, if it would necessarily have
> to get much worse to address the problem. If it goes up to 100ms, but
> it fixes the problem, would that be more desirable?
I'd personally have to hear it to know for sure. And it may depend on the
program. It honestly doesn't sound too bad currently, but I don't imagine it
being able to go much higher before you can really start to tell (and audio
synchronization is something that drives me nuts if I can tell it's off).
> From what I've read (which admittedly isn't much), higher priority
> means more CPU time. If you're a short-running task like the mixer
> would be, you'd basically get the CPU more often with a higher priority.
I don't really think OpenAL's mixer can be classified as a short-running task,
though.. I'd imagine it can be pretty hefty, especially with multiple sources
playing. My system's been able to cope with the help of realtime priority,
but still.. there's quite a lot of redundancy and inefficient data handling
going on there. Without the rt priority patch, it doesn't take much for the
audio to start stuttering, and the more load the system is put under, the
less likely any non-realtime method will be enough.
More information about the Openal-devel