[Openal-devel] Additional patches...

[Chris Robinson]

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.