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 <steve@plugin.org.uk> 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