On Mon, Jan 7, 2013 at 6:05 AM, Ove Karlsen <
ove.karlsen@email-addr-hidden> 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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jan 7 16:15:03 2013
This archive was generated by hypermail 2.1.8 : Mon Jan 07 2013 - 16:15:03 EET