30 Jan
2007
30 Jan
'07
2:35 p.m.
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(a)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