Re: [linux-audio-dev] Old hat - comparison against windows
On Tue, 2007-01-30 at 23:30 +0100, [EMAIL PROTECTED] wrote: On Tue, Jan 30, 2007 at 09:18:06PM +, Bob Ham wrote: On Tue, 2007-01-30 at 21:05 +, Bob Ham wrote: On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: Can anyone suggest ways to compare audio/midi performance between Linux and Windows that ... make Linux compare favorably? I work for a company that sells a Linux based piece of hardware that plays windows VSTs. The word FUD comes to mind. No idea why. 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. the customers dont notice. they still use windows or no computers at all. it looks rather like a question from the management. You are correct there. From the modern business perspective, though, management are Michael's personal customers. I think the argument still applies. If your goal is to convince someone that your choice of linux is correct, telling them why you chose linux in the first place seems, to me at least, to be the best method, rather than seeking out reasons which you yourself haven't been concerned with previously. Bob -- Bob Ham [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [linux-audio-dev] Old hat - comparison against windows
On 31 Jan 2007, at 11:27, Bob Ham wrote: On Tue, 2007-01-30 at 23:30 +0100, [EMAIL PROTECTED] wrote: On Tue, Jan 30, 2007 at 09:18:06PM +, Bob Ham wrote: On Tue, 2007-01-30 at 21:05 +, Bob Ham wrote: On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: Can anyone suggest ways to compare audio/midi performance between Linux and Windows that ... make Linux compare favorably? I work for a company that sells a Linux based piece of hardware that plays windows VSTs. The word FUD comes to mind. No idea why. 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. the customers dont notice. they still use windows or no computers at all. it looks rather like a question from the management. You are correct there. From the modern business perspective, though, management are Michael's personal customers. I think the argument still applies. If your goal is to convince someone that your choice of linux is correct, telling them why you chose linux in the first place seems, to me at least, to be the best method, rather than seeking out reasons which you yourself haven't been concerned with previously. I don't think that's necessarily the case, just because Linux had better RT performance in 2000 doesn't mean it still does today, with Vista and general improvements. I think it's reasonable for management to question if it's still the best choice. - Steve
Re: [linux-audio-dev] Old hat - comparison against windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Harris wrote: On 31 Jan 2007, at 11:27, Bob Ham wrote: [...] I don't think that's necessarily the case, just because Linux had better RT performance in 2000 doesn't mean it still does today, with Vista and general improvements. I think it's reasonable for management to question if it's still the best choice. pick two out of three: cheap, quick, good. - Who's in the management? :) IMO most modern PC/PPC hardware and OS are equally good enough for non-hi-end audio engineering. - tweak your personal flavor! [hardware-]end-users are concerned about low-latency, scalability and reliability. (audio-processing-quality, easy-use, etc. are irrelevant here) Pro's for gnu/Linux that come to my mind: - flexibility (all kinds of... GNU) - reliability (you have the option to see what's the OS/HW is doing) - existing free Live-cds - active and open developer community ;-) - ... Cons; If windows wants it can perform better than a fully fledged rt-unix-kernel. - but that remains to be proven for Vista! It would be nice to have a software-suite to compare linux-audio-realtime performance .. - For linux/linux tests there seem to be various code-snippets out there... does anyone care to share pointers? robin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFwJGUeVUk8U+VK0IRAlBcAJ92OtWRExkXGwzf1OFxdCTlXW2KLQCgpX+9 AbZjWHeYCQ47Zy5OnRebsnY= =incw -END PGP SIGNATURE-
Re: [linux-audio-dev] Old hat - comparison against windows
On Wed, 2007-01-31 at 13:54 +0100, Robin Gareus wrote: Cons; If windows wants it can perform better than a fully fledged rt-unix-kernel. - but that remains to be proven for Vista! Are you saying that this is true for XP? Are there any references for that? --ll
Re: [linux-audio-dev] Old hat - comparison against windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Luthman wrote: On Wed, 2007-01-31 at 13:54 +0100, Robin Gareus wrote: Cons; If windows wants it can perform better than a fully fledged rt-unix-kernel. - but that remains to be proven for Vista! Are you saying that this is true for XP? Are there any references for that? maybe not for audio-apps. I once read some books about subverting the windows kernel - one can do marvelous stuff and get great performance out of it!! - only half kiddingly. - luckily I have not booted into XP for years and this Con might just be crap... however some instinct tells me that a UNIX - no matter how pre-emptive or tweaked - will always have more overhead than some DirectX-app. - but IMO this is irrelevant for normal audio apps on modern machines.. - memory management and -locking are more crucial.. robin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFwKJJeVUk8U+VK0IRAguvAKC5WkK6enqRl5YXpuqoY6hpdcjiCwCeKxSG Mqz4u/A+Eg8g/LD21Jvrlbc= =+Sl0 -END PGP SIGNATURE-
Re: [linux-audio-dev] Old hat - comparison against windows
On 31 Jan 2007, at 14:06, Robin Gareus wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Luthman wrote: On Wed, 2007-01-31 at 13:54 +0100, Robin Gareus wrote: Cons; If windows wants it can perform better than a fully fledged rt-unix-kernel. - but that remains to be proven for Vista! Are you saying that this is true for XP? Are there any references for that? maybe not for audio-apps. I once read some books about subverting the windows kernel - one can do marvelous stuff and get great performance out of it!! - only half kiddingly. - luckily I have not booted into XP for years and this Con might just be crap... however some instinct tells me that a UNIX - no matter how pre-emptive or tweaked - will always have more overhead than some DirectX-app. - but IMO this is irrelevant for normal audio apps on modern machines.. - memory management and -locking are more crucial.. I don't know if it's still the case, but a few years ago the NT kernel was very heavyweight compared to the UNIX kernel, and too a long time to do things like context switches. - Steve
Re: [linux-audio-dev] Old hat - comparison against windows
Greetings: Michael Gogins recently tested Csound5 with Windows XP Media Center Edition and with Ubuntu 6.10. His tests indicated that Linux was the slightly better performer, you can check out his post and commentary on the Csound mail list archive : http://sourceforge.net/mailarchive/forum.php?thread_id=31517593forum_id=43699 Best, dp
Re: [linux-audio-dev] Old hat - comparison against windows
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
Re: [linux-audio-dev] Old hat - comparison against windows
I would not rule out that Linux is found to perform worse under some circumstances. But that is ok. Adaptability is one of the strong points of open source, once we know the problems we can start fixing them. Nice point and this is the strength of OS. the problems are addressed far quicker than in Prop' software. Cheers Bob On 31/01/07, Robert Jonsson [EMAIL PROTECTED] wrote: Hi, [EMAIL PROTECTED] skrev: On Tue, Jan 30, 2007 at 09:18:06PM +, Bob Ham wrote: On Tue, 2007-01-30 at 21:05 +, Bob Ham wrote: On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: Can anyone suggest ways to compare audio/midi performance between Linux and Windows that ... make Linux compare favorably? I work for a company that sells a Linux based piece of hardware that plays windows VSTs. The word FUD comes to mind. No idea why. 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. the customers dont notice. they still use windows or no computers at all. it looks rather like a question from the management. Whatever the reasons, it's a valid and interesting question. In truth Linux is often touted (not the least with respect to audio) as a better performer than Windows. Though I can't say that I have personally experienced this. It is hard work getting a Linux system tuned, I have actually never succeeded without some drawback that have forced me back to generic configurations. Not that I complain, my current (k)ubuntu kernel performs good enoughtm, but I am certain it would be no problem getting equal performance under Windows. My choice of using Linux has more to do with the freedom of opensourceness (it's a word!..now atleast). Steve's idea with a vst timing plugin sounds very interesting. One using LADSPA would be equally interesting for comparing Linux to Linux. Are there other performance measurements that would be nice? xruns under load I suppose. Having a test suite for system performance would be great! I would not rule out that Linux is found to perform worse under some circumstances. But that is ok. Adaptability is one of the strong points of open source, once we know the problems we can start fixing them. Regards, Robert
Re: [linux-audio-dev] Old hat - comparison against windows
On Tue, 2007-01-30 at 21:05 +, 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
Re: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, Michael Ost [EMAIL PROTECTED] 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
Re: [linux-audio-dev] Old hat - comparison against windows
2007/1/31, Michael Ost [EMAIL PROTECTED]: 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?
Re: [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
Re: [linux-audio-dev] Old hat - comparison against windows
Frank Smith [EMAIL PROTECTED] Nice point and this is the strength of OS. the problems are addressed far quicker than in Prop' software. Yes, that's good. Microsoft doesn't give a hoot about professional audio. We can actually tweak the OS, and Wine, to improve performance of our specific application. We got an improvement of Wine's CRITICAL_SECTION implementation in (using futexes) that helped DFH perform during heavy use of a particular drum. - mo
Re: [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 --'
Re: [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: [...] 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? ;-) 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
Re: [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: 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? ;-) 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. 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 --'
Re: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, David Olofson [EMAIL PROTECTED] 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
Re: [linux-audio-dev] Old hat - comparison against windows
On Wednesday 31 January 2007 22:49, Lee Revell wrote: On 1/31/07, David Olofson [EMAIL PROTECTED] 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. 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 --'
Re: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, David Olofson [EMAIL PROTECTED] 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
Re: [linux-audio-dev] Old hat - comparison against windows
On Wednesday 31 January 2007 23:39, Lee Revell wrote: On 1/31/07, David Olofson [EMAIL PROTECTED] 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. 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 --'
