On 08/05/2012 06:02 AM, Alexandre Ratchov wrote:
On Tue, Jul 31, 2012 at 10:46:57PM +0300, Alexey Suslikov wrote:
Hello misc.
http://klang.eudyptula.org/
very interesting ideas.
Just curious, why they didn't even try to evaluate OpenBSD sndio.
An overall approach to the problem is interesting thing too
Q: Why a audio system in the kernel?
A: Because it's the only reasonable thing to do.
IMHO it's not important; both kernel-mode and user-mode approaches
can work, neither seems "better". Both have their advantages.
kernel-mode is thought to be better with respect to underruns, but
that's not 100% true. Trying to explain. Underruns occur whenever
an element in the audio processing chain doesn't complete its work
before the deadline imposed by the hardware. This chain includes
the audio player, which necessarily runs in user mode. Thus we have
to get right audio programs (user-mode) first to avoid underruns.
If you're able to write audio programs that don't underrun, then
you're also able to write an audio daemon that doesn't underrun. No
need to put the audio system in the kernel in this case.
If you're unable to write audio programs that don't underrun, audio
will stutter, and putting the audio system in the kernel won't fix
stuttering, so no need to put the audio system in the kernel
either.
AFAICS, the main advantage of a kernel-mode implementation is to
avoid the overhead of extra context switches. In the current sndio
implementation the overhead of context switches is negligible
compared to audio processing.
The choice of moving parts of the OpenBSD audio sub-system out of
the kernel is mostly for practical reasons; having less code with
kernel privileges seems sane as well; A kind of "if a program
doesn't need kernel privileges then put it in user mode" principle.
What people think? Maybe we should write an article for wikipedia
to make sndio more visible to rest of the world?
Sure
-- Alexandre
Yes, no, maybe, your mileage may vary...
There are two separate issues here: throughput/bandwidth and latency.
Confusing these is a very common misconception.
You can have all the bandwidth (CPU & disk) in the world, but if
program latency > (buffer size / sample rate), you will have over/underruns.
If (buffer size / sample rate) is too large, then it is possible that
there will be large latencies when starting & stopping, etc.
To have a system which is agile and does not over/underrun, the
hardware should be controlled by a pair of functionalities:
1) a kernel function or a process running at real-time guaranteed
latency priority which directly controls the hardware.
2) a user process running at a lower priority but one higher
than processes doing interruptible long-running tasks.
Its latency must be controlled as well as possible.
Functionality #1 must never use a blocking system call except
a poll/select or something similar. It should use a hardware
buffer sized for the best compromise between desired responsiveness
and CPU usage tending the buffers.
This process/kernel function should then talk to functionality #2
using buffers sized for the greater latency of the non-real-time process.
Functionality #2 can control the hardware quickly via the real-time function
yet it can buffer large quantities of data for efficient use of its
resources
and to compensate for large latency.
This process must run at a priority sufficiently high to take precedence
over updating the screen or other indefinitely CPU-intensive tasks.
It does format conversion, resampling, and other tasks which consume
relatively large amounts of CPU or memory.
It is often helpful to store audio on a dedicated disk to reduce or
eliminate queueing delays.
I've implemented such an architecture on a 1 MIPS machine handling
16 in and 16 out channels simultaneously. The bottleneck was the disk drive.
Applications of this type almost always work best when engineered throughout
with reducing latency as the top priority. Current CPUs and disks are
capable of handling a huge number of audio channels if properly used.
I.e. get the video out of the way, ensure low interrupt latency by
eliminating all kernel spins or indefinitely long loops with interrupts
blocked, etc.
Geoff Steckel
