On Sun, 2010-01-24 at 17:46 +0300, Louigi Verona wrote: The 290 employees at KORG is raking in a cool $16,419.7 million in annual sales from their efforts, so they might deviate just slightly from our most humble opinions. :-D http://www.hoovers.com/company/Korg_Inc/rfcjhyi-1.html

On Sun, 2010-01-24 at 14:38 -0500, drew Roberts wrote: That would be a conclusion based on false logic.

On Mon, 2010-01-25 at 09:25 +0000, Victor Lazzarini wrote: Yes it does sound a bit excessive, doesn't it? According to the same website, Roland is selling for $40 billion. This includes their Video gear though. And then again, Yamaha is selling for only $4 billion, which is highly surprising compared to the two others?! Did something get lost in translation? Are these figures really Taiwan or Hong Kong dollars? Yen? Roland is publically traded and hence publish their key data, which tells us that their sales for 2009 were at ¥100,506,864,000 (Yen!) which then again still translates to around a billion US dollars - but nowhere near the forty like it was quoted in the link I gave yesterday. Sorry ... Roland: $1 billion http://www.corporateinformation.com/Company-Snapshot.aspx?cusip=C39242560 Yamaha: $4 billion http://www.corporateinformation.com/Company-Snapshot.aspx?cusip=C39283560 Kawai: $1/2 billion http://www.corporateinformation.com/Company-Snapshot.aspx?cusip=C392AK960 My guess is that KORG would be selling maybe like Kawai? (while of course targetting an entirely different market.) In any case, $16 billion does not sound reasonable. ... And now back to our regular programming: "How to make useful musical instruments out of the techno-trash others have thrown in the dumpster?"

On Mon, 2010-01-25 at 09:25 +0000, Victor Lazzarini wrote: Yes it does sound a bit excessive, doesn't it? According to the same website, Roland is selling for $40 billion. This includes their Video gear though. And then again, Yamaha is selling for only $4 billion, which is highly surprising compared to the two others?! Did something get lost in translation? Are these figures really Taiwan or Hong Kong dollars? Yen? Roland is publically traded and hence publish their key data, which tells us that their sales for 2009 were at ¥100,506,864,000 (Yen!) which then again still translates to around a billion US dollars - but nowhere near the forty like it was quoted in the link I gave yesterday. Sorry ... Roland: $1 billion http://www.corporateinformation.com/Company-Snapshot.aspx?cusip=C39242560 Yamaha: $4 billion http://www.corporateinformation.com/Company-Snapshot.aspx?cusip=C39283560 Kawai: $1/2 billion http://www.corporateinformation.com/Company-Snapshot.aspx?cusip=C392AK960 My guess is that KORG would be selling maybe like Kawai? (while of course targetting an entirely different market.) In any case, $16 billion does not sound reasonable. ... And now back to our regular programming: "How to make useful musical instruments out of the techno-trash others have thrown in the dumpster?"

On Tue, Jan 26, 2010 at 03:15:43PM -0500, David McClanahan wrote: That's not how Linux audio works. Processing is done in blocks of typically between 64 and 1024 samples. With current kernels you don't even need any RT patches to get good performance, unless you need very low latency (i.e. very small block sizes). I've been working most of the day on a 64-channel system with several quite complex apps, and I haven't seen a single xrun. Standard unpatched 2.6.32 kernel. If you get xruns on a correectly set-up system (and that requires very little these days) it's probably because the apps you use have not been written in the way required to perform well in a realtime context. Unfortunately there are many like that. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Tue, Jan 26, 2010 at 3:15 PM, David McClanahan <david.mcclanahan(a)gmail.com> wrote: Just a note, I know there will be lots of different answers to your post, but in the midst of all that could we have a small side discussion on precisely this topic? I have been using Xenomai recently for non-audio related research, and found it not too hard to use. (Other than the fact that I had to patch and compile the kernel myself.) However, this was with some custom PCI hardware for which I had driver source code which I translated to the RTDM model myself. (Which was quite easy actually. RTDM is not a bad driver model at all-- in some ways more consistent than the Linux driver model.) Does anyone have experience porting audio drivers to RTDM? Or... is it possible to use ALSA in conjunction with Xenomai somehow? I'm particularly interested for small embedded systems, but the old Dell laptop in question is also I think a valid scenario. thanks, Steve

On Thu, Jan 28, 2010 at 1:55 PM, David McClanahan <david.mcclanahan(a)gmail.com> wrote: on a machine with virtual memory and 3 levels of cache? sounds, uh, hard.

Hey! Bristol synths are very good, but I have problems with them. They do run on my system, but I am not able to use most of them reliably, since if you play fast or play a long succession of notes, the synth simply uses up too many resources and eventually gets kicked out of jack. So my dream to use all those synths in a real-time performance are still only dreams. I have been in close contact with the developer and as far as I understood he does not have such an issue on his machine. He will soon release a new version and we'll see how it goes, but at the moment Bristol synths seem to be using too much resources to be used for live performance and my machine is nowhere near being old, with a DUO P8600 CPU and 4Gb of RAM it should fly. Louigi Verona. On Wed, Jan 27, 2010 at 4:15 AM, David McClanahan < david.mcclanahan(a)gmail.com&gt; wrote:

Which is interesting. I did not notice on my ASUS laptop any significant difference between rt-kernel and a normal one. It was there - a bit less dropouts, but the change was not significant, meaning that my non RT kernel mode works almost as good. On Wed, Jan 27, 2010 at 9:47 AM, David Olofson &lt;david(a)olofson.net&gt; wrote:

On Thu, Jan 28, 2010 at 03:01:38PM -0500, David McClanahan wrote: i still dont understand how building a highway, can speed up a bicycle with a flat tire. you should try a car on a normal road. will get you where you want. you named the set of synths which are not RT safe. (i dont really know about fluidsynth, but zyn and especially bristol arent clean) thats what i meant with bicycle. we are talking about a buffer of 3ms here. sound travels about 1 meter in that time. -- torben Hohn

On Thu, 28 Jan 2010, David McClanahan wrote: Well, knock yourself out. Make us all proud! As Torben said, Bristol and Zyn are well-known to be programmed in a manner that is NOT RT-safe... even if the OS is RT-safe. Meanwhile, lots of folks here are getting good performance with Linux audio without a ton of fiddling. Correct. And the entire OS and hardware is dedicated to the task of synth. And the hardware is generally application-specific. In fact, most of your hardware synths (whether analog or digital) are build around several application-specific integrated circuits (ASIC) that act as co-processors for specific tasks (whether an oscillator or DSP). GNU/Linux, on the other hand, is a general-purpose, multi-tasking operating system for non-specific hardware. Most people coming to Linux are /not/ looking for an OS to turn their PC into a dedicated synth. So, duh, the -rt kernels for a desktop OS are not fit to be used for a safety-critical control system than needs HRT. For that sort of application, you need a customized version of Linux fine-tuned for the hardware. Why hasn't it happened, yet? Because most folks don't want this from Linux. And those that /do/ realize that it is hardware specific, and you /will/ have to roll your own OS (e.g. Korg, Harrison Consoles). You can't just download "KewlSynthOS" and run it, because there are several prerequisite hardware components to make the system run properly (whether off-the-shelf or home-grown). No buffering? We're talking about DIGITAL signal processing, right? Are you serious? -gabriel

On Thursday 28 January 2010, at 21.01.38, David McClanahan &lt;david.mcclanahan(a)gmail.com&gt; wrote: [...] This has nothing to do with the definition of hard realtime. These lowlatency kernels don't even claim to be *hard* realtime. I think you'd get "lowlatency" or possibly "firm realtime", depending on who you ask. True hard realtime systems don't really exist, but if we accept hardware failure and application bugs as acceptable reasons for failure, we can get pretty close. For Linux, you'd go with RTAI or RT-Linux. However, although running all realtime audio code under RTAI or RT-Linux might offer a slightly lower risk of drop-outs, those are pretty harsh environments, even compared to the "strict" requirements of JACK clients, realtime safe LADSPA or LV2 plugins and the like. You basically cannot use ANY syscalls, but have to work with a completely different API. (RTAI/LXRT does allow hard realtime code to run in userspace, but when a thread is actually running in hard realtime context, it will be thrown back to "standard" mode as soon as it makes an ordinary syscall.) More seriously, you cannot make use of ANY normal Linux drivers. Drivers have to be ported, so that all code involved in the hard realtime "loop" actually runs under the realtime kernel, and not Linux. Even more seriously, there is just no way that any realtime kernel can ensure anything on bad hardware. If BIOS super-NMIs are blocking normal IRQs every now and then, or you have some device + driver combo that abuses PCI bus blocking (common issue with 3D accelerators), you may get worst case latencies of any number of milliseconds - and there is nothing at all that any OS can do about this. You *may* be able to avoid these issues by replacing cards, patching or reconfiguring drivers or tweaking the BIOS settings, but as general purpose PC/workstation hardware isn't really designed for this sort of work, there are no guarantees. It basically comes down to trying hardware until you find something that does the job. BTW, this has very little to do with raw performance. A faster CPU does let you finish the job quicker, but if you wake up too late, you still won't be able to make the deadline... The bottom line is that, in the context of mainstream hardware and systems that aren't specifically put together for lowlatency audio work, this is a matter of diminishing returns. Indeed, it's possible to do better than a lowlatency kernel, but it's a lot of work, and it's completely wasted without perfectly configured, well behaved hardware. Sure, RTAI or RT-Linux would support 0.1 ms audio latency on a purpose built system with ported drivers, properly configured BIOS, SMI hacks etc, but it just won't happen on your average PC. Well, yes - but going beyond lowlatency kernels, it's usually the hardware you need to deal with; not the OS... Same difference. If you have sufficiently solid scheduling for the realtime processing part, you can build pretty much anything around that. [...] It's not about sophistication. A low cost singleboard computer with an AMD Geode, VIA C7, some Intel Celeron or whatever you need in terms of raw power, will do just fine - as long as the chipset, BIOS and connected devices are well behaved and properly configured. If you, as a manufacturer of synths or similar devices, don't want to try a bunch of different motherboards for every new revision you make, you might decide to design your own board instead. Then again, if your product is low volume and requires enormous CPU power, carefully selected mainstream hardware may still be a better option. SMI is one of them. In my experience, nearly every motherboard at least has some BIOS features you must stay away from, so even "know good" hardware sometimes need special tuning for this sort of work. General purpose computers just aren't built for low latency realtime work - but most of them can still do it pretty well, with some tweaking. [...] [...] That's just pointless, as the ADC and DAC latencies are already several sample periods, and the way DMA works on any PCI, USB or 1394 soundcard will add somewhere around 64 bytes' worth of latency or more to that. Also note that your average MIDI synth has anywhere from a few through several tens of milliseconds of latency! You can only send around 1000 messages per second over a standard MIDI wire anyway, so where would you get the timing information to make use of less than 1 ms latency? Actually, going below a few ms only guarantees that the notes in a chord can never be triggered simultaneously. [...] For knobs and similar "analog" controls, I'd say it takes at least tens of ms before you start to notice any latency. For keys, I personally think it starts to feel weird if the latency approaches 10 ms. More importantly though, latency must be *constant*! A synth that just grabs all pending events once per buffer cycle won't be playable with more than a few ms of latency, as the "random" response times quickly become very noticeable and annoying as the "average" latency increases. If incoming events are properly timestamped and scheduled, this is much less of an issue, and latency has the same effect as varying the distance to the monitor speakers. -- //David Olofson - Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://olofson.net http://kobodeluxe.com http://audiality.org | | http://eel.olofson.net http://zeespace.net http://reologica.se | '---------------------------------------------------------------------'

On Fri, Jan 29, 2010 at 5:24 PM, David McClanahan &lt;david.mcclanahan(a)gmail.com&gt; wrote: No, not enough. You still don't seem to grasp that (a) hard realtime is NOT required for systems doing pro-audio or synthesis (b) latency matters a lot, but not as much as some people think (c) doing hard realtime on a general purpose processor on a general purpose OS is asking for trouble (d) meeting deadlines these days has more to do with everything in the box *except* the processor --p

On Tue, 2010-01-26 at 15:15 -0500, David McClanahan wrote: There is a difference between 'any Linux system' and 'a Linux System built for audio' A Roland/Yamaha styled HW synth will at least have one dedicated DSP - or even custom built logic - directly connected to its ADC/DAC to do the single innermost loop that is the RT-application. Everything else is for display, blinken-lights and monitoring state of knobs and buttons. A $150 Beagle Board has the nescessary HW and connectivity to work like that. Your Dell laptop does not.