Perhaps you don't understand that I wrote the software that makes running Windows VST plugins on Linux possible (along with Ardour and JACK). Audacity uses Wine too, but in a different way than Ardour because we care about scaling, and the Audacity approach (running plugins in a different (Wine-controlled) process doesn't scale in the way that an actual DAW (intended to be use with hundreds of tracks and hundreds of plugins) requires.
In general, audio technology companies do not make very much money. Digidesign is almost close to bankruptcy, and laid off the bulk of its engineering staff. When Yamaha purchased Steinberg, it cost then a few tens of millions of dollars - for the number 2 company in the industry at that time. Most new audio technology companies fail within a few years. The recording industry does NOT pay significant cash to "well funded teams of software engineers" for this technology, which is one of the reasons why companies like Digi are having a hard time (along with their older cousins, the makers of large-format consoles, which are also no longer a line item in most budgets). The recording industry does not function like the video industry, and hasn't for more than a decade, if they ever did.
Probably the most successful audio software company right now is Ableton, and they've created an entirely new workflow for music creation, entirely over the opposition and disbelief of people with years of experience on more traditional DAWs. Another example might be Waves Audio, who have significantly diversified their products and focus from their traditional plugin-centric approach, again reflecting changes in what people will and will not spend money on (hint: broadcast and live PA work are now significantly more cash-flow endowed than recording).
What the linux audio software lacks is not funding from the recording industry (and note that Ardour is already the basis of products from Waves Audio and Harrison Consoles), but enough paying users, which in turn is a reflection of what happens when you develop for a tiny niche inside of an already niche software environment.
1) Quite a few manufacturers choose not to use the USB audio class specification 2) I can't write the software fast enough. Ardour has taken up 16 years of my life already, with a huge amount of help from other people.
If companies adhere to the USB standards, then stuff just works. That's why you can plug a Behringer (Midas, really) X32 into a Linux system and it all just works. All of it.
PulseAudio is nothing like WDM on Windows, in any sense at all.
Your "one system for everyone (CoreAudio on OS X)" is also true on Linux too. The issue is the presence of "middleware", such as PulseAudio or JACK. But JACK provides functionality that is not possible with just CoreAudio (interapplication audio, shared transport control and more), so the comparison is a bit more complex.
And by the way, if low latency is the primary metric for measuring the quality of an audio system, then ALSA still wins.
And finally, almost all new audio interfaces use USB, and almost all of them are class compliant, which means that the manufacturer doesn't write a driver at all. One driver, all applications, all Windows, OS X and Linux.
There are LOTS of multichannel USB audio interfaces that work perfectly on Linux. What matters is whether the devices correspond to the USB audio class specification, which is also equivalent to asking whether they come with their own drivers for OS X and Windows. No drivers? They will work on Linux.
I suppose it is just too hard these days to imagine recording music (the question was about a home RECORDING studio) as actually meaning RECORDING musicians performing on instruments.
I can assure you that there are plenty of people using Linux to do that, without the issues you're describing above. I'm also going to assume that you live in the USA, because if you lived in Europe (notably Germany) I think your perception of Linux would be quite different.
As the primary author of Ardour, I can point you at a dozen people who do this kind of recording with Ardour at least weekly. I can even point you (anonymously, alas) at a major UK-based mobile recording truck service that is now installing Ardour as its secondary recording systems, in scenarios that typically involve recording at least 72 tracks at once. Yeah, it would be nice if it was the primary system, but I'm patient. After all, its only been about 6 months since the last/. flamefest that declared that Ardour could not do , or....
nobody agrees on (a) what the subsystem should do (b) what API it should have (c) how it should be enforced.
your description of your problems with JACK doesn't match any of the user experiences i've heard about for the last several years. perhaps you should be providing bug reports, feedback and other useful to the JACK development community rather than just commenting about it on/. ?
i wrote JACK (originally, and with help from many others) by the way.,
what do you consider "top end hardware interfaces"?
RME HDSP and MADI interfaces, the choice of most highly-multichannel configurations worldwide, work perfectly on Linux and have done for a long time. Perhaps you are one of those who believe that firewire devices are "high end"?
Nobody who is serious about audio production attempts to sync two audio interfaces without an explicit sample clock (aka "word clock") sync connection. Whether this is done implicitly, as is possible with firewire based interfaces, or via an additional coax cable with suitable termination on a PCI card doesn't matter: you don't get sync out of two separate clocks without resampling, which is the enemy. You can even take out your soldering iron if you want and run a wire between two el-cheapo consumer interfaces. Not recommended for beginners.
People commenting on technical matters that they know less about than they make it sound: $0.02 People commenting on technical matters and honestly reflecting their knowledge level: $10.00 People who actually understand this stuff: priceless.
1) JACK was not conceived as a plugin system. It is there to connect processes. The cost of context switches is too great for this design to scale to a level that can replace an in-process plugin API.
2) because of this, JACK will rarely be handling audio data flow that is "complex" - that kind of thing happens inside of applications, and rarely between them.
3) JACK2 (aka jack 1.9.X or jackdmp) has support for parallel data flows
4) It is not true to say that user space cannot be hard real time in a practical sense. If you approach the absolute definition of hard real time, then almost nothing on Linux, even with an RT-patched kernel, is hard real time. In the sense of providing sufficient timing guarantees to meet the hardware limits of current (and imagined) audio interfaces, the RT-patched kernel makes it possble for user-space code to be sufficiently hard-RT that the difference between these two definitions doesn't matter.
5) Linux is already used by "hardcore professionals". There are at least 3 manufacturers of large scale mixing consoles in which the DSP signal flow is being handled by Linux on more or less off the shelf components. Their users, of course, don't see Linux at all.
The "pre-emptive" kernel is not the one recommended for low latency configuration. The pre-emptive option merely improves performance, but does not provide any realtime-ish scheduling guarantees. For that you need an RT-patched kernel. This is NOT necessary for many latency settings.
Furthermore the current JACK ALSA MIDI backend is known to have notable timing bugs, and it is much better to use the current version of a2jmidid. In the coming weeks/month, I will be merging that into the standard JACK ALSA MIDI backend.
No distribution has taken JACK seriously in the sense of providing developers or other developers to help improve it. More money to work on JACK has come from Solaris users than anyone based on Linux.
i'd like to see you try this "1 inch always == 1 inch" with a beamer or other projection system.
management of DPI scaling is, sad to say, *much* more complex than you are suggesting.
X11 does not blit the entire damn window across the network. Its a client/server architecture and what is passed across the network are requests by the client to ask the server to draw <something>, where <something> was envisaged as a mostly abstract entity. It is true that if you application does nothing but push images or video into a window, then there is little alternative to blitting across the network, but this is not what is happening in the majority of apps today.
You seem to have about a similar level of (mis)understanding of what AJAX is doing, but I won't get into that here.
Re:This is a huge amount of work
on
Linux 2.6.27 Out
·
· Score: 4, Interesting
There are also longstanding issues with Intel HDA hardware... this supposed "standard" isn't really a standard at all. It has huge amounts of slop for mobo makers to futz around with the pinouts, and indeed, there are at least as many variants on HDA h/w as seen by the kernel as there are major laptop models. The windows drivers work because of collaboration with mobo makers who provide the info about how they specifically wired up the pinouts. The linux ones are a case of trial-and-error. There are thousands (or even millions) of Intel HDA users on linux who do not have your problem, another whole set who do, and and even bigger set who have different problems with this godforsaken "standard" h/w.
the example you give is pretty typical of the kind of stuff i hear from people who haven't been confronted by real world demands.
lets change your example just a little bit. instead of a filter curve, its a crossfade curve. same basic idea - user manipulates a graphical representation, signals "changed" and good stuff happens.
and then the users say "we want to see the waveform changing shape as we modify the curve". all of a sudden, the view is representing two distinct models, which are entirely orthogonal to each other in the core. hmm, ok, so the view(s) have to be mid-level GUI object, rather than a widget, something that can be composited together with other views. and so now, your entire view architecture has to be tied into whatever scene graph API you're using, which are much less "standardized" than widget toolkits. or you construct a crazy compound view object for every combination of "show me the model(s)" requirement that you have.
but lets take another example that skips that problem. many modern GUIs use some kind of treeview/listview widget for many different purposes. its ubiquitous on windows, pretty common on linux, and reasonably visible on OS X. go take a look at the APIs for the widgets used for this with different toolkits. even though they share some basic concepts, in many important ways they are very different. when we ported Ardour from GTK1 to GTK2, we had devote an entire month to getting just the treeview stuff working - first understanding the new GTK2 treeview (which is much more MVC than the old one), then figuring out how to do stuff with it. the moment you want to do more than select items in the treeview and maybe do DnD with them, you have to get pretty deeply into the "internal" event handling model of the widget in order to get things done (and sometimes, what you want to do cannot be done because of the internal implementation of the widget). This kind of thing causes a massive drag on porting, and there's really no way around it when you want a GUI with all the bells and whistles attached.
I think you're out of your depth.
My application's design is totally based on MVC. If you think that you can write a modern large GUI application with widgets that expose just "i was clicked", then I'd suggest that you've either gotten lucky or haven't done it. My app is cross-platform (Linux, OS X and Windows), and the non-GUI engine can be controlled via the GUI, network control, or MIDI (independently or all at once). It runs 8 or 9 threads concurrently. Porting it to a new toolkit would take 1-3 man years of work. I can say this with confidence because the port between a major version switch of the same toolkit took about 1 man year.
http://ardour.org/ just in case you care to take a look.
You don't know what you're talking about.
For a small application, that might be true. For GIMP (or Photoshop), its not true. Why do you think Adobe have never ported Photoshop to Cocoa, 7 years after Apple announced that Carbon was going away? I've ported my own application (about 75k lines of GUI code, and the same again in non-GUI code, with complete separation between them) between two versions of the same toolkit, and that was bad enough. We frequently get people suggesting we do a Qt port or a Cocoa version, and its just laughable. Subtle changes in the semantics of many the widgets, fundamental differences in the way canvas/scene-graph designs can be implemented, even the basics of threads & event processing can be fundamentally different. You can't search&replace tens of thousands of code to do this - it all has to done line by line by hand.
It would cool if Photoshop made the same move too, eh? Its not written with Cocoa either, which is giving Adobe a few headaches now that Carbon has been even more officially deprecated than it used to be.
Seriously, you simply don't seem to understand what is involved in switching an program that it totally rooted in its GUI from one GUI toolkit to another. People say this as though its a simple recoding. Nothing could be further from the truth. Even porting from one version of a toolkit to another can be traumatic, let alone porting between two different 'kits.
Much more optimistic is the fact that the GTK/Quartz port gets better every week, allowing the GIMP guys to offer a "native" (non-X11 based) build with very few code changes.
Slashdot Mirror
Perhaps you don't understand that I wrote the software that makes running Windows VST plugins on Linux possible (along with Ardour and JACK). Audacity uses Wine too, but in a different way than Ardour because we care about scaling, and the Audacity approach (running plugins in a different (Wine-controlled) process doesn't scale in the way that an actual DAW (intended to be use with hundreds of tracks and hundreds of plugins) requires.
In general, audio technology companies do not make very much money. Digidesign is almost close to bankruptcy, and laid off the bulk of its engineering staff. When Yamaha purchased Steinberg, it cost then a few tens of millions of dollars - for the number 2 company in the industry at that time. Most new audio technology companies fail within a few years. The recording industry does NOT pay significant cash to "well funded teams of software engineers" for this technology, which is one of the reasons why companies like Digi are having a hard time (along with their older cousins, the makers of large-format consoles, which are also no longer a line item in most budgets). The recording industry does not function like the video industry, and hasn't for more than a decade, if they ever did.
Probably the most successful audio software company right now is Ableton, and they've created an entirely new workflow for music creation, entirely over the opposition and disbelief of people with years of experience on more traditional DAWs. Another example might be Waves Audio, who have significantly diversified their products and focus from their traditional plugin-centric approach, again reflecting changes in what people will and will not spend money on (hint: broadcast and live PA work are now significantly more cash-flow endowed than recording).
What the linux audio software lacks is not funding from the recording industry (and note that Ardour is already the basis of products from Waves Audio and Harrison Consoles), but enough paying users, which in turn is a reflection of what happens when you develop for a tiny niche inside of an already niche software environment.
1) Quite a few manufacturers choose not to use the USB audio class specification
2) I can't write the software fast enough. Ardour has taken up 16 years of my life already, with a huge amount of help from other people.
This is not accurate. JACK uses ALSA. And tools like Ardour can now use ALSA directly, rather than via JACK, if the user prefers.
This isn't really true.
If companies adhere to the USB standards, then stuff just works. That's why you can plug a Behringer (Midas, really) X32 into a Linux system and it all just works. All of it.
iz RADAR.
Oh, and Ardour no longer requires JACK either (on any of the 3 platforms on which it runs), but can use it if the user wishes to do so.
PulseAudio is nothing like WDM on Windows, in any sense at all.
Your "one system for everyone (CoreAudio on OS X)" is also true on Linux too. The issue is the presence of "middleware", such as PulseAudio or JACK. But JACK provides functionality that is not possible with just CoreAudio (interapplication audio, shared transport control and more), so the comparison is a bit more complex.
And by the way, if low latency is the primary metric for measuring the quality of an audio system, then ALSA still wins.
And finally, almost all new audio interfaces use USB, and almost all of them are class compliant, which means that the manufacturer doesn't write a driver at all. One driver, all applications, all Windows, OS X and Linux.
There are LOTS of multichannel USB audio interfaces that work perfectly on Linux. What matters is whether the devices correspond to the USB audio class specification, which is also equivalent to asking whether they come with their own drivers for OS X and Windows. No drivers? They will work on Linux.
1) http://manual.ardour.org/worki...
2) http://manual.ardour.org/worki...
I suppose it is just too hard these days to imagine recording music (the question was about a home RECORDING studio) as actually meaning RECORDING musicians performing on instruments.
I can assure you that there are plenty of people using Linux to do that, without the issues you're describing above. I'm also going to assume that you live in the USA, because if you lived in Europe (notably Germany) I think your perception of Linux would be quite different.
I wrote JACK. I'm sorry but your response reads like total gibberish. Perhaps your ideas are just too much for my current mental state.
I already rebuffed your comments about "really high end stuff" - I am not sure why people keep spreading this myth.
As the primary author of Ardour, I can point you at a dozen people who do this kind of recording with Ardour at least weekly. I can even point you (anonymously, alas) at a major UK-based mobile recording truck service that is now installing Ardour as its secondary recording systems, in scenarios that typically involve recording at least 72 tracks at once. Yeah, it would be nice if it was the primary system, but I'm patient. After all, its only been about 6 months since the last /. flamefest that declared that Ardour could not do , or ....
nobody agrees on (a) what the subsystem should do (b) what API it should have (c) how it should be enforced.
your description of your problems with JACK doesn't match any of the user experiences i've heard about for the last several years. perhaps you should be providing bug reports, feedback and other useful to the JACK development community rather than just commenting about it on /. ?
i wrote JACK (originally, and with help from many others) by the way.,
what do you consider "top end hardware interfaces"?
RME HDSP and MADI interfaces, the choice of most highly-multichannel configurations worldwide, work perfectly on Linux and have done for a long time. Perhaps you are one of those who believe that firewire devices are "high end"?
Nobody who is serious about audio production attempts to sync two audio interfaces without an explicit sample clock (aka "word clock") sync connection. Whether this is done implicitly, as is possible with firewire based interfaces, or via an additional coax cable with suitable termination on a PCI card doesn't matter: you don't get sync out of two separate clocks without resampling, which is the enemy. You can even take out your soldering iron if you want and run a wire between two el-cheapo consumer interfaces. Not recommended for beginners.
People commenting on technical matters that they know less about than they make it sound: $0.02
People commenting on technical matters and honestly reflecting their knowledge level: $10.00
People who actually understand this stuff: priceless.
1) JACK was not conceived as a plugin system. It is there to connect processes. The cost of context switches is too great for this design to scale to a level that can replace an in-process plugin API.
2) because of this, JACK will rarely be handling audio data flow that is "complex" - that kind of thing happens inside of applications, and rarely between them.
3) JACK2 (aka jack 1.9.X or jackdmp) has support for parallel data flows
4) It is not true to say that user space cannot be hard real time in a practical sense. If you approach the absolute definition of hard real time, then almost nothing on Linux, even with an RT-patched kernel, is hard real time. In the sense of providing sufficient timing guarantees to meet the hardware limits of current (and imagined) audio interfaces, the RT-patched kernel makes it possble for user-space code to be sufficiently hard-RT that the difference between these two definitions doesn't matter.
5) Linux is already used by "hardcore professionals". There are at least 3 manufacturers of large scale mixing consoles in which the DSP signal flow is being handled by Linux on more or less off the shelf components. Their users, of course, don't see Linux at all.
The "pre-emptive" kernel is not the one recommended for low latency configuration. The pre-emptive option merely improves performance, but does not provide any realtime-ish scheduling guarantees. For that you need an RT-patched kernel. This is NOT necessary for many latency settings.
Furthermore the current JACK ALSA MIDI backend is known to have notable timing bugs, and it is much better to use the current version of a2jmidid. In the coming weeks/month, I will be merging that into the standard JACK ALSA MIDI backend.
No distribution has taken JACK seriously in the sense of providing developers or other developers to help improve it. More money to work on JACK has come from Solaris users than anyone based on Linux.
Mr. Ardour/JACK.
i'd like to see you try this "1 inch always == 1 inch" with a beamer or other projection system. management of DPI scaling is, sad to say, *much* more complex than you are suggesting.
X11 does not blit the entire damn window across the network. Its a client/server architecture and what is passed across the network are requests by the client to ask the server to draw <something>, where <something> was envisaged as a mostly abstract entity. It is true that if you application does nothing but push images or video into a window, then there is little alternative to blitting across the network, but this is not what is happening in the majority of apps today. You seem to have about a similar level of (mis)understanding of what AJAX is doing, but I won't get into that here.
There are also longstanding issues with Intel HDA hardware ... this supposed "standard" isn't really a standard at all. It has huge amounts of slop for mobo makers to futz around with the pinouts, and indeed, there are at least as many variants on HDA h/w as seen by the kernel as there are major laptop models. The windows drivers work because of collaboration with mobo makers who provide the info about how they specifically wired up the pinouts. The linux ones are a case of trial-and-error. There are thousands (or even millions) of Intel HDA users on linux who do not have your problem, another whole set who do, and and even bigger set who have different problems with this godforsaken "standard" h/w.
lets change your example just a little bit. instead of a filter curve, its a crossfade curve. same basic idea - user manipulates a graphical representation, signals "changed" and good stuff happens.
and then the users say "we want to see the waveform changing shape as we modify the curve". all of a sudden, the view is representing two distinct models, which are entirely orthogonal to each other in the core. hmm, ok, so the view(s) have to be mid-level GUI object, rather than a widget, something that can be composited together with other views. and so now, your entire view architecture has to be tied into whatever scene graph API you're using, which are much less "standardized" than widget toolkits. or you construct a crazy compound view object for every combination of "show me the model(s)" requirement that you have.
but lets take another example that skips that problem. many modern GUIs use some kind of treeview/listview widget for many different purposes. its ubiquitous on windows, pretty common on linux, and reasonably visible on OS X. go take a look at the APIs for the widgets used for this with different toolkits. even though they share some basic concepts, in many important ways they are very different. when we ported Ardour from GTK1 to GTK2, we had devote an entire month to getting just the treeview stuff working - first understanding the new GTK2 treeview (which is much more MVC than the old one), then figuring out how to do stuff with it. the moment you want to do more than select items in the treeview and maybe do DnD with them, you have to get pretty deeply into the "internal" event handling model of the widget in order to get things done (and sometimes, what you want to do cannot be done because of the internal implementation of the widget). This kind of thing causes a massive drag on porting, and there's really no way around it when you want a GUI with all the bells and whistles attached.
I think you're out of your depth. My application's design is totally based on MVC. If you think that you can write a modern large GUI application with widgets that expose just "i was clicked", then I'd suggest that you've either gotten lucky or haven't done it. My app is cross-platform (Linux, OS X and Windows), and the non-GUI engine can be controlled via the GUI, network control, or MIDI (independently or all at once). It runs 8 or 9 threads concurrently. Porting it to a new toolkit would take 1-3 man years of work. I can say this with confidence because the port between a major version switch of the same toolkit took about 1 man year. http://ardour.org/ just in case you care to take a look.
You don't know what you're talking about. For a small application, that might be true. For GIMP (or Photoshop), its not true. Why do you think Adobe have never ported Photoshop to Cocoa, 7 years after Apple announced that Carbon was going away? I've ported my own application (about 75k lines of GUI code, and the same again in non-GUI code, with complete separation between them) between two versions of the same toolkit, and that was bad enough. We frequently get people suggesting we do a Qt port or a Cocoa version, and its just laughable. Subtle changes in the semantics of many the widgets, fundamental differences in the way canvas/scene-graph designs can be implemented, even the basics of threads & event processing can be fundamentally different. You can't search&replace tens of thousands of code to do this - it all has to done line by line by hand.
It would cool if Photoshop made the same move too, eh? Its not written with Cocoa either, which is giving Adobe a few headaches now that Carbon has been even more officially deprecated than it used to be. Seriously, you simply don't seem to understand what is involved in switching an program that it totally rooted in its GUI from one GUI toolkit to another. People say this as though its a simple recoding. Nothing could be further from the truth. Even porting from one version of a toolkit to another can be traumatic, let alone porting between two different 'kits. Much more optimistic is the fact that the GTK/Quartz port gets better every week, allowing the GIMP guys to offer a "native" (non-X11 based) build with very few code changes.