[linux-audio-dev] Old hat - comparison against windows
frsmith at gmail.com
Tue Jan 30 18:33:37 UTC 2007
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
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
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!
On 30/01/07, Steve Harris <steve at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linux-audio-dev