If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
While duplication of effort is generally a bad thing, I like judging by merit. If this ends up being superior to ALSA and PA, then rejoice; progress to the audio stack. Elsewise this implementation will simply remain niche and/or die out, and it may have taken manhours that could otherwise have been spent on existing systems (but that's not guaranteed).
I wonder, to what extent can existing drivers be ported to this?
1. Unless he wants to only support integer sample formats, this will never be allowed in the kernel, because Linus doesn't allow floating point in the kernel. I guess he'd have to resample any inbound floating point audio from programs in userspace before passing it to the kernel. But since the proposal is for directly accessing a character device, that sounds impossible. Good luck with that.
Yeah, chances of mainlining this is slim at best, and cards are really stacked against it if it wants to gain traction when being an out-of-tree system.
Also, OSS is a terrible API from the 90s that has no concept of modern ideas like power savings.
Well, the page does say that KLANG API is a superset of OSS API, with its extensions including power management support. From the page;
Originally posted by http://klang.eudyptula.org
Wait, doesn't OSS4 already provide all this
OSS4 provides mixing, resampling and splicing a signal from a source to a process. But OSS4 still treats audio HW and client processes accessing it as different kinds of citizens. In addition to that OSS4 has no support for power management and sequencer data (=MIDI)
KLANG is different. KLANG has full support for the available power management primitives. KLANG provides transport for non-sample data, like MIDI. And KLANG will integrate into the kernel's namespacing/container primitives.
The problem is that a "character device" is a concept unique to *NIX operating systems, so any OS that doesn't implement that concept is kinda screwed. A "C" API is pretty much a universal concept; all but 1 or 2 exotic OSes support that. So you can't talk about portability while saying "forget all OSes that don't derive their core design from UNIX".
Is this that big a problem? In its defense, it does mention being targeted toward Linux and FreeBSD kernels. (Moreover, to sate my curiosity, what open source OS nowadays isn't nix-like, or at least supports char devices?)
3. We don't need another solution. Period. We have too many already. It's way past the point where introducing new solutions is even remotely plausible. All this can possibly do is bring further fragmentation and brokenness to the Linux desktop, and add more headaches for application developers trying to support every system. Hopefully it does not gain any traction whatsoever.
My pragmatic self concedes to this, but my idealistic self just nods its head and says 'bring it.' Much like extraordinary claims demand extraordinary evidence, if this project can show that it's a better solution across the board, then I'm all for it. Until such time I'll stick with PA, but my door will stay open to new ideas. Moreover I imagine most applications will still use abstraction layers (SDL, gstreamer, etc), excepting stuff where realtime-level latencies are simply crucial.
4. Using the justification of being "annoyed" at PulseAudio is not a reason for starting a completely new project. Instead, improve on the things about PulseAudio that annoy you. Although I can't imagine what; I haven't even thought about sound infrastructure on my system for more than a year. I start up apps and they play sound. I don't see what there is to be annoyed about. Everything "just works" with no glitches/dropouts/etc, exactly like it was promised when PA started back in '06 / '07.
Can't argue here. My main gripe with PA is just that KDE doesn't implement its controls better, which isn't PA's fault at all. PA is great for my use-cases.
5. It'll take you a decade to develop all the hardware support needed to be even competitive with OSS4, let alone ALSA. Audio drivers can't ever be pure and simple; they necessarily have to come with tons of ASIC-specific hacks and workarounds, because hardware manufacturers like to add little tweaks to break your driver, like changing pinouts, etc. It's part of the territory. It takes a ridiculous amount of manpower to develop and maintain all those workarounds. One person isn't going to cut it. All the traction is already with ALSA. All the success is already with ALSA.
This is an interesting problem. Can ALSA drivers be ported to KLANG, keeping the hardware interface but changing what it exposes to the kernel?
This thing is just stupid. It's like going on a 500 mile trip in the car, traveling 498 miles to your destination, then say "oh $@(# I meant to take a train, not a car, this sucks", then drive all the way back home and get on a train to go there again. What a terrible waste of manpower.
Well, to be a bit more fair, it's more like seeing everyone else taking long trips in their gasoline-powered cars, and thinking "hm, can't we use this new cheap diesel I'm envisioning and cut costs?". New car engines would have to be developed, but assuming ALSA drivers can be ported with reasonable effort, the rest of the car can stay the same.
The OS X kernel has RT facilities. But you're missing the point: you don't need RT for this. The reason why RT is used in Linux for audio just shows the problems the audio stack has. RT is not needed, unless you're doing something wrong in the audio infrastructure.
From experience I know that a task like this can not be taken lightly. I've been developing a lightweight 3D audio library for years and only recently it got in a state I find acceptable (but maybe I've got too high standards). It's called AeonWave and is available for Linux and Windows now: http://www.adalin.com
Although it is not Freeware, it is cheap and a royalty free (but limited) version of the library is available.
I am a fan of Free and Open Source software though (hence the many open source side projects and more to come).
This project was started out of frustration for the state of OpenAL-Sample years ago (and in some ways still today with OpenAL-Soft) and renders about 6 times faster than both. As time passed proper stereo mixing and effects supports has been added as well as support for audio-frames which can be used for sub-mixing and to move multiple sound emitters around simultaneously in a 3d environment.
This library however is not meant to be a replacement for ALSA, PulseAudio or OSS but instead it simply uses one of them as a backend. I really wouldn't want to think of this much code added the the kernel..
Personally I think the library fills a gap that both OS-X and Windows already have a solution for and the fact that it can render (3d) audio up to 7 times faster (and I see some room for more improvement) and can be setup for latencies as low as 2 msec means it is well thought out in my honest opinion.
Sounds good architecture decisions except for the use of OSS.
A company tried to blackmail Linux with OSS API, that's why it is being replaced by ALSA.
The company simply did not release some improvements. People were free to implement those on their own. The creation of ALSA was far more than was necessary and wasted resources that could have went into making other things better.
NASA launches a rocket carrying a satellite. The rocket explodes 10 seconds after liftoff. 1 billion dollars wasted. Someone says: "It exploded, something went wrong!" 89c51 says: "Explain what's wrong then." Someone answers: "I've no idea!" 89c51 says: "See? Nothing's wrong. Everything is OK."
89c51 was fired soon after.
The differrence is that the audio stack doesn't explode or destroy 1 billion dollars of stuff. You dodged the question because you actually know what the answer is: there is nothing wrong with the linux audio stack. Having Real Time priority will allow any type of process to get more done in a given time frame, so it naturally helps audio stuff which has a strict deadline. That being said, it is prefectly possible to do audio stuff on a stock kernel. I generally have between 8 and 32ms latency, depending on how much processor intensive stuff I am doing. I use the stock kernel as I can't be bothered to install a RT one. Judging from the conversations that I have seen on #opensourcemusicians on freenode (people who have some idea how audio works under linux :P) using a RT kernel isn't even the most common approach.
Next time you say something is broken at least be able to tell why you believe this (the rocket because it exploded, a car because it crashed, etc.)
"professional grade audio, that means lowest possible latency, latency compensation and bit exact precision at a very low CPU load. KLANG has been designed as a signal routing system, supporting seamless and transparent signal transport between all endpoints.
Isn't this what ALL the other sound systems have been trying to do? They have all failed.
ALSA has worked fine for me for as long as I can remember. I don't want another square wheel.