Re: Moving From ProTools to Linux? Good or bad?

dawhead wrote:

not quite the right analogy in my mind. the issue here is whether you
start the "new user" out on a path that is fundamentally different
from the one s/he may (or is even likely to) take later, or "force"
them to deal with the whole system from the beginning. reasonably
people can agree to differ on which approach is better;

I find that it's much easier to explain how audio routing works when people know the fundamentals. In hardware I always send them to the block diagram, and if necessary, coach them in reading it. Once they get the hang of that, they can solve their own problems.

Maybe what I need is something like a block diagram of the audio connections in Linux. I get the hint that Jack has something to do with this, but it's just not clear from what I can see from the JACK GUI. You've brought up Rewire a couple of times, but that shouldn't be necessary for a basic audio in-to-out setup. I've never used Rewire, and I'm not even sure what it does, or what it will do for me. Apparently I don't miss it.

Must use JACK in order to assign the input and output of my sound card to an application (like Ardour, or Audacity)? Those are things that I do from the application itself when I'm working in Windows. If I have to do it, I'll accept that and do it, but it's just not clear that it's necessary, and even assuming that it is, I can't find anything about my sound card in JACK, which is surprising. I can find references to MIDI, but I have no MIDI interface hardware. I assume this will connect a sequencer program that can play a MIDI file (or play from a virtual MIDI keyboard) to some sample player that plays through the sound card. This may be all some users need to do. But others (like me) have no need for it at all.

> i will
certainly agree that we could do a better job of making JACK more
trivial to use and control. for a more direct comparison with a world
you are already familiar with, imagine if all win pro-audio apps were
able to use Rewire and in fact required it. on the one hand, the
learning curve to get started is steeper and perhaps a little longer.
on the other hand, once you've understood the basic idea, you have
access to a lot more possibilities and you never have to relearn the
basic audio i/o model.

That's pretty much my point. I don't mind learning something new, but the first thing I need to learn is what it does and why I need it. That's not at all clear when it comes to JACK. There are other applictions (utilities?) that make reference to sound devices.

In JACK's Audio Connections Settings tab (which seems to be a reasonable place to look for what I'm trying to figure out), under Input Device I see:

hw:0 Intel 82801 AA-ICH
hw:0,0 Intel 82801 AA-ICH
hw:0.1 Intel 82801 AA-ICH MIC ADC
and (default) - lots of "default" spread around there.

What does it all mean? Which one should I pick? Has Linux "found" the sound card (in a similar way that Windows finds hardware that's installed on the system)?

the problem is that these "other applications"
generally are not written to collaborate with the ones you already
have (hence the monolithic host + plugin model on win & OS X). one of
the most important parts of the current linux audio software "world"
is that we've been attempting to create something more like an
ecosystem, where every app can be used in collaboration with other
apps. for new users, this seems awkward, especially if they already
have experience of the host+plugin model.

Yup. As I said, and I have this problem with lots of computer stuff, you can't do anything useful until you first learn enough to build the tools that make the application work. This is not friendly to beginners, even beginners who have some basic (and correct) knowledge about how things work on a functional level. It's the need to always get below the functional level and get down into the internal workings that frustrates me. I can dig deeper when I have the need, but I'd rather not be distracted with that when doing something that I believe should be automatic.

> but let me give a single
concrete example. xjadeo is a small app that plays video files
(without audio playback). it syncs to JACK transport, so when the user
clicks on a "roll" button on any JACK app, xjadeo starts up. when the
locate with any JACK app, xjadeo locates too. result? every JACK app
that has a timeline (i.e. as distinct from live FX processors, or
loopers) now has the ability to run with audio-sample-synced video.

Great for developers, but unnecessarily complex for the user.

instead of every developer of such an app duplicating the work robin
put into this (and continues to put into it in order to facilitate his
own work as a sound design guy), all the apps get to "share" the
functionality. trickier than having in-app video playback? yes, a
little. more flexible? a lot.

But if the user wants to play or edit a video, he'll just open an application that does that. Why open one application that plays audio, another that plays video without audio, a third that displays where you are in the file, and then connect them all together with JACK? This is making the user take the role of application developer. If this is what's so great about Linux audio, I'll stop right now.

When I first saw Ardour, I was coming from Mackie where I worked
on the documentation for the HDR24/96

too bad that all 3 of the units we attempted to use would crash
regularly. looks like we followed that part of the HDR model too :)

Too bad you got into it a little too early. I have two units and both have been rock solid. The crashes that I've seen since the second software release have nearly all been attributed to hardware, often as not with a connector. But I'll admit that the early software did have some problems.

its so interesting to me that audio engineers are so unlike wood
workers or other construction workers, who all share the same property
that you get your work done by interacting with (some part of) the
world via a variety of different kinds of tools.

We do, but the tool sets are different. We use compressors and mic preamps and equalizers, and, yes, hammers and saws to build acoustically decent recording spaces. But only a small handful of engineers today have the knowledge or experience to buy a bunch of parts and make a mic preamp, or even to to trace a signal through a mixer to identify the faulty circuit.

When a woodworker gets a new plane, the blade is almost always sharp enough to do a little work. He doesn't have to first get the sharpening stone out of his toolbox and put an edge on the blade. He knows how those two tools relate - he won't try to sharpen the blade with a saw. And when he works with the sharpening stone, he's able to see his progress every step of the way.

> the people using
power tools all accept (and even welcome) a top-to-bottom knowledge of
their tools, and it is widely accepted that you can't use a power
planer or a router, let alone a large scale industrial laser cutter,
without substantial training and a solid conceptual model of how it
works.

Agreed. So where does one get this conceptual model? And how many carpenters use a large scale laser cutter? I can look at a power planer or router and figure out how to use it. The laser cutter may require that I need to learn its programming language and set it up to do what I want it to do, but if it came with a "cut an oval" preset, I could find that and cut an oval.

> even the characteristics of the motor that drives these tools,
or the specific alloy used to form a blade, is part of the knowledge
base that skilled users of these tools expect to carry around with
them.

Uh . . . I think you're getting a little optimistic here.

the fact that the computer is a general purpose tool
that gets "re-purposed" to specific tasks (such as audio recording &
editing) has led people to a viewpoint where the only part of it you
are supposed to know about is the application. i don't know if this
view can be shown to be "correct" or "false", but i do find it both
strange and a bit sad.

I think that there's some middle ground that you wouldn't be sad about. I'm pretty much in that place. I know what should be happening, but I can't deduce how to get there from what I see in front of me. To the user who has no interest in being a developer, you have to offer a product that he can find his way around without learning a completely new language and vocabulary, and a new way of getting information. "Read the man page" often leads to only more research to find out what they're talking about.

I realize that developers aren't primarily interested in end products for practical users, but if your an your community have any interest in building new advocates, someone needs to reach out to them and show them that it's easy to get started. Then you can tell them about some really cool things that they can do when they have the need or desire.

Honestly, when I was tempted by the "product" called Ubuntu Studio, I expected that when the installation was finished, I'd have a desktop with at least a few audio applications on it, but instead, I first had to find the menu (a little hard-to-see button) to find the menu. My Windows intuition and experience led me to putting Ardour and Audacity on the desktop so at least it's easier to get them started.

this is generally called a "live CD". there are a few that exist if
the goal is to do audio stuff, and some of them actually work quite
well

This was what I expected from Ubuntu Studio, based on what a few of the folks on rec.audio.pro said about it. (mostly "get it, run it, enjoy")

the last time i was looking at them (a couple of years ago), none of
them worked well enough for me to recommend them. but they are
improving all the time. the major issues tend to come from
interactions with the audio h/w - the intel so-called "HDA"
specification for motherboard-based audio interfaces has been a total
clusterfuck for linux, because its not a standard at all,

Hey, a programmer's life is never simple. <G>

if your system had a more reasonable
PCI-based audio interface in it (eg. anything based on the
ice1712/1724 chipsets, like a lot of stuff from m-audio, terratec and
several other companies), then this goal is almost doable today (but
only almost).

This isn't sounding very good, but thanks for recognizing what real life is like. I might spring $50 for a used M-Audio Audiophile card, but not $600 for a Delta 1010, particularly knowing that it still won't be simple once I get the "right" hardware.

you've just skipped over my original point about shoutcasting. the
goal is not "just plugin in your mic and go". its "take the audio from
anywhere, including your mic, your DAW master outs, or that nifty
softsynth, and stream it to the world".

That's step two, or maybe five. What I'd expect as an end user is a GUI that looks like a mixer, where I could choose the input to each fader - one would be for the mic, one would be for the DAW output, one would be from the soft synth. What happens inside in order to create that interface shouldn't be my concern. Let the GUI application open JACK if that's the most sensible tool for the job.

Windows isn't devoid of this sort of conceptional problems for the hardware-oriented peole like me, either. One example that I often use is one of creating an auxiliary send to a hardware output in a DAW. I want to set up a bus, set the bus input to a track or source output, and set the bus output to the hardware port to which I'm going to connect the headphones or reverb processor. But DAWs almost universally use the paradigm of a track as a bus, so first I have to create a track that isn't a track in the conventional sense (but it's still called a track and looks like a track), assign the source that I want to send to the outside world as the input to the track, and assign the output of the track to, say, Delta 1010 Outputs 7-8. And if I want to sent it to two sets of headphones, perhaps with a different mix to each one, I have to set up another track and repeat the process.

Now if the software has to do all of that in order to best accomplish the end result, fine. But there's really only one thing that needs to be accomplished (other than perhaps how many buses you want ot set up) so give me a user interface that says:

1. Make me a bus
2. Select where the input comes from
3. Select where the ouptut goes

Don't clutter up the already crowded display with a track that I don't have to see. Acid Pro 7 has a button that lets you hide some of that stuff, but the idea hasn't universally caught on yet. There's no need to ever see that track once it's been set up, so why not get it out of the way?

when protools first came out for windows, it was certified/supported
on only a single h/w platform (some model supplied by IBM). we're
still dealing with a situation on linux that is somewhat equivalent to
this, mostly because of h/w manufacturer reluctance/refusal to provide
us with information.

Well, you see, this is where the big bucks help. But Linux developers aren't the only ones who have this problem. Developers of commercial audio software like to try it with whatever hardware they can get their hands on, some in house, some that their engineers have in their personals studios, some that outside beta testers own, some that they are able to mooch from manufacturers or choose to invest in. But there's always something that they haven't tested, or something that comes along after the product is released that doesn't work. Commercial audio software or hardware manufacturers have a little more money than you do, but not nearly as much as Microsoft, and even then, Microsoft puts a very small amount of their budget into audio.

When CEntrance was doing their Windows Universal ASIO Firewire Driver (since abandoned) they needed hardware to test with, and being a pretty small company, they didn't get a lot of contributions from the manufacturers. They offered to add any hardware to their driver that they could get their hands on, and some users loaned them hardware for their testing. They had a Mackie Onyx mixer Firewire card and mixer of mine for about a year before Mackie finally coughed up one for them.

Intellectual property doesn't cost as much as hardware, but since they're in a competitive world, I can see that they don't want to release a lot of proprietary information for fear that someone will reverse engineer their products. I know that RME, for example, has decided that all the stock support for Firewire audio isn't good enough and has written a lot of new code in house that gives their hardware a performance edge over a lot of competing products. RME doesn't want to make it easier for M-Audio to figurre out what they're doing better by looking at the (open) source code for a Linux driver based on their proprietary Firewire software interface.

nevertheless, we attempt to get linux audio stuff
working on any system the user might have, although in some cases
(hello VIA motherboard owners), we just have to give up.

This goes with the territory when you have open hardware systems. In the Windows world, the 'net is full of wisdom about what Firewire host cards work (or don't) with what hardware. And like most PC users (believe it or not, most don't build their own computers) who don't know what chipset their motherboard has, it's getting harder to find out what kind of chipset a Firewire host card has, nor do they know what chip is used in the hardware device they're trying to interface. It used to be that the manufacturer proudly put that info on the box. Now you're lucky if you get a box. It used to be easier with Apple, but even that's getting kind of flaky now.

> the amount
of work necessary to get an arbitrary windows system configured for
minimal latency audio still seems to me to be roughly equivalent to
what is needed for linux *if you started with the right distribution*,
and therein lies half of the problem. people don't know what the right
distribution really is, and in truth, neither do i at this point. a
lot of this confusion comes from the wide range of "new users" we
encounter. some are people with lots of windows or osx experience
dipping their toes into linux. some are very experienced linux users
dipping their toes into audio. some are neophytes at all of this.

Yup, you get all kinds. Inexpensive computer hardware has brought a lot of people who don't have a clue about either computers or system engineering to the world of the "home studio in a computer." Windows may not have all the resources to achieve an ideal system but at least its restrictions prevent you from going too far off track, at least some of the time. So even against all those odds, most people who give it an honest try manage to come up with a workable if not ideal system without having much knowledge of what's going on under the hood. But with Linux, it appears that sometimes you need to grind the camshaft in order to even get the engine to start.

> i've
watched people be deeply confused by audio (and many other things) on
os x, so i don't think the problem is just linux

I have favorite quote from author John Watkinson: "Today's production equiomet is IT based and cannot be operated without a passing knowledge of computing, although it seems that it cant be operated without a passing knowledge of audio."

although there is
still a lot of room for improvement. sit a new-to-audio-on-computers
guitar+voice user down in front of a system with windows & protools
preinstalled and see how well they do.

Some get it, and some don't. But the ones who get it fastest are those who have hooked a microphone, a mixer, a tape deck, and some speakers with real wires. They understand the signal flow and know where there should be inputs and outputs.

consider this: your definition of "a basic system" is just one of the
many that i have to deal with day in, day out. some people say they
just want something like the HDR24/96. others "just want" basic
editing. others consider video-sync to be a "just basic" requirement.
others think that "running my win32/vst plugins" is a key part of a
"basic system". ardour doesn't slave directly to midi clock? useless!
and on and on.

The difference between a Linux or Ardour team and a commercial manufacturer is that the commercial manufacturer starts out by deciding what he wants to make - usually based on similar products presently on the market and the wish list of his potential customers. He develops a product specification and when he has all the functions in his specification working well enough, he releases the product. If you want video integration you need to buy a product that offers it, not bitch that the one you bought doesn't offer it (though many don't understand this). But if you try to please everybody, and continue to add features as user requests come in, you'll never be finished.

waves, for example, already
runs all their plugins on linux - if you buy the hardware from them.
they would be quite happy to release their stuff for linux if it was
possible to come up with a licensing model, but since they are locked
into Pace/iLok, which doesn't work on linux at this time, this isn't
possible for them to do.

Do you know the Plugzilla project? That was a Linux-based hardware box that ran plug-ins, and licensing was the part that they never really came up with a good solution for. They eventually dropped it, though there's a similar one called Muse that's still around. But I think more people are using it as a synthesizer than as an outboard reverb or compressor, the things that Waves does well.

nobody in the linux community expects h/w manufacturer to write
drivers. what we ask for is the information to enable us to write
drivers. companies that imagine that doing so reveals critical
proprietary information have a deeply flawed business model

Unfortunately, it's a fast-turnaround industry. They have to make money on their technology in a couple of years because the product will be obsolete by then. What would be really nice is if the Linux community could provide a specification against which the hardware manufacturer could write a driver that will work. But I suspect that given the Linux environment, it's difficult to write an interface specification and make it stick around long.

there is still a key problem for existing companies though - coming up
with something that looks like a business model and involves linux.
over the years, i've been sponsored by a variety of very well known
audio tech companies, but only 1 of them has managed to come up with
anything that looks remotely like a plan that integrates with their
existing products and strategies.

Harrison? I know that they have an Ardour-based recording system integrated with their Linux-based digital consoles. But when you buy into that, you're not really buying the open system concept. You get a turnkey system that's supported by the console manufacturer, they fix the bugs, and release updates as necessary. But you don't get the software without the console, and it's not cheap.

my mother ("granny" to some)
just recently switched from windows to an asus notebook running linux
and is having a great time with it because "its just like windows" :))

That's a good example of a turnkey system. Put together as set of mainstream applications that cover the needs of the majority of the users and you can sell a turnkey system that needs no additions.

how would they have any idea how many linux users they have? they
don't even know how many win/osx users they have, only total users.

I think they have a pretty good idea, based on the sale of applications.

a rough guess based on my recent visits to various universities and
watching various linux audio mailing lists, i'd say that RME have
netted at minimum an extra 2000 sales of their hardware for systems
which primarily run linux

That's not bad, but there are far more Windows users than that. RME is a pretty high priced line and tends to attract more of the "professional" users who may not be as fussy (or are more dedicated to getting a special purpose system to work) than I am. I'm just dabbling out of curiosity and because it appeared that linux audio was getting ready for prime time. But I'm not very strongly committed.

Again, thanks for your input and open honesty.


--
If you e-mail me and it bounces, use your secret decoder ring and reach me here:
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers (mriv...@xxxxxxxxxxx)
.

Relevant Pages

  • Re: Good bye
    ... And if you expect a 5-year useful life for hardware, ... windows machines are as stable/reliable as anything running Linux. ... full processor, memory, RF, IF, audio, and peripheral drivers on board. ...
    (Fedora)
  • Re: OReilly critique on Linux and audio
    ... >>recording needs.I am using Linux every day to make my recordings mostly ... > input 24-bit audio into any Linux recording software. ... Start Jack and it will refuse if the sample rate is not supported. ... Note: audio device hw:0 doesn't support a 32bit sample format so JACK will try a 24bit format instead ...
    (comp.os.linux.misc)
  • Re: Moving From ProTools to Linux? Good or bad?
    ... Given that I think of a computer as being a computer and not an audio ... starting JACK when the machine boots is wrong. ... Linux, and what you are trying to do has very little to do with JACK ... distribution, and as much as i'd love to take responsibility for ...
    (rec.audio.pro)
  • Re: Linux and audio pro
    ... a commercial linux install with a lot of the ... complete music production environment including sequencer, MIDI and Audio ... You can use your existing VST plugins and VST ... * Sweep 0.8.1 (plus jackasyn for JACK support) ...
    (comp.os.linux.misc)
  • Re: Is Linux A Feasible Platofrm For Professional DAW work ?
    ... and only some of them actually talk to an audio interface at all. ... Maybe JACK is the wrong tool here and a different one ... names that don't indicate the "type" of hardware that they refer to. ... I found a number of instances in Ardour where the human interface ...
    (rec.audio.pro)