This is a discussion on Having Trouble with Protools and Linux. within the Linux General forums, part of the Linux Forums category; flatfish+++ wrote: > On Thu, 04 May 2006 04:47:39 +0000, Jim wrote: > > >>>So ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
flatfish+++ wrote:
> On Thu, 04 May 2006 04:47:39 +0000, Jim wrote: > > >>>So how many professional studios are using Linux? >>> >>> >>> >> >>want me to name two right off the bat? >> >>Earache Records (now defunct due to financial fiddling) >> >>URN >> >>Have a nice day. > > > So in effect you found one.. > I know one as well, so we are back to 2. > And BTW I mean using Linux to do the DAW part (ie:Nuendo, Protools etc) > not as a server farm backing up the data or online systems etc. > > I know plenty of studios running Linux in that capacity. > URN uses Linux in realtime studio mixing; they're a radio station run by and for the students at the University of Nottingham. Earache used Linux in the studio, also for postprocessing and downmixing. -- When all else fails... Use a hammer. |
|
|||
|
The Ghost In The Machine wrote: > > Hmm..."Pro Tools" shows up on Google as "the industry's leading digital > audio production tools". > > http://www.digidesign.com/ptfree/ > > The website offers Mac OS9 and Win98/Me versions. This tells me two > things: > > [1] this particular manufacturer hasn't quite gotten around > to writing a Linux version yet, and > > [2] this particular manufacturer hasn't quite gotten around > to writing a Windows XP version yet. > > It gets weirder. I also see Avid Pro Tools LE. > http://www.avid.com/products/xpressStudio/proToolsLE/ > > System requirements suggest WinXP Pro w/SP1. Therefore this > is inappropriate for Linux qua Linux, although others have > already suggested WinE or VmWare. > > This suggests "ProTools" is not sufficiently specified to inquire > further. This won't be news to anyone else but Digidesign is owned by Avid. Pro Tools is indeed the industry leader. Only the FREE version hasn't been updated for OS X and Windows XP. Both the LE and TDM versions are current except that they haven't been updated for Intel Macs. No Linux. I'm not sure how you missed out on the bulk of the specifications for the Pro Tools offerings. It is the industry standard. Craig http://www.pro-tape.com Authorized Dealer Sales · Service · Training Adobe · Apple · Avid · Canon · Digidesign · Pro Audio and Video |
|
|||
|
On Thu, 04 May 2006 06:39:36 -0500, Linonut wrote:
> After takin' a swig o' grog, flatfish+++ belched out this bit o' wisdom: > >> On Wed, 03 May 2006 19:37:09 -0500, Linonut wrote: >> So basically you accuse me of bullshitting, but yet you can't show me how >> to do what I say is very difficult to do with Linux (IOW a great time >> waster). > > I called your statem bullshit for two reasons: > > 1. Latency on linux can be pared pretty well > > 2. You present a rather amorphous claim (even the latency claim is > subject to questions such as "latency in what context") saying > that Linux is essentially useful for audio work, when lots of > stuff is out there (even if there are indeed lacks and problems > with Linux audio.) You're dancing now Linonut. The title says Protools, which is a high end audio recording application and my post is in keeping with the context of that title. IOW I don't care how long it takes your little bits and bytes to circulate around a somewhat bloated kernel, it's all GIGO to me. I move a slider and the latency is adjusted accordingly and I can get very low latencies easily. No kernel compile required (hint hint!) > What I would prefer to see is a giant matrix of > scenarios/tasks/constraints by audio adapter. I'd expect the Windows > one to be fairly full of checkmarks, but I would not expect the Linux > one to be nearly empty. You're all over the place now Linonut. This is a very simple concept. Windows does it easily, today and now. Linux? I'm sure it can be done, but easily? No way. >> Why does one want to adjust latency within the application? >> Duhhh.... >> What do you think is doing the recording, playback etc? >> >> That's the problem with you Linux nut jobs, you have a hard time thinking >> in terms of APPLICATIONS because you are too busy playing with OPERATING >> SYSTEMS. > > And that's the problem with your statement above. The latency you're > talking about here is basically a buffer size. Somewhat correct. The amount of buffers effects the latency, but there are trade offs depending upon the OS AS WELL as the program and the hardware as well. IOW you may get 6 msec with Nuendo but only 10 with Sonar (made up numbers). Also each independent application, say Soundforge and Sonar, can have their own latencies running at the same time. That is why the applications control it. The soundcard is profiled during the setup of the program and it determines the amount of latency that is suggested, and this default number is generally a very low value especially with ASIO drivers. > What's the smallest buffer size an OS can reliably play back under > various load conditions? It depends. But again you are all over the place. You are talking theory, and I am talking here today, and doing it NOW. >> I'll give you credit, at least you responded. > > Look, I don't think Linux is perfect. And, to be frank, the last time I > did any serious audio work was in a lab, with Win 98 in control of a DSP > card and a rack of audio-related modules, on a P-II 400 MHz machine. > There was no way Win98 could handle what we needed -- timing accurate to > a millisecond. So we had to depend on the (expensive) hardware to do > it. > > Today's machines can handle the loads better. > > Another example: I used to play MIDI using timidity (MIDI-to-wave > conversion on the fly) on a P-II 400. It worked. I tried it recently > on a P-Pro 200. It would not work. Continual gaps in playback. With > todays P-IV 3000's, things should go a lot better. > > X also brings in problems. At least in my configuration, you can freeze > up audio by holding onto a window long enough. So it sounds like I > would indeed have work to do to use my systme for live playback. > >> Here's a guy looking to move to Linux: >> >> http://lists.ardour.org/pipermail/ar...ch/000201.html >> >> Notice the "I can do this under Windows with near zero latency" part? >> And this was 2 years ago. > > Win 2000 improved the situation, and XP even more so. > >> Do you realize how many professional studios are using Nuendo? >> If near zero latency was not possible, this would not be true. >> >> Linux? >> >> So how many professional studios are using Linux? > > I don't know. It's party marketing, partly support, and partly just > the plain ubiquity of Windows. > > I remember well the day when Atari ST was the machine. Linux is making > strides. Eventually it will have vendors laboring hard to make sure > their drivers work well with Linux and the low-latency kernel. I left the rest intact because I mostly agree with it. -- flatfish+++ "Why do they call it a flatfish?" |
|
|||
|
After takin' a swig o' grog, flatfish+++ belched out this bit o' wisdom:
> You're dancing now Linonut. > The title says Protools, which is a high end audio recording application > and my post is in keeping with the context of that title. If I'm dancing, it is by accident. Sorry. > IOW I don't care how long it takes your little bits and bytes to circulate > around a somewhat bloated kernel, it's all GIGO to me. > > I move a slider and the latency is adjusted accordingly and I can get very > low latencies easily. > No kernel compile required (hint hint!) Hint: you've been over this ground before, and are ignoring what you were told. >> What I would prefer to see is a giant matrix of >> scenarios/tasks/constraints by audio adapter. I'd expect the Windows >> one to be fairly full of checkmarks, but I would not expect the Linux >> one to be nearly empty. > > You're all over the place now Linonut. > > This is a very simple concept. > Windows does it easily, today and now. > Linux? > I'm sure it can be done, but easily? > No way. It would really help if you clarify what "it" is. Instead you flatulate a cloud into the air so that no one can grapple with your argument, whatever it is. MIDI looks easy to me, in Linux. Editing waveforms looks pretty easy to me, in Linux. Mixing waveforms looks pretty easy to me, in Linux. Configuring apps to use multiple sound cards seems fairly easy to me, in Linux. What you seem to be complaining about is more advanced functionality provided by Windows-based tools. That, I could agree with -- if I knew more about the tools on both platforms. But it does sound <get it?> to me like Linux and open-source has the basic functionality pretty well covered. > Also each independent application, say Soundforge and Sonar, can have > their own latencies running at the same time. > That is why the applications control it. You are clearing up some of the static for me <grin>. -- Kreegah! Bundolo Microsoft bolgani! |
|
|||
|
In comp.os.linux.advocacy flatfish+++ <flatfish@linuxmail.org> wrote:
> > The short answer is :Linux does NOTHING (except maybe Office) that you > need as an audio engineer. > You will never get the low latency and features that you get from Windows > or OSX with Linux and your time will be consumed trying to make Linux do > what you need it to do. I disagree. Linux is useful for a subset of audio/video engineers that need a very open architecture for stringing a few custom pieces into their toolchain. If this were not true, the existing (admittedly rough) linux AV tools would not even exist. As for audio latency, that is just plain wrong. It may have been true back in the 2.2 kernel, but the current 2.6 audio and video pipelines crank out just fine. It certainly performs better than Windows on similar hardware, and my experience with it has been at least comparable to similar tasks on my Mac. Of course if your editing program is written poorly and buffers things overly long in user space, you will suffer from bad latency, but that is not the fault of Linux, just the crappy app. Personally, I've had a good experience with the Linux tools I've used. > My advice is if you want to abandon Windows, which is really not a bad > thing, go for OSX and buy a Mac. Not bad advice... I still use Final Cut Pro on a Mac at the tail end of my toolchain quite a bit. Linux is the workhorse for doing a lot of the processor intensive transformations and filtering. > Don't even waste your time trying to make Linux perform up to the > standards of a professional recording studio. > It can't be done, at least not commercially. Not true, it can be done. It requires a bunch more work up front but does yield an environment that is very open to automation of repetitive tastes and insertion of custom tools into the process. Not something everyone needs but a godsend for those of us who do need it. > IOW if you are playing back 16 tracks and overdubbing a vocalist at the > same time, going through (monitoring) your sound card and you have too > much latency, usually more than 10msec, but less for many, the singer will > not be in time with the already recorded music. > Or if you are playing a VSTI instrument you will *feel* a delay at the > keyboard. Resyncing is a non-issue. Any delay in the pipeline is deterministic; the software adjusts for it when it merges the tracks together in the output file. The VSTI instrument delay could be an issue, but not one I have encountered; I have mainly been layering in vocal layers. When I do plunk around on my sampling keyboard, I tend to let it generate its own tones rather than depend on my workstation. Nevertheless, I see no technical reason this should be a problem. Linux can service hardware interrupts plenty fast for this sort of thing. If anyone has real experience with this issue, though, I would love to hear about it. > My studio runs under Windows, but my network including family PC's run > Linux, except for one iMac. > I suggest you try the same. Sounds about like my network, a mix of Linux and Windows (now used mostly for games) and a single Mac. Cheers, Thad |
|
|||
|
In comp.os.linux.advocacy flatfish+++ <flatfish@linuxmail.org> wrote:
> > This is a very simple concept. > Windows does it easily, today and now. > Linux? > I'm sure it can be done, but easily? > No way. This is not what you were saying earlier... you essentially said Linux could not be used in this capacity at all. Yes, Linux requires more work up front. The question is, do you gain something extra for that work and is it worth it. The answer depends on your specific needs. For a subset of uber-geeky audiophiles, the answer is 'yes'. > Somewhat correct. > The amount of buffers effects the latency, but there are trade offs > depending upon the OS AS WELL as the program and the hardware as well. > IOW you may get 6 msec with Nuendo but only 10 with Sonar (made up numbers). > > Also each independent application, say Soundforge and Sonar, can have > their own latencies running at the same time. > That is why the applications control it. > > The soundcard is profiled during the setup of the program and it > determines the amount of latency that is suggested, and this default > number is generally a very low value especially with ASIO drivers. This is essentially how it works in Linux also. The OS layer passes the data blazingly fast. Any real delay is caused by buffering in the application layer. > It depends. > But again you are all over the place. > > You are talking theory, and I am talking here today, and doing it NOW. Actually, having built audio/video editing environments on both Windows and Linux, I don't think Windows is really out front on this one. On Windows the apps were well development, but I spent too much time fighting the OS to get reliable performance. On Linux the OS gave fast, consistant performance, but the apps were not as developed. Of course with the Mac I just plunked in Final Cut Pro, Garage Band, etc and got to work. More recently, their are new Linux distros geared specifically toward making multimedia work easier. You can supposedly just boot of the CD and go to work. I have not tried it, so anyone who has, throw your experiences into the COLA blender. :) Later, Thad |