31 Jan
2007
31 Jan
'07
3:33 p.m.
On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote:
Further to that, something constructive: perhaps you could try telling
your customers why *you* chose linux, rather than trying to find reasons
to tell them *they* should.
My reasons, from back in about 2000, were "cost" and "interesting".
First off the license costs were not hard to sell. And secondly that I
personally wanted to program in Linux. I thought it would be interesting
--- and it has been fun. Also the company was kind of a crapshoot and I
wanted the professional experience on my resume if I needed to go get
another job. Embedded Linux sounded good to me.
I want to stick with Linux and hoped there were some measurable
performance differences to tout. Sounds like there aren't, really.
And now for some more kind of Dilbert-esque background for the curious...
A couple of years ago, we tried answering this question by measuring the
time between a midi impulse on a rigged midi cable and audio output on
an oscilloscope. We tested Receptor vs Windows 2000 running VStack. The
Receptor was not more responsive but was less jittery in its reponse.
We engineers didn't feel that the results were carefully enough
generated to be publicly announced, but we felt that our hunch was being
confirmed.
Then I made some perhaps loose comments about how Linux is less bloated
than Windows. True, but not quantifiable.
Then there is the general (and vague) perception among many in the music
biz that Windows is not for pro audio.
All of these factors led our non-tech people here to start saying that
our OS was better. Being an engineer, and not being able to quantify
"better", I would cringe when they would say that and qualify endlessly.
But I also couldn't prove anything either way, so I kind of left it.
As time has passed, I have found that I was naive about the costs of
Wine (VST compatibility, Linux (hardware compatibility, especially USB
and firewire audio/midi devices) and the costs of getting programmers
productive on Linux as a development platform.
Now it is time for a leap to a newer OS --- 2.4 isn't giving us SATA
drive support and our Wine is getting old (vinegar? %). Our code could
do Windows pretty easily. Should I push for that, or move to a newer Linux?
There you have it. Life in the software business.
By the way, I appreciate all of the comments. I expected it might be a
loaded question! ... mo
31 Jan
31 Jan
3:44 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, Michael Ost <most(a)museresearch.com> wrote:
Now it is time for a leap to a newer OS --- 2.4
isn't giving us SATA
drive support and our Wine is getting old (vinegar? %). Our code could
do Windows pretty easily. Should I push for that, or move to a newer Linux?
I would say it depends on how much Windows would cost per unit, and
whether you can tolerate being at the mercy of vendors and Microsoft
to fix any bugs you find.
However I didn't realize that you were using 2.4. 2.6 with the -rt
patches should definitely give better latency than Windows. In fact
it's capable of uselessly low latencies like 0.66ms on some hardware,
which is exactly the kind of thing the marketing guys love ;-)
Lee
4:03 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
Lee Revell wrote:
However I didn't realize that you were using 2.4.
2.6 with the -rt
patches should definitely give better latency than Windows. In fact
it's capable of uselessly low latencies like 0.66ms on some hardware,
which is exactly the kind of thing the marketing guys love ;-)
We have a 32 sample setting (.7 msecs) in Receptor which I have yet to
see in a Windows driver. And it actually works with some plugins, even a
large sampler like Synthogy Ivory --- if you don't try to play too many
notes. %)
So, yes, thanks, that's an idea.
- mo
4:36 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
On Wednesday 31 January 2007 21:02, Michael Ost wrote:
[...]
We have a 32 sample setting (.7 msecs) in Receptor
which I have yet
to see in a Windows driver. And it actually works with some plugins,
even a large sampler like Synthogy Ivory --- if you don't try to
play too many notes. %)
[...]
Have you considered RTAI/LXRT (microsecond scale hard real time in
user space, sort of) for really insane latencies? ;-)
You would have to wire any API calls used in real time threads to
implementations over RTAI, as you'll be switched back to normal
SCHED_FIFO if you try to make any normal system calls. Further, you'd
have to use shared memory (ie raw DMA buffer) mode, and
some "external" synchronization mechanism, so you can avoid talking
directly to the audio driver from the RT thread.
Now, you still can't get below the minimum latency of the sound card,
which is usually defined by the PCI DMA burst size. Scheduling jitter
can be low enough to process one sample at a time at 44.1 kHz, but
the only real use for that is better CPU utilization; that is, you
can push closer to 100% load without getting dropouts.
Of course, all of this is pretty much moot, unless all code that runs
in the real time thread is strictly deterministic. My point is just
that with an Open Source OS, at least in environments where you can
have total control over the whole system, you don't have to stop
at "sensible" solutions. There really is no limit to what you can do,
if you really have to or want to, and have the time and resources at
hand.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
4:46 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
On Wed, 2007-01-31 at 21:35 +0100, David Olofson wrote:
On Wednesday 31 January 2007 21:02, Michael Ost
wrote:
[...]
there are no drivers for any audio interfaces that run in RTAI kernel
space or in user space.
theoretically, its cool an' all; practically speaking, i think its
useless.
--p
We have a 32 sample setting (.7 msecs) in
Receptor which I have yet
to see in a Windows driver. And it actually works with some plugins,
even a large sampler like Synthogy Ivory --- if you don't try to
play too many notes. %)
[...]
Have you considered RTAI/LXRT (microsecond scale hard real time in
user space, sort of) for really insane latencies? ;-)
5:22 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
On Wednesday 31 January 2007 21:45, Paul Davis wrote:
On Wed, 2007-01-31 at 21:35 +0100, David Olofson
wrote:
There are a few hacks for RTAI and/or RTLinux, actually, but AFAIK,
nothing for any serious hardware... (I did one myself a few years
ago, for RTLinux and AudioPCI cards, IIRC.)
Anyway, this is why I'm suggesting memory mapped mode. Instead of
blocking in the driver calls, the audio thread would block on a
periodic RTAI timer. The timer would be kept in sync with the
hardware using an RTAI interrupt handler on the sound card IRQ, or
(possibly simpler but less accurate) by a SCHED_FIFO thread that does
talk to the driver.
It's pretty much the same method used by many PC game and demo sounds
systems back in the DOS days. Instead of running the audio code in
the interrupt context (if there was any!), it was run either in the
video main loop or in some timer interrupt, while the DMA just kept
looping over a buffer of 64 kB or so.
For running audio code under RTAI, it would probably be more
appropriate to adjust the timer interval to keep the fragment size
constant, but of course, the other way around may work too, depending
on the plugin API and/or plugin implementations. You'd have to infer
the timings either way, unless you can somehow read the current DMA
position from the RTAI thread.
All that said, MIDI I/O would still be restricted to SCHED_FIFO
scheduling. Missing MIDI deadlines is usually a lot less serious than
missing audio deadlines, though, so it may not be a real issue.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
On Wednesday 31 January 2007 21:02, Michael Ost
wrote:
[...]
there are no drivers for any audio interfaces that run in RTAI
kernel space or in user space.
theoretically, its cool an' all; practically speaking, i think its
useless. We have a 32 sample setting (.7 msecs) in
Receptor which I have
yet to see in a Windows driver. And it actually works with some
plugins, even a large sampler like Synthogy Ivory --- if you
don't try to play too many notes. %)
[...]
Have you considered RTAI/LXRT (microsecond scale hard real time in
user space, sort of) for really insane latencies? ;-)
5:49 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, David Olofson <david(a)olofson.net> wrote:
There are a few hacks for RTAI and/or RTLinux,
actually, but AFAIK,
nothing for any serious hardware... (I did one myself a few years
ago, for RTLinux and AudioPCI cards, IIRC.)
There's no point these days - the 2.6 -rt kernel can already deliver
latencies down to the hardware limit.
Lee
6:25 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
On Wednesday 31 January 2007 22:49, Lee Revell wrote:
On 1/31/07, David Olofson <david(a)olofson.net>
wrote:
Yes, but that's not all there is to it.
Jitter reduces the amount of CPU time available for real time
processing. Worst case jitter of N ms means you can't safely use more
than M - N ms per fragment, where M is the fragment period. Triple
buffering or dynamic fragment size may cut you some extra slack in
relation to total latency (same logic as triple buffering with
OpenGL), but this isn't supported by all hardware.
Related to this, making efficient use of multiple CPUs and/or cores
requires much tighter timing than UP processing, unless you can get
away with running multiple independent audio "pipes" in parallell.
The inter-thread sync can be solved with lock free mechanisms, but
that doesn't help much if threads with tight interdependencies get
out of phase due to scheduling latencies.
That said, as you can't use all CPU time on a UP machine anyway, and
as cache issues seem to make multithreaded processing virtually
pointless (with the possible exception of multicore CPUs), it's
entirely possible that there is no real gain in cutting latencies
below what 2.6-rt can provide. I don't know, but it might be worth
some experiments...
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
There are a few hacks for RTAI and/or RTLinux,
actually, but
AFAIK, nothing for any serious hardware... (I did one myself a few
years ago, for RTLinux and AudioPCI cards, IIRC.)
There's no point these days - the 2.6 -rt kernel can already deliver
latencies down to the hardware limit.
6:40 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, David Olofson <david(a)olofson.net> wrote:
That said, as you can't use all CPU time on a UP
machine anyway, and
as cache issues seem to make multithreaded processing virtually
pointless (with the possible exception of multicore CPUs), it's
entirely possible that there is no real gain in cutting latencies
below what 2.6-rt can provide. I don't know, but it might be worth
some experiments...
Maximum jitter with 2.6-rt is 20-50 microseconds last time I checked.
So less than 5% even at a marginally useful period sizes like 32
frames.
Lee
6:45 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
On Wednesday 31 January 2007 23:39, Lee Revell wrote:
On 1/31/07, David Olofson <david(a)olofson.net>
wrote:
Well, that's not even an order of magnitude away from what you can get
with a "true" RTOS on this type of hardware. (You can get a lot worse
with crappy motherboards, regardless of OS...)
If that's really the worst case, I don't think there is room for any
significant improvement, even in theory. :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
That said, as you can't use all CPU time on a
UP machine anyway,
and
as cache issues seem to make multithreaded processing virtually
pointless (with the possible exception of multicore CPUs), it's
entirely possible that there is no real gain in cutting latencies
below what 2.6-rt can provide. I don't know, but it might be worth
some experiments...
Maximum jitter with 2.6-rt is 20-50 microseconds last time I
checked.
So less than 5% even at a marginally useful period sizes like 32
frames. 
3:46 p.m.
New subject: [linux-audio-dev] Old hat - comparison against windows
2007/1/31, Michael Ost <most(a)museresearch.com>om>:
Now it is time for a leap to a newer OS --- 2.4
isn't giving us SATA
drive support and our Wine is getting old (vinegar? %). Our code could
do Windows pretty easily. Should I push for that, or move to a newer Linux?
I think there is no general answer, however it mostly depends on the people,
do you have any significant experience programming on the win32 platform?
Do your engineers have any significant experience?
I've made the observation on myself, that once you are immersed in an open
and free platform, it is very hard to go back to something like win32. You just
get used to a lot of things that are natural on your platform, which are
hardly available outside. Every once in a while I port some software from
Linux to Windows, and beforehead I think: "Can't be that hard, all the tools are
available." And then the cursing starts.
Have try, and do some work on windows, if you think you can handle it, it might
be an option. But if you have any doubts, drop it. It seems that you
have a lot of
Linux-Experience. This is a serious investment that I wouldn't throw
away lightly.
Cheers
-Richard
--
Are you teaching the What and the How but without the Why and the When?
6463
days inactive
6463
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
David Olofson -
Lee Revell -
Michael Ost -
Paul Davis -
Richard Spindler