[Openal-devel] Additional patches...

[Chris Robinson]

On Tuesday 24 July 2007 08:43:53 am you wrote:
> To me, unless there's a way to do this for any normal user, a better
> solution would be to increase the mixer's buffer sizes so that it runs
> reliably.  Then, we can work on making it more efficient and get the
> latency down.

The mixer buffer can't really go much larger, I fear. Although I'd wager to 
bet it's large enough, just that the mixer itself needs to be fixed (perhaps 
I'm underestimating the compiler's optimizer, but I really think the code is 
that bad). That is definitely the best and safest bet, but even when the 
mixer can be cleaned up, anything that can't preempt most other threads will 
still have trouble when the CPU gets under heavy load (as intensive 3D games 
tend to do, at least).

> FWIW, I took a peek at the Windows implementation, and it doesn't seem
> to try to adjust process or thread priorities anywhere (I was a little
> surprised by this). I doubt the Windows scheduler is that much more
> efficient than Linux's.

The OpenAL driver for Windows can use DirectSound acceleration, which will use 
hardware mixing when possible (pre-Vista, anyway). I'm sure DirectSound 
itself can use a software mixer, which would likely be boosted. I'm not sure 
the SI would perform at all better under Windows as it does under Linux.

Scheduling in Windows seems to work on discrete priorities. A process is 
explicitly given a priority class, and each thread has an explicit priority 
level.. these two are used to give each thread a priority between 0 and 30. 
Windows will start at the top, looking for any threads with a priority of 30 
waiting to run, if it finds none, checks 29, etc. until it finds a thread 
waiting to run. Any thread with a priority level lower will be blocked until 
all higher priority threads are asleep/blocked. If there's more than one 
thread on the same priority waiting to run, it assigns them typical time 
slices and does round-robin style scheduling (this is in fact exactly how 
SCHED_RR works; except that it takes a single per-thread value, not a process 
priority class and a thread priority level). There's no dynamic scheduling by 
default.. what's set, stays.

Also, time-critical thread priority automatically puts it near the top. 
Time-critical threads always preempt non-time-critical threads regardless of 
priority class, except the realtime priority class (not the same thing as 
Linux's realtime priority). The realtime priority class in Windows should 
never be used except for things that do direct hardware IO and can't handle 
much interruption, as it even blocks kernel-level stuff from running.

> That's one concern.  My concern is just that for any kind of
> organization (individual users aren't really affected by this) no one in
> charge of that organization is going to permit regular users the kind of
> access needed to raise a process's or thread's priority.  There are
> security concerns, and there's simply the fact that no sysadmin wants to
> take the time to deviate a lot from a standard install of a distribution.

That's true, however Linux has been gaining more useage as a single-user 
desktop system, where the user has full control over these options. And I'd 
arguably say that OpenAL is primarilly an audio API for gaming, which is 
dominated mostly by single-user desktops. Of course that's not the only use 
for OpenAL, especially for an OS like Linux, and I'd never say it couldn't be 
be used for more practical or production-environment purposes.. nor am I 
saying such uses should be neglected. Just that a sizeable portion of 
OpenAL's target audience would benefit from something such as this.

> Because of this, I think we need to figure out a way to fix this for all
> users, not just those that might have access to root privileges.  I
> suppose we could commit the rtprio patch as a stopgap, but I'd hate for
> it to quell any interest on getting the mixer more efficient just
> because "it works for me".

Yeah, I suppose I can understand that. But at the same time, it currently 
doesn't work when the CPU is put under load. It wouldn't be much of a problem 
to leave it as it is for now I guess, as it's not any worse than before. Make 
a release without the patch, cleanup the mixer, then see how it reacts with 
CFS. Decide what to do then.

> (BTW, I realize lately you're the one writing all the code, so I'm not
> in much of a position to make demands.  I'm just not convinced that this
> is a viable solution in the long term.)

I believe the long term solution is to explicitly raise the priority level of 
the thread.. something to tell the system that it's more time sensitive than 
most other threads on the system, and to run it when it needs to run. Other 
than leaving it to the scheduler to properly guess that the mixer thread is 
like that, the best way to do it is to select a scheduler that gives what it 
needs (unfortunately POSIX doesn't have a way to change thread priorities 
outside of changing the scheduler; and there's only three viable schedulers.. 
two are "realtime", and the third is default).

> Again, I don't believe that most sysadmins would be favorable to this
> kind of thing in the security-crazed world we now live in.

True, it's hardly an all-encompassing solution.. but it's the best one I can 
come up with, given what I know about how prioritizing works. Cleaning up the 
mixer will definitely help, but again, it can only go so far since it's 
nature is counter to the fairness the default scheduler attempts to achieve 
(CPU usage by the thread will become greater as more sources are mixed and 
effects added, but it needs to remain time-critical).

> I didn't mean short-running task in any formal sense.  The CFS simply
> works to guarantee that all processes receive the same amount of CPU
> time.

But still, a mixer needs to get more CPU time as more time is required to do 
the mixing, not receive the same amount or less. And if the number of threads 
vying for the CPU increases, the mixer needs to have first-call (or close to 
it) on the CPU.