Hi I can only give you a musicians 'real world' comment.
I had Sonar on my XP box and used it a lot for multitracking. It was an a Athlon 3400 64 ( running 32 xp) 1 gig ram and an RME card for sound. It ran fine on the XP box but still had a few wobblies re dropout after about 10 tracks. Can I point out I use all instruments live and record them to disk, haven't got Midi working yet. Thing is as you changed the tracks redoing some live again I noticed a slight compression on the tracks. It seemed to build up as you used more stuff on the tracks IE: reverbs and such. Not long after I installed 64studio and used Ardour doing the same kind of stuff, running 46 of course, and I didn't get this effect even on more tracks and using effects. To my ears the end result sounds cleaner and more like the original. Just my 2 p's worth! Cheers Bob wavesound On 30/01/07, Steve Harris <[EMAIL PROTECTED]> wrote:
On 30 Jan 2007, at 17:03, Michael Ost wrote: > Can anyone suggest ways to compare audio/midi performance between > Linux > and Windows that (1) are relevant to non-technical musicians and (2) > make Linux compare favorably? > > Not things like "I just don't like Windows" or software feature > comparisons or the politics of open vs. closed source, but rather > things > like responsiveness to audio interrupts, RAM footprint of the OS > and ...? > > I work for a company that sells a Linux based piece of hardware that > plays windows VSTs. We spend alot of time on compatibility, > especially > on getting the plugins to work with Wine. I often get asked about > switching to Windows and I don't have a good answer. > > My sense is that the main benefit of Linux is that audio interrupts > are > serviced faster and more predictably than in Windows because of > SCHED_FIFO and Linux's low overhead. And clearly musicians could feel > that, especially at lower buffer size settings so that's the kind of > thing that could matter. I would have thought that the best way to measure scheduler performance is to write a simple VST plugin that writes the precise time at which it was called into a ram buffer, and writes the buffer out to disk after a few tens of thousands of calls. You can the measure the times between adjacent runs and work out if there's any significant difference in jitter. I would think that the RAM footprint is essentially impossible to measure, as you can't tell what proportion of the kernel space is buffers etc. From a commercial point of view, your are at the very least saving licence fees for each piece of hardware, that would surely eat into your profit margin. - Steve
