On Mon, Jan 7, 2013 at 6:05 AM, Ove Karlsen <ove.karlsen@paradoxuncreated.com> wrote:

What I think Linux audio needs is to combine efforts for professional and regular users.

linux is not OS X. the changes required in the audio "stack" to unify these two worlds would be rejected by a huge chunk of the developers on linux. there is no stick available to force them to adapt, as apple did in the 1990's when it imposed CoreAudio on all of its developers.
 
There seems to be little combined direction in linux audio.

see above.
 
There are several standards, and nobody really seems to care much for them.

most developers using JACK seem very content with it. the quibbles seem generally to be about edge cases with the API. pulseaudio isn't really a "standard" especially given that it continues to recommend that developers use the ALSA API and not the one that PA itself provides. as for plugin APIs, it is not as if the proprietary world can be cited as an example of convergence on The One Truth. Why does AU exist on OS X when there was already VST? Why did digidesign announce its own new plugin (native) API within the last year? Why does VST exist when there was already a plugin API present as part of DirectSound? LV2 is a honest, serious attempt to (a) tackle the problems caused by LADSPA's *intentional* focus on being SIMPLE (b) create an extensible API. it suffers from the fact that it is documented in terms that are obscure and even confusing to most programmers (including me) - i'm constantly amazed at how simple most of it is once you see a real example of just about anything - but like each and every plugin API before (and after) it, it will have its fans and its detractors no matter what.
 
And audiodrivers seem to vary in quality, and you can get better results with alternatives less used.

when vendors write device drivers, you typically get the best possible results for a given device. when 3rd parties write device drivers, often simply using a specification (e.g. intel HDA) or worse, reverse engineering, its absurd to expect the same level of functionality. the drivers for devices whose vendors have actively supported their development are as good as those on any other platform, particularly those where the driver is responsible for the entire codepath from the h/w to user space (i.e. PCI devices).
 
What should be done is, rethink the whole audio signal path/stack with regards to the lowest possible latency. Audio is one of the places, one really cares about low latency. While latency on the linux kernel now, is good enough for most uses, the audio needs rethinking. I tried a brand-new USB Fireface UCX, in classcompliant mode, and it did not work at first, needed a patch,

welcome to the world of the linux firewire stack, which is developed and maintained without a lot of interest in the particular needs of audio interfaces (though less and less so these days). note also that firewire audio interfaces are a dying breed (thanks apple!)
 
and then only got 5ms latency. And I have run 0.33 ms with a firewire card. Looking at this from a high-level perspective it seems to be a software problem. On windows, it works without a problem, and with 1ms latency, with the firewire drivers. Linux audio really needs to be as good. And knowing MS engineering, it can easily be better.

why can it "easily be better" when at least half of the companies involved in providing the technology are not interested in enabling  
 
What about a professional mixer, used system wide, where you can apply effects, eq, routing etc. Windows does not have this.

neither does OS X (though this is starting to change, undocumented). and actually, windows *did* use to have this but it came with a 100msec latency penalty.

we have a "professional mixer" where you can apply effects and routing on Linux (and we also "gave" it to OS X and to a lesser extent, WIndows too), but it does not run in kernel space. because of the issues i alluded to earlier, it also is not capable of supporting all the requirements of desktop applications, which is why pulseaudio exists. Pulseaudio does things that no "professional" mixer needs, but that are incredibly useful for consumer/desktop workflows.

 
And a good plugin standard (atleast 64bit float).

there is absolutely no evidence that a 64 bit data path *between* processing stages creates any detectable improvement in audio quality. in fact, there are a few double blind tests that show that it makes no difference whatsoever. with any plugin API, plugins are free to use whatever data format they wish to. there are not many DSP algorithms that are improved by using a 64 bit data format, so enforcing this on everything (at this point in time) is unnecessary and counter-productive.

And things need to be quick and easy to use. No uneccesary mouseclicks. Look at Logic audio, maybe 5.5.1 on windows, it can be very fast to use. Later versions on mac are also good, but to be honest, a bit bloated for my tastes, and they also reduced the control rate on some stuff there, which I did not like at all.

you now seem to be mixing up kernel/system-level  development with application development. all the existing DAWs on linux (muse, qtractor, rosegarden, traverso, non, ardour and others) welcome feedback on their GUI/workflow design. all DAWs on every platform have their own flaws and their own excellence. there are number of editing features in ardour, for example, that were designed by a long time professional logic user precisely because he was so tired of logic's approach to certain operations.
 
And what about trying to establish a universal soundplayback engine, with atleast sampleaccurate timing.

what does this even mean?
 

Making a os-level mixer and sequencer, with the features expected by professional, but that also scales to normal users, with a "soundblaster" would be the optimal.

and world peace with apple pie and whipped cream for everyone.

those who don't remember the audio server wars of 1998-2003 are doomed to repeat them. sigh.