26 Jan
2010
26 Jan
'10
6:32 p.m.
Excerpts from fons's message of Tue Jan 26 21:47:31 +0100 2010:
On Tue, Jan 26, 2010 at 03:15:43PM -0500, David
McClanahan wrote:
Well, I use the same distro and kernel and easily get xruns. It all
depends on a couple of factors, among them hardware, software and settings.
One reason why such hardware is not feasible for hard realtime is SMI.
Currently there's nothing you can do about those other than hoping that
they don't happen and that they don't block for too long. Well you can
go up with your latency settings which will make it less likely that
SMIs cause xruns. There are some slides from the last Linux Plumbers
conference that explain what it basically is and talk about a possible
future solution:
linuxplumbersconf.org/2009/slides/Keith-Mannthey-SMI-plumers-2009.pdf
Other typical laptop hardware also is one reason for xruns, mainly
wireless, bluetooth or network in general, various acpi thingies, etc..
These fall in the settings category I guess, and I'm no expert on those
(yet) since I'm pretty new to laptops.
It certainly is possible to use laptops as reliable synths, Ken Restivo
uses a netbook as synth for live performances for example, but I think
SMIs alone will prevent hard realtime capabilities on any standard
hardware.
Regards,
Philipp
3. I'm a little worried about what some are
calling realtime systems. The
realtime system that is part of Ubuntu Studio and others may be more
preemptible than the normal kernel(as in kernel calls themselves can be
preempted), but that's not a hard realtime system. A hard realtime
system(simplistic I know) might entail a task whose sole job is to pump out
a sinusoidal sound sample to the D-to-A on the sound card. A hard realtime
scheduler would run that task at 44Khz no matter what. This would entail
developing code that when the machine instructions were analyzed, would run
in the time constraints(aka the 44Khz). RTLinux appears to be suitable and
RTAI might be. Perhaps others.
That's not how Linux audio works. Processing is done in
blocks of typically between 64 and 1024 samples.
The way things are now even with the
"realtime kernel" on U. Studio. , xruns
can occur because there's no hard limit on accessing resources-only
priorities. This may work fine on newer/faster machines but not on the older
ones. Some may say, "Go buy a faster machine". My answer is that won't
necessarily solve the problem which is a proliferation of "systems" on top
of systems without any assurance they'll all work together on time.
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 !