Re: [LAD] [ANN] ladspamm - a small c++ library for handling LADSPA plugins

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Ove Karlsen <ove.karlsen@...>
Cc: linux-audio-dev@lists.linuxaudio.org <linux-audio-dev@...>
Date: Monday, January 7, 2013 - 12:28 pm

--bcaec554d60ef5ed7104d2b1f671
Content-Type: text/plain; charset=ISO-8859-1

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

>

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

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

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

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

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.

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

what does this even mean?

>

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.

--bcaec554d60ef5ed7104d2b1f671
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, J=
an 7, 2013 at 6:05 AM, Ove Karlsen <ove.karlsen@paradoxuncr=
eated.com
> wrote:

What I think Linux audio needs is to combine efforts for professional and r=
egular users.linux is not OS X. the changes requi=
red in the audio "stack" to unify these two worlds would be rejec=
ted 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 Cor=
eAudio on all of its developers.
=A0
There seems to be little combined direction in linux audio. see above.=A0There are seve=
ral 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 r=
eally a "standard" especially given that it continues to recommen=
d 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 (nati=
ve) API within the last year? Why does VST exist when there was already a p=
lugin API present as part of DirectSound? LV2 is a honest, serious attempt =
to (a) tackle the problems caused by LADSPA's *intentional* focus on be=
ing SIMPLE (b) create an extensible API. it suffers from the fact that it i=
s documented in terms that are obscure and even confusing to most programme=
rs (including me) - i'm constantly amazed at how simple most of it is o=
nce 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.
=A0 And audiodrivers seem to vary in q=
uality, and you can get better results with alternatives less used.
when vendors write device drivers, you typically get the best poss=
ible results for a given device. when 3rd parties write device drivers, oft=
en simply using a specification (e.g. intel HDA) or worse, reverse engineer=
ing, 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 res=
ponsible for the entire codepath from the h/w to user space (i.e. PCI devic=
es).
=A0
What should be done is, rethink the whole audio signal path/stack with rega=
rds 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 eno=
ugh for most uses, the audio needs rethinking. I tried a brand-new USB Fire=
face UCX, in classcompliant mode, and it did not work at first, needed a pa=
tch,
welcome to the world of the linux firewire stack, which is develop=
ed and maintained without a lot of interest in the particular needs of audi=
o interfaces (though less and less so these days). note also that firewire =
audio interfaces are a dying breed (thanks apple!)
=A0and 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 re=
ally needs to be as good. And knowing MS engineering, it can easily be bett=
er.
why can it "easily be better" when at least=
half of the companies involved in providing the technology are not interes=
ted in enabling =A0=A0

What about a professional mixer, used system wide, where you can apply effe=
cts, eq, routing etc. Windows does not have this. nei=
ther does OS X (though this is starting to change, undocumented). and actua=
lly, windows *did* use to have this but it came with a 100msec latency pena=
lty.
we have a "professional mixer" where you can apply effects an=
d 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 r=
equirements of desktop applications, which is why pulseaudio exists. Pulsea=
udio does things that no "professional" mixer needs, but that are=
incredibly useful for consumer/desktop workflows.
=A0And a good plugin standard (atl=
east 64bit float). there is absolutely no evidence th=
at a 64 bit data path *between* processing stages creates any detectable im=
provement in audio quality. in fact, there are a few double blind tests tha=
t 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 th=
is on everything (at this point in time) is unnecessary and counter-product=
ive.

And things need to be quick and easy to use. No uneccesary mouseclicks. Loo=
k 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 tast=
es, 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 =A0d=
evelopment with application development. all the existing DAWs on linux (mu=
se, qtractor, rosegarden, traverso, non, ardour and others) welcome feedbac=
k on their GUI/workflow design. all DAWs on every platform have their own f=
laws and their own excellence. there are number of editing features in ardo=
ur, for example, that were designed by a long time professional logic user =
precisely because he was so tired of logic's approach to certain operat=
ions.
=A0
And what about trying to establish a universal soundplayback engine, with a=
tleast sampleaccurate timing.what does this even =
mean? =A0

Making a os-level mixer and sequencer, with the features expected by profes=
sional, but that also scales to normal users, with a "soundblaster&quo=
t; would be the optimal.and world peace with appl=
e pie and whipped cream for everyone.
those who don't remember the audio server wars of 1998-2003 are doo=
med to repeat them. sigh.

--bcaec554d60ef5ed7104d2b1f671--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] [ANN] ladspamm - a small c++ library for handling LADS..., Florian Paul Schmidt, (Mon Jan 7, 10:02 am)
Re: [LAD] [ANN] ladspamm - a small c++ library for handling ..., Florian Paul Schmidt, (Mon Jan 7, 12:37 pm)
Re: [LAD] [ANN] ladspamm - a small c++ library for handling ..., Paul Davis, (Mon Jan 7, 12:28 pm)
Re: [LAD] [ANN] ladspamm - a small c++ library for handling ..., Alexandre Prokoudine, (Mon Jan 7, 11:51 am)
Re: [LAD] [ANN] ladspamm - a small c++ library for handling ..., Alexandre Prokoudine, (Mon Jan 7, 12:46 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 12:57 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 1:01 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 2:04 pm)
Re: [LAD] , Vytautas Jancauskas, (Mon Jan 7, 1:27 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 2:25 pm)
Re: [LAD] , Brett McCoy, (Mon Jan 7, 2:35 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 2:46 pm)
Re: [LAD] , Paul Davis, (Mon Jan 7, 2:57 pm)
[LAD] , Marc-Olivier Barre, (Mon Jan 7, 6:49 pm)
Re: [LAD] , Dominique Michel, (Mon Jan 7, 7:45 pm)
Re: [LAD] List moderation, Robin Gareus, (Mon Jan 7, 7:08 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 3:39 pm)
Re: [LAD] , Patrick Shirkey, (Mon Jan 7, 2:53 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 3:24 pm)
Re: [LAD] , Dominique Michel, (Mon Jan 7, 5:12 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 5:15 pm)
Re: [LAD] , Nils Gey, (Mon Jan 7, 5:24 pm)
Re: [LAD] , Florian Paul Schmidt, (Mon Jan 7, 6:42 pm)
Re: [LAD] , Patrick Shirkey, (Mon Jan 7, 6:51 pm)
Re: [LAD] , Vytautas Jancauskas, (Mon Jan 7, 6:57 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 5:18 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 5:23 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 1:20 pm)
Re: [LAD] , Nils Gey, (Mon Jan 7, 3:38 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 3:41 pm)
Re: [LAD] , Neil C Smith, (Mon Jan 7, 3:46 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 3:48 pm)
Re: [LAD] , Vytautas Jancauskas, (Mon Jan 7, 4:21 pm)
Re: [LAD] , Patrick Shirkey, (Mon Jan 7, 4:42 pm)
Re: [LAD] , Fons Adriaensen, (Mon Jan 7, 5:10 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 5:13 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 5:08 pm)
Re: [LAD] , Patrick Shirkey, (Mon Jan 7, 5:19 pm)
Re: [LAD] , Alexandre Prokoudine, (Mon Jan 7, 4:47 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 5:10 pm)
Re: [LAD] , Charles Henry, (Mon Jan 7, 4:31 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 5:05 pm)
Re: [LAD] , Robin Gareus, (Mon Jan 7, 5:29 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 8:32 pm)
Re: [LAD] , Paul Giblock, (Mon Jan 7, 3:47 pm)
Re: [LAD] , Nils Gey, (Mon Jan 7, 3:45 pm)
Re: [LAD] , David Robillard, (Mon Jan 7, 3:28 pm)
Re: [LAD] , Ove Karlsen, (Mon Jan 7, 3:33 pm)