Re: Kernel Level Audio Next Generation
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
Re: Kernel Level Audio Next Generation
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
[na...@mips.inka.de: Re: Kernel Level Audio Next Generation]
It is "clever" in Norwegian as well and remindes me of "Kling Klang Studio" which is the private recording studio of Kraftwerk. Anyway, I think such names are unsuitable for kernel level IO functionality and really like the approach OpenBSD has chosen in it's naming conventions. Sndio makes a lot more sense than "PulseAudio" or "Klang" - the latter being more suitable for some more or less fancy music players. - Forwarded message from Christian Weisgerber - Date: Thu, 2 Aug 2012 20:12:36 + (UTC) From: Christian Weisgerber To: misc@openbsd.org Subject: Re: Kernel Level Audio Next Generation Alexey Suslikov wrote: > http://klang.eudyptula.org/ Well, if nothing else the project has a clever name--if you know German.
Re: Kernel Level Audio Next Generation
Alexey Suslikov wrote: > http://klang.eudyptula.org/ Well, if nothing else the project has a clever name--if you know German. > Just curious, why they didn't even try to evaluate OpenBSD sndio. You should ask the author, not us. Also, that text doesn't definitely say that he didn't look at sndio. And if in fact he didn't, it's probably because he didn't know about it. > 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. ratchov@ disagrees. :-) The argument that the real-time requirements of audio call for a kernel implementation isn't without merit. On the other hand, other than routing, an audio system is also expected to offer a number of transformations. Do you really want to put all this into the kernel? (1) Conversion of sample formats: 8/16/24/... bits, signed/unsigned, endianness, possibly integer/float. (2) Resampling. There is no single perfect algorithm for this. See the description of sox's "rate" effect for hints of the issues involved that you probably never heard about: http://sox.sourceforge.net/sox.html (3) Mixing of several audio streams. This can get tricky. Streams in different formats--see (1), (2)--and potentially different numbers of channels need to be normalized; you want to avoid clipping but not sacrifice dynamic range, which are conflicting goals. For bonus points, if somebody wants to implement a new audio system, ask them about their intentions for dealing with compressed audio (think AC3/DTS). *shrug* -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Kernel Level Audio Next Generation
i particularly enjoy the part where an opposing spectator conflated gdm with the only way to deal with handicapped users. he also proceeded to discredit the talker by stating that he hated the handicapped, even though that couldn't possibly be inferred from the presentation thus far. not only did you fail to recognize his drama queen tactics, you're also implying that klang is the conclusion of a personal vendetta against lennart after the most boring pissing fight ever. everybody involved in that petty exchange are jokers, including the audience who somehow didn't realize they were being manipulated with a picture of a three legged puppy. On Wed, Aug 1, 2012 at 4:25 PM, Tobias Ulmer wrote: > On Tue, Jul 31, 2012 at 10:46:57PM +0300, Alexey Suslikov wrote: >> Hello misc. >> >> http://klang.eudyptula.org/ > > Heh, that's by the guy who got his ass whooped by Lennart at 27c3. His > talk made me cringe... > > After watching, you may understand why he's writing his own stuff > instead of using the awesome PulseAudio. > >> >> Just curious, why they didn't even try to evaluate OpenBSD sndio. > > Because he's a Linux fanboi, isn't that obvious? :) > >> >> 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. >> >> What people think? Maybe we should write an article for wikipedia >> to make sndio more visible to rest of the world? > > I think it's pretty pointless to document an audio system that's only > available on OpenBSD. Maybe add it to the main OpenBSD article if it > isn't mentioned there already. > >> >> Regards, >> Alexey
Re: Kernel Level Audio Next Generation
On Wed, Aug 01, 2012 at 10:55:36PM +0200, Tobias Ulmer wrote: > [...] > Heh, that's by the guy who got his ass whooped by Lennart at 27c3. His > talk made me cringe... > [...] Hehe, I also though "wait a second... that name is familiar". I remember the mixture of pain (because I kinda felt sorry for the poor bastard) and pleasure (because he got what he deserved) when I was sitting in that audience. > [...] -- Gregor Best [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Kernel Level Audio Next Generation
On Wed, 01 Aug 2012 15:55:36 -0500, Tobias Ulmer wrote: After watching, you may understand why he's writing his own stuff instead of using the awesome PulseAudio. I really hope you're using the word "awesome" in an ironic / sarcastic way
Re: Kernel Level Audio Next Generation
On Tue, Jul 31, 2012 at 10:46:57PM +0300, Alexey Suslikov wrote: > Hello misc. > > http://klang.eudyptula.org/ Heh, that's by the guy who got his ass whooped by Lennart at 27c3. His talk made me cringe... After watching, you may understand why he's writing his own stuff instead of using the awesome PulseAudio. > > Just curious, why they didn't even try to evaluate OpenBSD sndio. Because he's a Linux fanboi, isn't that obvious? :) > > 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. > > What people think? Maybe we should write an article for wikipedia > to make sndio more visible to rest of the world? I think it's pretty pointless to document an audio system that's only available on OpenBSD. Maybe add it to the main OpenBSD article if it isn't mentioned there already. > > Regards, > Alexey
Kernel Level Audio Next Generation
Hello misc. http://klang.eudyptula.org/ 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. What people think? Maybe we should write an article for wikipedia to make sndio more visible to rest of the world? Regards, Alexey
