[LAT] [Fwd: [pure:dyne] a working rt-kernel -- please test]

Robin Gareus robin at gareus.org
Fri Aug 8 09:38:58 EDT 2008

Hash: SHA1

krgn wrote:
>>> I got rid of rtirq and das-watchdog entirely. after that, the machine
>> didn't
>>> lock up for at least as long as Robins session, ~45 mins, but the in the
>>> middle of some session I would have liked to keep the recording of,
>> dang..
>> sorry, but without rtirq the whole thing is useless.

I should have said: without rtirq the setup is not really usable for
professional sound-production or live-performance, but handy nonetheless.

> really? how so? 
because you can not guarantee that soundcard I/O is handled in time.
you might just as well run a lowlatency kernel without RT.

> I mean I can understand what it doesn, but I personally
> havn't seen it doing anything significant for i/o performance.

The general I/O performance may even go down; since fi. the sound-card
would be allowed to /interrupt/ network-i/o. - In >99% of cases the
system will run without RTirq as it will with RTirq.

If we reach a more stable 2.6.26-rt - we should ask the PPL on
ardour-users ; some of them do 64 or 128 audio-channels and you will
definitely experience a difference there.

> that said, I
> don't really do latencies lower than 128 samples... let me know your
> view/experiences/hints.

heh, hints are hard to come by.

most of the time I run at 64 * 3 (for recording) and 1024 or 2048 (for
mastering); mobile via USB, if I need more channels via 1394.  The
build-in HDA on this TP-X60s does only "work" at 128, 1024 and up, but
that's OT; i mostly use it only as "phone". - I use max. 10
hardware-channels, but occasionally go above 256 jack ports.

I never succeeded to get a Xrun free setup without rtIRQ - but the hdsp
multiface PCI/PCMCIA interface may be more /forgiving/ that the USB or
firewire stack.

Version: GnuPG v1.4.9 (GNU/Linux)


More information about the Linux-audio-tuning mailing list