Prioriteiten stellen met rtirq

In een vorig blogje had ik al aangegeven dat ik tegen wat problemen aanliep na het aansluiten van mijn Firewire kaart op mijn notebook met Karmic. Na alles goed ingesteld te hebben wilde de kaart wel opstarten met de FFADO drivers maar hield JACK er al snel mee op na de volgende foutmelding uitgespuugd te hebben:

firewire ERR: wait status < 0! (= -1)
DRIVER NT: could not run driver cycle

Zal wel aan mijn onboard Firewire chipset liggen dacht ik, maar ik kon me herinneren dat het wel gewerkt had. En dat kan ik dan niet hebben, waarom zou het met Karmic niet werken en met een oudere versie wel? Dan moet ik weten waar dat aan ligt en ga ik net zo lang zoeken totdat ik dat uitgevogeld heb.

Kort daarvoor had ik een draadje gelezen op het Ubuntu Multimedia Production forum over het rtirq pakketje. Met rtirq kun je in combinatie met de realtime kernel bepaalde zogenaamde ‘tasklets’ prioriteren. Een computer werkt met IRQ’s (interrupt requests) en de IRQ’s worden in Linux geregeld door de interrupt handlers. Hier is een mechanisme voor geschreven (een API) waarmee je met deze interrupt handlers kunt praten. Dit mechanisme heet de tasklet API en de koeriertjes heten dus tasklets. Via de tasklets kun je invloed uitoefenen op de interrupt handlers en dat is precies wat het rtirq pakketje doet.

Wil je met rtirq kunnen werken dan moet je eerst weten welke apparaten welke IRQ’s gebruiken. Met het commando cat /proc/interrupts kun je deze gegevens uitlezen. Op mijn notebook zag ik al meteen wat de oorzaak van mijn foutmelding was: de Firewire chipset deelde zijn IRQ met die van de WiFi chipset. Daarom werkte het in 8.04 wel, toen gebruikte ik nog geen draadloos internet. Na een ifdown eth0 werkte de Firewire kaart dan ook naar behoren. Maar nu ik toch al bezig was met het uitzoeken hoe rtirq te gebruiken ben ik er verder ingedoken om te kijken of ik mijn Karmic installatie op mijn notebook nog verder kon optimaliseren.

Volgens het al eerder aangehaalde forumdraadje moet je na installatie van rtirq een verbeterde versie downloaden van de site van Rui Nuno Capela (de auteur van o.a. QjackCtl en Qtractor) en deze kopiëren naar /etc/init.d/rtirq:

cd ~/Desktop
wget -c http://www.rncbc.org/jack/rtirq-20090920.tar.gz
tar zxvf rtirq-20090920.tar.gz
cd rtirq-20090920
sudo cp rtirq.sh /etc/init.d/rtirq
 

/etc/init.d/ is de directory die je opstartscripts bevatten die gedraaid worden als Ubuntu wordt opgestart, rtirq is dan ook een opstartscript die bepaalde tasklets die belangrijk zijn voor audio productie kan prioriteren. Nu het goeie script is geïnstalleerd kun je de prioritering aanpassen in het bestand /etc/default/rtirq:

sudo gedit /etc/default/rtirq

De regels die aangepast moeten worden zijn de regels die beginnen met RTIRQ_NAME_LIST en RTIRQ_NON_THREADED. Bij mij zien die er nu zo uit:

RTIRQ_NAME_LIST="rtc ohci1394 snd usb i8042"
RTIRQ_NON_THREADED="rtc ohci1394 snd"

Sla het bestand op en sluit gedit af. Na een herstart met de realtime kernel zal dit script uitgevoerd worden en de tasklet die hoort bij de ohci1394 kernelmodule (de algemene Linux Firewire driver) keurig prioriteren zodat deze een stuk stabieler zal draaien omdat de module minder gezeur aan zijn kop krijgt, een soort van top-down management als het ware zeg maar eigenlijk in feite. Je kunt het script ook meteen draaien, vermits je de realtime kernel draait:

sudo /etc/init.d/rtirq start

Kun je ook gelijk zien of je geen foutjes hebt gemaakt, als alles ok is zul je een aantal regels voorbij zien komen die beginnen met “Setting IRQ priorities: start …” en zou je systeem nog stabieler moeten draaien. Ik heb rtirq ook op mijn netbookje geïnstalleerd en daar de onboard geluidskaart voorrang gegeven en dat werkt echt als een speer.

Meer informatie over het prioriteren vind je op de FFADO site.

Prioriteiten stellen met rtirq

Ubuntu Studio Controls

Ben nu mijn Karmic installatie op mijn notebook aan het finetunen voor audio productie en probeer de Ubuntu Studio Controls daarvoor te gebruiken. Normaal doe ik dit het liefst zelf maar ben wel benieuwd naar dit tooltje. De eerste melding voorspelt helaas niet veel goeds, Engels is niet mijn moedertaal maar ik weet wel dat privilages niet de correcte spelling is. Ik bekijk nu mijn /etc/security/limits.conf omdat er nog een bugje in Ubuntu Studio Controls zit waardoor er een regel niet correct wordt aangemaakt, die moet je zelf handmatig nog even toevoegen:

@audio - rtprio 90       # maximum realtime priority

unlimited  # maximum locked-in-memory address space (KB)

Ja, daar kan je systeem weinig mee, daar mist wel meer dan een regeltje. Dus ik pas het nu aan zodat er het volgende komt te staan:

@audio - rtprio 90       # maximum realtime priority
@audio - nice -19 # maximum nice priority (= lowest nice value, default '0')
@audio - memlock unlimited # maximum locked-in-memory address space (KB)

Dit is ook erg slordig en bovendien niet erg handig:

# do not delete static device nodes
ACTION=="remove", NAME=="", TEST=="/lib/udev/devices/%k", OPTIONS+="ignore_remove"
KERNEL=="raw1394",              GROUP="video"
ACTION=="remove", NAME=="?*", TEST=="/lib/udev/devices/$name", OPTIONS+="ignore_remove"

Die raw1394 regel is er dus gewoon ergens tussen geknald terwijl het netter zou zijn als deze regel aan de Firewire stanza van dit bestand (/lib/udev/rules.d/50-udev-default.rules) zou zijn toegevoegd. Bovendien is het handiger om deze regel toe te voegen aan een nieuw bestandje in /lib/udev/rules.d want er is dus al een update geweest die bovenstaande regel er weer uit heeft gehaald. Een andere optie is om een dergelijk bestandje aan te maken in /etc/udev/rules.d want er is altijd een kans dat met een toekomstige update er toevallig een bestandje in /lib/udev/rules.d bijkomt wat toevallig dezelfde naam heeft als jouw zelf aangemaakte bestandje. Kleine kans natuurlijk, maar het kan altijd.

Volgende bugje, als ik nu check in welke groepen ik zit ben ik dus niet in de ‘video’ groep gezet, alle andere accounts wel. Dus het account onder welke je Ubuntu Studio Controls aanroept wordt kennelijk niet toegevoegd. Maar even handmatig gedaan want anders kan ik alsnog geen Firewire apparaten gebruiken met mijn huidige account.

Nou, maar even checken of het werkt…

Hmmmmm, het werkt maar heb wel last van xruns en af en toe loopt het vast met de volgende foutmelding:

firewire ERR: wait status < 0! (= -1)
DRIVER NT: could not run driver cycle

Vervolgens floept het lampje op de Focusrite uit en wordt het apparaat uitgeschakeld:

Nov 30 22:45:01 soushi kernel: [ 1128.407152] ieee1394: Node changed: 0-01:1023 ->
0-00:1023
Nov 30 22:45:01 soushi kernel: [ 1128.407160] ieee1394: Node paused: ID:BUS[0-00:1023]
GUID[00130e01000605c2]
Nov 30 22:45:04 soushi kernel: [ 1131.423020] ieee1394: Node removed: ID:BUS[0-00:1023]
GUID[00130e01000605c2]

Dit is natuurlijk erg onhandig. Het zou aan de chipset van mijn notebook kunnen liggen (JMicron) of aan het über goedkope Firewiresnoer dat ik er nu tussen heb zitten maar onder 9.04 werkte het wel volgens mij. Nooit uitgebreid getest dus het hoeft niet specifiek aan Karmic te liggen. Nu wilde ik eigenlijk alleen Ubuntu Studio Controls even testen, ik ga mijn notebook toch niet gebruiken in combinatie met mijn Firewire kaart, dus laat het hier verder bij voor vanavond. Mijn conclusie is dat ik de boel liever zelf configureer want Ubuntu Studio Controls maakt er een beetje een potje van.

Edit: ik heb hier inmiddels melding van gemaakt op launchpad.net.

En zowel onder Jaunty als onder Karmic werkt de Focusrite niet goed, ook niet met betere kabels. Ligt dus hoogstwaarschijnlijk aan de Firewire chipset van mijn notebook (JMicron Technology Corp. IEEE 1394 Host Controller) of aan het feit dat de Firewire aansluiting op mijn notebook 4-pins is ipv. 6-pins. Alhoewel, dat hoort dus niet uit te maken.

Onder 8.04 heeft het kennelijk wel gewerkt zie ik nu net op mijn oude blogje.

Ubuntu Studio Controls