[Openal-devel] Additional patches...
chris.kcat at gmail.com
Tue Jul 24 12:25:39 PDT 2007
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
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.
More information about the Openal-devel