To all concerned, I've gotten quite a few responses and rather respond individually to each every one I'm responding to David Olufson's because his is overall the most sensible and informative. I'll respond to some of his indivdual points and then finish with this in general at the end.<br>
<br><div class="gmail_quote">On Thu, Jan 28, 2010 at 8:32 PM, David Olofson <span dir="ltr"><<a href="mailto:david@olofson.net">david@olofson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 28 January 2010, at 21.01.38, David McClanahan<br>
<div class="im"><<a href="mailto:david.mcclanahan@gmail.com">david.mcclanahan@gmail.com</a>> wrote:<br>
[...]<br>
</div><div class="im">> > The relevant definition of "hard realtime system" here is "a system that<br>
> > always responds in bounded time." That bounded time may be one<br>
> > microsecond or one hour, but as long as the system can meet it's deadline<br>
> > every time, it's a hard realtime system. The definition doesn't really<br>
> > imply any specific time frames.<br>
><br>
> I agree with the definition but feel its a bit incomplete. Somebody can<br>
> write a piece of software and performance test it on a "soft realtime"<br>
> system and it meet all its deadlines DURING THE TEST. But a hard realtime<br>
> system should have mechanisms(the scheduler and timing analysis of the<br>
> code) to insure the deadlines are met. The current "RT patches" system is<br>
> probablistic("cross your fingers"). It may be a good one and sufficient on<br>
> most machines.<br>
<br>
</div>This has nothing to do with the definition of hard realtime. These lowlatency<br>
kernels don't even claim to be *hard* realtime. I think you'd get "lowlatency"<br>
or possibly "firm realtime", depending on who you ask.<br></blockquote><div><br>I understand this. That's kind of why we were discussing hard realtime<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
True hard realtime systems don't really exist, but if we accept hardware<br>
failure and application bugs as acceptable reasons for failure, we can get<br>
pretty close. For Linux, you'd go with RTAI or RT-Linux.<br>
<br>
However, although running all realtime audio code under RTAI or RT-Linux might<br>
offer a slightly lower risk of drop-outs, those are pretty harsh environments,<br>
even compared to the "strict" requirements of JACK clients, realtime safe<br>
LADSPA or LV2 plugins and the like. You basically cannot use ANY syscalls, but<br>
have to work with a completely different API. (RTAI/LXRT does allow hard<br>
realtime code to run in userspace, but when a thread is actually running in<br>
hard realtime context, it will be thrown back to "standard" mode as soon as it<br>
makes an ordinary syscall.)<br>
<br>
More seriously, you cannot make use of ANY normal Linux drivers. Drivers have<br>
to be ported, so that all code involved in the hard realtime "loop" actually<br>
runs under the realtime kernel, and not Linux.<br>
<br></blockquote><div>I didn't know this but I'm not surprised by it either.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Even more seriously, there is just no way that any realtime kernel can ensure<br>
anything on bad hardware. If BIOS super-NMIs are blocking normal IRQs every<br>
now and then, or you have some device + driver combo that abuses PCI bus<br>
blocking (common issue with 3D accelerators), you may get worst case latencies<br>
of any number of milliseconds - and there is nothing at all that any OS can do<br>
about this. You *may* be able to avoid these issues by replacing cards,<br>
patching or reconfiguring drivers or tweaking the BIOS settings, but as<br>
general purpose PC/workstation hardware isn't really designed for this sort of<br>
work, there are no guarantees. It basically comes down to trying hardware<br>
until you find something that does the job.<br></blockquote><div><br>Ok, that's the answer I've been looking for.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
BTW, this has very little to do with raw performance. A faster CPU does let<br>
you finish the job quicker, but if you wake up too late, you still won't be<br>
able to make the deadline...<br>
<br>
The bottom line is that, in the context of mainstream hardware and systems<br>
that aren't specifically put together for lowlatency audio work, this is a<br>
matter of diminishing returns. Indeed, it's possible to do better than a<br>
lowlatency kernel, but it's a lot of work, and it's completely wasted without<br>
perfectly configured, well behaved hardware. Sure, RTAI or RT-Linux would<br>
support 0.1 ms audio latency on a purpose built system with ported drivers,<br>
properly configured BIOS, SMI hacks etc, but it just won't happen on your<br>
average PC.<br>
<div class="im"><br>
<br>
> > Now, in real life, the "every time" part will never be quite accurate.<br>
> > After<br>
> > all, you may see some "once in a billion" combination of hardware events<br>
> > that<br>
> > delays your IRQ a few microseconds too many, or your lose power, or the<br>
> > hardware breaks down, or a software bug strikes... There are countless<br>
> > things<br>
> > that can go wrong in any non-trivial system.<br>
> ><br>
> Even in HRT systems, things go wrong. But in an HRT system, you lash the<br>
> squirrels nuts down. In a soft realtime system, you bet that there won't be<br>
> a storm.<br>
<br>
</div>Well, yes - but going beyond lowlatency kernels, it's usually the hardware you<br>
need to deal with; not the OS...<br>
<div class="im"><br></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
> > Of course, there's a big difference between a DAW that drops out a few<br>
> > times a<br>
> > day, and one that runs rock solid for weeks - but a truly glitch-free<br>
> > system<br>
> > would probably be ridiculously expensive, if it's even possible to build.<br>
> > Triple redundancy hardware, code verified by NASA, various other things<br>
> > I've<br>
> > never even thought of; that sort of stuff...<br>
> ><br>
> Who wants a DAW. I'd be happy a while with a stable minimoog emulator.<br>
<br>
</div>Same difference. If you have sufficiently solid scheduling for the realtime<br>
processing part, you can build pretty much anything around that.<br>
<br>
<br>
[...]<br>
<div class="im">> Well there are affordable synths(mostly wavetable ones) that don't appear<br>
> any more sophisticated hardware-wise than a PC.<br>
<br>
</div>It's not about sophistication. A low cost singleboard computer with an AMD<br>
Geode, VIA C7, some Intel Celeron or whatever you need in terms of raw power,<br>
will do just fine - as long as the chipset, BIOS and connected devices are<br>
well behaved and properly configured.<br>
<br>
If you, as a manufacturer of synths or similar devices, don't want to try a<br>
bunch of different motherboards for every new revision you make, you might<br>
decide to design your own board instead. Then again, if your product is low<br>
volume and requires enormous CPU power, carefully selected mainstream hardware<br>
may still be a better option.<br>
<div class="im"><br>
<br>
> The PC may be such a<br>
> "generalized" piece of hardware as to make it impractical as a dedicated<br>
> synth(unless it's of a "super" computer variety). I haven't heard anything<br>
> yet that quite "put the nail in the coffin" yet. The SMI issue mentioned<br>
> earlier might be such an issue.<br>
<br>
</div>SMI is one of them. In my experience, nearly every motherboard at least has<br>
some BIOS features you must stay away from, so even "know good" hardware<br>
sometimes need special tuning for this sort of work. General purpose computers<br>
just aren't built for low latency realtime work - but most of them can still<br>
do it pretty well, with some tweaking.<br>
<br>
<br>
[...]<br>
> > ... process a bunch of samples at a time, usually<br>
<div class="im">> > somewhere around one millisecond's worth of audio.<br>
</div>[...]<br>
<div class="im">> Well I understand it from that perspective, but for a performance<br>
> instrument I would think no buffering would be the ideal.<br>
<br>
</div>That's just pointless, as the ADC and DAC latencies are already several sample<br>
periods, and the way DMA works on any PCI, USB or 1394 soundcard will add<br>
somewhere around 64 bytes' worth of latency or more to that.<br>
<br>
Also note that your average MIDI synth has anywhere from a few through several<br>
tens of milliseconds of latency! You can only send around 1000 messages per<br>
second over a standard MIDI wire anyway, so where would you get the timing<br>
information to make use of less than 1 ms latency? Actually, going below a few<br>
ms only guarantees that the notes in a chord can never be triggered<br>
simultaneously.<br>
<br></blockquote><div>Yes I understand that from a practical standpoint some buffering is necessary and acceptable. But for a performance instrument buffering introduces latency. I have gotten the impression from past reading/discussions that buffering is a preferred as opposed to a practical condition to some. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
[...]<br>
<div class="im">> Well my question is if you took something like a Bristol synth, and<br>
> operated multiple control streams(pitch bend, filter sweeps, etc) if you<br>
> would experience latency(ie you turn the knob and the pitch bends 1/2 hour<br>
> later)<br>
<br>
</div>For knobs and similar "analog" controls, I'd say it takes at least tens of ms<br>
before you start to notice any latency. For keys, I personally think it starts<br>
to feel weird if the latency approaches 10 ms.<br>
<br>
More importantly though, latency must be *constant*! A synth that just grabs<br>
all pending events once per buffer cycle won't be playable with more than a<br>
few ms of latency, as the "random" response times quickly become very<br>
noticeable and annoying as the "average" latency increases. If incoming events<br>
are properly timestamped and scheduled, this is much less of an issue, and<br>
latency has the same effect as varying the distance to the monitor speakers.<br>
<font color="#888888"><br></font></blockquote><div>I'll take your word on this in general. Part of issue with "latency" is that is thrown around in the Linux audio community like the holy grail without much consideration as to its context. Some speak of it in terms of delays in response(ie outputting a sample or frame) in the context disk accesses, interrupts etc and that's fair but not complete.<br>
<br>Latency also includes the delays in response resulting from calculating the sample output. As a synthesis system gets more sophisticated I could see this becoming as much or more of an issue than the other type of latency. I vaguely recall installing the Molnar patches on a kernel years ago and running some "latency" test(Ben Sommer??) Anyway I think it did various naughty things while playing a single tone. I think it would be fairer test to exercise a midi synth with full out midi stream(pitch bends, notes, chords, patch changes etc) and see the results in that case. <br>
-------------------------------------------------------------------------------------------------------------------------------------<br>As a coda<br><br>I'm gonna let this go cause we're(we in this maillist suarez) are bordering on repeating ourselves louder. I'll state my conclusions/interpretations to this point.<br>
<br>1. Part of the reason I originally posted was to get a sense of the issues in embarking on implementing a synth on my Dell on one of the available hard realtime systems currently available. Some have contributed useful info that I was not aware of and I am glad to know. I have heard some of the issues involved. I don't think anyone has said it can't be done just that it may be harder, more complicated than expected. It's software....it's always harder than you expect.<br>
<br>2. The other issue--hard realtime vs the RT patches.<br><br>First of all since I've mentioned Bristol and ZynAddSub I want to say I did not mean to make them the center of my wrath. I have used Zyn on a desktop and have heard it make quite neat sounds. Bristol I had hopes for but I've never had much success with it. Maybe in the future.<br>
<br>The other side of that coin is that I don't blame their failure to work on the RT patch system. They came with the Ubuntu Studio system. I installed all this stuff with the Ubuntu/Debian packaging system. I ran them under the RT patch system and the whole system locked up. Whether that's the RT system or a failure of these systems to by "RT safe"(please issue a bullet list as to WTF that means)<br>
<br>When I started out in this discussion, I didn't assume hard realtime would be an easy answer and I realized that hardware quirks could be an issue and so on. I still don't like the answer from the other side which equates with "Get a faster system and fiddle/tune it and it'll be ok". At least add in the provisio, "After you get it working never upgrade cause someone's liable to slip in a new stack of bricks in your Ferrari"<br>
<br>Finally<br>--from gabriel's message<br><br>Why hasn't it happened, yet? Because most folks don't want this from Linux. And those that /do/ realize that it is<br>
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).<br>-------------------------------------------------------------------------------------------------------------<br>"KewlSynthOS" ?? No shit. What do you call all these audio distributions floating around that basically claim "Plug us in and you'll have an instant studio", "Look at our low latency" Blah Blah Blah. How many years has Linux been out? And how many years has ALSA and OSS been coupled with it? Since we're into "latency", I dare say I'd get less latency if I plugged in a 1Mhz Commodore 64(with 64Kb) and played the SID chip than the latency I've gotten from trying to get Linux to give me soft synth on a machine with 200Mhz processor and 200+MB of memory. When this started this a dedicated bootup synth what I suggested because quite frankly think its a bit much to insure a machine will run reliably as a synth and do spreadsheets at the same time. AND I think a lot people would gladly make the tradeoff to have an inexpensive reliable instrument especially if they could resurrect an older machine for such purposes.<br>
<br>From where I stand, it looks like a LOT of effort has been expended on Linux audio systems. It seems to me(forgetting my mission to acheive synth nirvana on the Dell for the moment) that it would have been worthwhile to build the audio on a hard realtime system since <br>
<br>1. Correct behavior is dependent upon time deadlines<br>2. That's what hard realtime systems are specifically geared to do. <br><br>Anyway, enough.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888">
<br>
--<br>
</font><div><div></div><div class="h5">//David Olofson - Developer, Artist, Open Source Advocate<br>
<br>
.--- Games, examples, libraries, scripting, sound, music, graphics ---.<br>
| <a href="http://olofson.net" target="_blank">http://olofson.net</a> <a href="http://kobodeluxe.com" target="_blank">http://kobodeluxe.com</a> <a href="http://audiality.org" target="_blank">http://audiality.org</a> |<br>
| <a href="http://eel.olofson.net" target="_blank">http://eel.olofson.net</a> <a href="http://zeespace.net" target="_blank">http://zeespace.net</a> <a href="http://reologica.se" target="_blank">http://reologica.se</a> |<br>
'---------------------------------------------------------------------'<br>
_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
</div></div></blockquote></div><br>