Configurazione di sistemi audio GNU/Linux

Da linuxaudio.it.

Indice

[LinuxMusicians]

Guida alla Configurazione di GNU/Linux per Sistemi Audio Professionali.


Traduzione italiana degli utenti: N i n U, el_Felix, Glasgo, Touchstyle
Forum www.linux-audio.org


Versione originale inglese della guida “System Configuration” rilasciata sul Wiki LinuxMusicians:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration
sotto licenza Creative Commons
BY-NC-SA 2.0

Configurazione del sistema

Come ottengo un sistema audio Linux perfettamente funzionante senza impazzire?

Come si compila un sistema audio Linux real-time?

Prima di iniziare

Le modifiche di cui parleremo nelle prossime sezioni sono state testate a fondo, e un buon numero di esse è stato implementato in distribuzioni specifiche per la produzione audio come KXStudio e AVLinux. In ogni caso ciò non garantisce che queste modifiche funzioneranno per tutte le situazioni, e dovresti applicarle al tuo specifico set-up piuttosto che seguirle alla lettera. È anche consigliabile provare gli interventi passo dopo passo, e non implementarli tutti insieme: in questo modo puoi verificare se ogni modifica funziona come dovrebbe, e sarà più semplice risalire al punto in cui si è generato un comportamento inaspettato.

Una buona abitudine – da seguire sempre nel campo dell'informatica – è effettuare dei backup dei file che si stanno per modificare, come per esempio il file /etc/fstab: prima di aggiungere il parametro di montaggio noatime potresti voler fare una copia di sicurezza del tuo file fstab attualmente funzionante:

sudo cp /etc/fstab /etc/fstab.orig

In questo modo puoi ripristinare il file originale nel caso in cui un errore di digitazione, per esempio, ha reso il sistema non più avviabile. La procedura da seguire per recuperare un sistema che non si avvia più è oltre lo scopo di questa Wiki ma ci sono moltissime risorse a riguardo in rete e non solo.

QuickScan

Lo script realTimeConfigQuickScan analizza automaticamente la tua configurazione corrente, proponendo una serie di modifiche e linkando alle sezioni relative su queste pagine per le informazioni di background.

Per ottenere lo script devi prima di tutto installare Git e poi scaricarlo:

git clone git://github.com/raboof/realtimeconfigquickscan.git
cd realtimeconfigquickscan
perl ./realTimeConfigQuickScan.pl

Puoi parlare di questo script nel LinuxMusicians Forum

Il kernel

Note sui kernel

  • I Kernel successivi al 2.6.31 sembrano funzionare abbastanza bene anche senza la patch RT, anche per usi professionali in real-time. Non è più strettamente necessario installare kernel real-time ('rt') per ottenere buoni risultati, nonostante i migliori risultati si otterranno sicuramente usando kernel real-time. Provalo, testalo e decidi tu stesso.
  • Nel periodo dei kernel precedenti alla versione 2.6.39 la patch rt era invece necessaria in quei casi in cui i dispositivi audio condividevano le linee di interrput con altre periferiche. Con il kernel rt e lo script rtirq era possibile assegnare le priorità alle linee di interrupt, ma dalla versione 2.6.39 è possibile usare lo script rtirq con un kernel generico e l'opzione threadirqs.
  • I kernel di molte distribuzioni, e molti kernel real-time di terze parti, sono configurati senza l'impostazione a 1000 Hz. Ciò non è significativo per la registrazione, ma è un argomento di cruciale importanza per il MIDI live. Se questa è la tua applicazione principale, potresti comunque voler usare un kernel real-time, ma di sicuro avrai bisogno dei 1000 Hz.

Lo stato del tuo kernel

Il metodo più affidabile per capire quale è lo stato di un kernel in esecuzione è probabilmente:

Eseguire il comando uname -a per sapere quale kernel è attualmente in esecuzione – per esempio, su una Ubuntu 12.04, potremmo avere un output del genere:

Linux drollie 3.2.23-rt37 #1 SMP PREEMPT RT Sun Jul 29 15:39:56 CEST 2012 x86_64 x86_64 x86_64 GNU/Linux

3.2.23-rt37 è il numero di versione del kernel attualmente in esecuzione. Il file di configurazione con il quale questo kernel è stato creato può essere generalmente trovato in /boot/config-3.2.23-rt37. Aprilo, e controlla che abbia le seguenti caratteristiche:

CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT=y

“RT” sta per realtime, e la configurazione riportata si riferisce a un kernel realtime. Il “1000” fa riferimento all'impostazione relativa ai 1000 Hz.

Se non riesci a trovare il file di configurazione, o vuoi essere certo che il kernel attualmente in esecuzione sia ben configurato, prova a leggere https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Checking_the_Kernel

Lo script Quickscan va bene anche per l'impostazione dei 1000 Hz, ma sembra avere problemi sulla rilevazione del realtime al momento della stesura di questa guida (1/3/2013): http://linuxmusicians.com/viewtopic.php?f=27&t=452&sid=1aad4cd46587460e6a71aa2d10f42f8a&start=90#p24221.

Ho davvero bisogno di un kernel real-time?

Dal kernel 2.6.39, una delle componenti principali del patchset real-time, ovvero l'IRQ threading, è stata integrata direttamente nel kernel. Con l'opzione d'avvio del kernel threadirqs i kernel standard hanno già l'IRQ threading, una caratteristica che era stata riservata, prima della versione 2.6.39, ai soli kernel provvisti di patch real-time. Puoi leggere di più sull'IRQ threading qui. L'integrazione di questa caratteristica nel kernel principale di fatto elimina il bisogno di usare un kernel realtime nella maggior parte dei casi, nonostante un tale kernel possa essere ancora molto utile su una piattaforma di produzione audio Linux. Se hai bisogno della più bassa latenza possibile (per esempio per applicazioni MIDI live) un kernel real-time potrebbe ancora essere la soluzione più adatta a te, ma se il tuo interesse è principalmente la registrazione, un kernel standard o uno ottimizzato (come quello low-latency messo a disposizione da Ubuntu) probabilmente sarà sufficiente.

Usare l'opzione del kernel threadirqs

Questa operazione è necessaria solo per i kernel cosiddetti “generici”, ovvero kernel standard che non sono stati modificati per lavorare a bassa latenza. Puoi controllare se il tuo kernel include già quest'opzione con il comando seguente:

$ grep -e CONFIG_IRQ_FORCED_THREADING=y -e CONFIG_PREEMPT=y /boot/config-`uname -r`

Se ti viene restituito CONFIG_IRQ_FORCED_THREADING=y e CONFIG_PREEMPT=y allora il tuo kernel sta usando l'IRQ threading e non hai bisogno di proseguire con i passi successivi. Se invece ti viene restituito soltanto CONFIG_IRQ_FORCED_THREADING=y puoi aggiungere l'opzione d'avvio threadirqs nel modo descritto più avanti. Se il comando non restituisce niente hai un kernel che non può usare l'IRQ threading.

Apri con i privilegi di amministratore /etc/default/grub con il tuo editor di testi preferito (per esempio con il seguente comando, per usare l'editor vim):

sudo vim /etc/default/grub

Cerca la riga che inizia con GRUB_CMDLINE_LINUX_DEFAULT e aggiungi threadirqs alla lista delle opzioni:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs"

Salva il file con :x (se stai usando vim) e aggiorna la configurazione di GRUB:

sudo update-grub

Ora riavvia il sistema e dovresti avere l'IRQ threading abilitato.

Installare un kernel real-time

Questa sezione descrive come installare un kernel real-time su una distribuzione Linux preesistente. Alcune distribuzioni contengono dei pacchetti che puoi installare per avere un kernel real-time, per le altre dovrai compilarlo tu stesso. Puoi riconoscere le versioni real-time di un kernel dal suffisso '-rt' o '-realtime' posto nel numero di versione del kernel.

Ubuntu

Ubuntu Studio 12.04 comprende un kernel non real-time abilitato all'impostazione dei 1000 Hz. C'è un PPA con un kernel real-time, ma al momento della stesura di questa guida (1/3/2013) non è ancora abilitato ai 1000 Hz. È stata testata una compilazione di un kernel 3.6.11 che però non si è avviato correttamente, mentre una simile compilazione dell'ultimo kernel 3.2 con le ultime patch real-time appropriate, funziona molto bene.

Debian

A partire da Debian Wheezy una variante real-time è disponibile nei repository. Ci sono altri kernel real-time disponibili su Pengutronix e 64 Studio. I kernel real-time di 64 Studio sono nei repository backport, perciò per Debian Squeeze devi aggiungere la seguente riga alla lista delle tue sorgenti apt:

deb http://apt.64studio.com/backports squeeze-backports main
Arch

Arch ha disponibile un kernel 3.0-rt in AUR: https://aur.archlinux.org/packages.php?ID=51360

Linux frummie 3.0-rt #1 SMP PREEMPT RT Sun Nov 27 16:12:17 CET 2011 x86_64 AMD Athlon(tm) Processor L110 AuthenticAMD GNU/Linux

Il patchset per il ramo kernel 3.0 è piuttosto stabile dunque un kernel 3.0-rt dovrebbe essere utilizzabile in un sistema audio basato su Linux.

Compilare il tuo real-time kernel

Se la tua distribuzione non ti fornisce un kernel real-time nei repository, puoi compilarne e installarne uno tu stesso. Per sistemi basati su Debian puoi usare la procedura descritta qui1).

Prima di tutto installa i pacchetti necessari:

sudo apt-get install kernel-package fakeroot build-essential libncurses5-dev

Scarica i sorgenti del kernel e il patchset RT:

mkdir -p ~/tmp/linux-rt
cd ~/tmp/linux-rt
wget -c http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.35.tar.bz2
wget -c http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.35-rt52.patch.bz2

Estrai i sorgenti del kernel e modificali con il patchset RT:

tar xjvf linux-3.2.35.tar.bz2
cd linux-3.2.35
patch -p1 < <(bunzip2 -c ../patch-3.2.35-rt52.patch.bz2)

Ora devi configurare il kernel. Il modo più semplice è usare un file config per un kernel già esistente. Questi file sono presente nella cartella /boot/ del tuo sistema. Puoi copiare il file config relativo alla versione che ritieni più opportuna, e usare questo come punto di partenza:

cp /boot/config-$(uname -r) .config

Questo comando copierà il file config del kernel attualmente in uso. Una buona idea è quella di usare il config di un kernel funzionante ma già ottimizzato per l'audio, come il kernel -lowlatency fornito da Ubuntu. Il prossimo passo consiste nel creare una nuova configurazione, partendo da quella copiata, ma abilitando la piena preemption:

make oldconfig

Ora avrai una serie di richieste alle quali puoi rispondere tranquillamente con il default suggerito, tranne per quanto riguarda la richiesta riguardante quale Preemption Model vuoi usare. Seleziona l'opzione 5 (Fully Preemptible Kernel):

Preemption Model
> 1. No Forced Preemption (Server) (PREEMPT_NONE)
  2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)
  3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT__LL) (NEW)
  4. Preemptible Kernel (Basic RT) (PREEMPT_RTB) (NEW)
  5. Fully Preemptible Kernel (RT) (PREEMPT_RT_FULL) (NEW)
choice[1-5]: 5 <Enter>


Ora compila effettivamente il kernel:

make-kpkg clean
CONCURRENCY_LEVEL=$(getconf _NPROCESSORS_ONLN) LOCALVERSION= fakeroot make-kpkg --initrd --revision 0 kernel_image kernel_headers

Quando la compilazione è completa e i pacchetti sono stati creati, puoi installarli:

cd ..
sudo dpkg -i linux-{headers,image}-3.2.35-rt52_0_*.deb

Ora riavvia e seleziona il tuo nuovo kernel RT nel menu del tuo bootloader.

Puoi fare riferimento anche a questi link:

Disabilitare servizi e processi che consumano risorse

Dovresti controllare se i seguenti demoni, servizi e processi sono in esecuzione e, in tal caso, valuta la possibilità di stopparli e/o ricorrere ad altre alternative:

  • powersaved
  • kpowersave
  • upowersave ?
  • I demoni che impostano lo scaling della frequenza della CPU dipendentemente dal suo carico possono causare xrun in alcuni casi. Le versioni più recenti di Jack1 (>= 0.118.0) soffrono meno di tali problematiche (come in casi in cui il demone del CPU scaling è impostato su ondemand). È in lavorazione un demone di CPU scaling specializzato per l'audio che dipende dal carico DSP invece che da quello della CPU:jackfreqd
  • Debian/Ubuntu: un'installazione di base installerà anche il pacchetto apt-xapian-index, il quale abilita l'opzione Quick Search nel governatore di pacchetti Synaptic. Tale funzionalità esegue continui aggiornamenti del suo database grazie a un cronjob. Soprattutto su sistemi meno performanti questo cronjob potrebbe causare vari xrun. Considera la possibilità di disinstallare questo pacchetto.
  • Ambienti Desktop (DE): soprattutto su sistemi meno performanti è preferibile usare un ambiente desktop (o DE, Desktop Environment) più leggero di Gnome, KDE o Unity. Possibili alternative sono LXDE, XFCE o IceWM. Un'altra possibilità è utilizzare unicamente un Window Manager (WM) più leggero come Openbox o Fluxbox.
  • Compositing: raccomandazione simile a quella sui DE. Evita l'utilizzo di gestori di compositing come Compiz per abbassare la possibilità di incappare in xrun.
  • Gnome NetworkManager e WiFi: NetworkManager rimane costantemente in esecuzione in background alla ricerca di nuove reti wireless, e potrebbe causare xrun. L'opzione migliore è di evitare l'uso di un governatore di reti wireless in un ambiente di produzione audio real-time a bassa latenza. Se hai la necessità di usare il WiFi, non hai altra possibilità se non quella di usare l'applicazione wpa_supplicant.
  • NTP: ci sono indicazioni sull'interferenza tra l'NTP e FFADO, se perciò usi una scheda audio Firewire assicurati di aver disabilitato il servizio ntpd e ogni cronjob o script ifup che prova a sincronizzare l'orologio del sistema con un server NTP. In ogni caso questo problema è stato risolto dalla versione 2.1.0 dei driver FFADO.

CPU Frequency Scaling

Se la tua CPU supporta la variazione della frequenza e il governor (governatore) è impostato su ondemand (settato così di default nella stragrande maggioranza delle distribuzioni) potresti incorrere in problemi di xrun. Il governor ondemand varia la frequenza in accordo al carico della CPU, più vi è carico, più alta è la frequenza.

Questo accade indipendentemente dal carico di DSP nel tuo sistema, così potrebbe succedere che il carico di DSP aumenti improvvisamente per esempio, chiedendo alla cpu più potenza, e che il demone della variazione intervenga in ritardo, manifestando xrun perché il carico di DSP arriva al limite.

Una soluzione potrebbe essere usare un demone di variazione della CPU in accordo al carico di DSP come Jackfreqd o disabilitare completamente la variazione della frequenza di CPU.

Quest'ultimo metodo si può ottenere impostando il governor su performance.


Per controllare che tipo di governor è attivo:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Impostare il governor su performance:

echo -n performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Ora potresti aggiungere una riga al tuo file /etc/rc.local per impostare il governor su performance all'avvio.

echo -n performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Ubuntu

Su Ubuntu il comando impostato nel file /etc/rc.local funziona solo se disabiliti il servizio ondemand.

sudo update-rc.d ondemand disable

Un'altra opzione sarebbe modificare lo script init ondemand rinominandolo in performance:

 sudo sed -i 's/ondemand/performance/g' /etc/init.d/ondemand
 sudo update-rc.d ondemand disable
 sudo cp /etc/init.d/ondemand /etc/init.d/performance
 sudo update-rc.d performance enable


Debian

Su Debian puoi controllare il governor della variazione grazie all'utility cpufreq-set che fa parte del pacchetto cpufrequtils:

sudo cpufreq-set -r -g performance

In fase di installazione il pacchetto installa inoltre uno script init in /etc/init.d/cpufrequtils e un file di configurazione in/etc/default/cpufrequtils. Per fare in modo che il governor sia sempre settato su performance assicurati che il file di configurazione abbia impostato quanto segue:

ENABLE="true"
GOVERNOR="performance"
MAX_SPEED="0"
MIN_SPEED="0" 

BIOS

La maggior parte dei BIOS disabilita completamente la variazione di frequenza della CPU, il risultato è che lavorerà al suo massimo valore di clock. Per quanto riguarda le CPU intel dovresti cercare l'opzione SpeedStep. Le equivalenti per AMD sono Cool'n'Quiet o PowerNow!.

Se vuoi evitare che la tua CPU si surriscaldi o prevenire arresti, oppure se preferisci che il tuo PC consumi meno energia, allora potresti cambiare alcune impostazioni nel BIOS (ammesso che il tuo BIOS le supporti):

  • Disabilitare PCI e/o gestione dell'energia PCIe nel BIOS
  • Disabilitare EIST e C1E halt-states

Con queste impostazioni disabilitate il governor ondemand dovrebbe funzionare senza causare nessun xrun.


Disattivazione dei servizi problematici e altri dettagli nascosti

Cose da disattivare

Ci sono diverse cose che possono tornare utili se disabilitate. All'interno di ciascuna di queste tipologie potrebbero esserci degli elementi di cui avrai bisogno sulla tua macchina, perciò fai attenzione.

  • Servizi di sistema che usano gli standard SysV / rc.d / init.d.
  • Servizi di sistema che usano il nuovo standard 'upstart'.
  • Processi avviati con D-Bus.
  • Supporto a moduli Hardware.
  • Elementi avviati da un login GUI.

Servizi di sistema che usano gli standard SysV / rc.d / init.d

Molte distribuzioni li usano ancora in via esclusiva. Strumenti da riga di comando per la loro disattivazione sono update-rc.d e chkconfig. Nella maggior parte delle distribuzioni che li utilizzano, è necessario capire il concetto di "runlevel": un runlevel è un livello in cui il sistema può essere eseguito, e ogni runlevel ha una propria serie di servizi. Il vecchio standard prevedeva la separazione dei runlevel in single-user mode per il debugging, modalità solo testo, X, ecc. Ci sono molte differenze oggi, specifiche per ogni distro.

Servizi di sistema che usano il nuovo standard 'upstart'

Upstart è piuttosto nuovo, veloce, ed elogiato da gran parte della comunità di sviluppatori Linux. Ubuntu 12.04 utilizza una combinazione di SysV e upstart, e la sua comunità è in fase di migrazione verso l'utilizzo del solo upstart. Per disabilitare i servizi controllati da upstart, vai nella cartella /etc/init (non /etc/init.d, che è usata da SysV), individua il nome del file di configurazione corrispondente alla voce che desideri disattivare (ad esempio, bluetooth.conf), crea un file con estensione corrispondente .override (in questo caso, bluetooth.override). Il file .override deve contenere solo una riga con la voce "manual". Riavviare per implementare la modifica.

Processi avviati con D-Bus

DBus è uno standard consolidato, utilizzato per una vasta gamma di servizi che devono essere avviati automaticamente, ma solo su richiesta e in background, non specificamente all'avvio. Una serie di servizi DBus ampiamente utilizzati in Ubuntu è 'gvfs', il filesystem virtuale per il desktop Gnome, se a questi è consentita l'esecuzione, il polling dell'hardware che include il bus USB si verifica, e potrebbe interferire facilmente con le interfacce USB MIDI, consumare CPU e causare xrun in generale. Per disattivare gvfs, vai come utente root in /root/usr/share/dbus-1/services, rinomina gvfs-daemon.service in gvfs-daemon.service.disabled, e gvfs-metadata.service in gvfs-metadata.service.disabled.

Supporto a moduli Hardware

Questi sono i moduli del kernel Linux che supportano vari tipi di hardware. I moduli impiegano risorse. Se, ad esempio, si dispone di una porta audio HDMI che non è necessaria, è possibile includere un comando 'rmmod' nel file /etc/rc.local per disattivarla. Tuttavia, è necessario verificare prima l'utilizzo degli IRQ (vedi capitolo relativo del presente documento), perché questo potrebbe essere un cambiamento fondamentale da effettuare, ma potresti incorrere in conflitti.

Script d'esempio per disabilitazioni necessarie

Ci sono alcuni processi e driver in esecuzione che potrebbero non essere necessari quando si fa musica. Di seguito vien riportato un esempio estremamente semplice di uno script Bash per disabilitare tutte le cose non necessarie. Si noti che comprende anche una soluzione per un conflitto IRQ, documentata più in basso.

#!/bin/sh
modprobe -r ppdev # Non ho una porta parallela
modprobe -r lp # Non uso una stampante quando faccio musica
modprobe -r uvcvideo # Non uso una webcam quando faccio musica
modprobe -r videodev # idem come sopra
modprobe -r ath9k # Wireless driver
modprobe -r r8169 # NIC driver
modprobe -r btusb # Bluetooth USB
/etc/init.d/bluetooth stop & # Arresto il Bluetooth e relativi processi
/etc/init.d/cups stop & # Arresto cups, Non uso una stampante quando faccio musica
/etc/init.d/networking stop & # Arresto il networking, internet è un fattore che può distrarre quando si fa musica
/etc/init.d/network-manager stop & # idem come sopra
killall modem-manager # Non ho un modem
killall wpa_supplicant # Vedi sempre le considerazioni sul networking come sopra
modprobe snd-hrtimer # Carico il modulo ALSA timer ad alta risoluzione per i miei strumenti MIDI
echo -n performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # Imposto il governatore della frequenza di CPU su performance
echo -n "0000:00:13.0" > /sys/bus/pci/drivers/ohci_hcd/unbind # Unbind di una porta USB, interferisce con la mia scheda audio
# La seguente sezione riguarda solo i kernel < 2.6.39. I kernel > 2.6.39 non hanno un demone tasklet.
TASKLETPR=76 # Definire variabile TASKLETPR e impostarla a 76
ps -eLo pid,cmd | grep [t]asklet | awk '{ system("chrt -f -p '$TASKLETPR' " $1)}' # Script che include i comandi grep e awk per impostare la priorità al demone tasklet

È possibile eseguire questo script una volta che hai fatto il login (ha bisogno dei privilegi di root però), eseguilo da /etc/rc.local o anche come script init. Un suggerimento sarebbe quello di metterlo in esecuzione solo quando un kernel real-time viene caricato, ad esempio:

if [ $(uname -r | cut -d "-" -f 3) = "realtime" ]
then /percorso/allo/script/indicato/sopra/
fi

I moduli e i processi naturalmente possono differire a seconda della macchina su cui si opera, così prima determina quali moduli sono stati caricati con lsmod e poi decidi quelli di cui hai veramente bisogno. Lo stesso vale per tutti i processi in esecuzione sul computer, ps -ef o anche pstree -p possono essere utili quando si cerca processi non necessari.

Risolvere conflitti IRQ facendo l'unbind dei dispositivi

Lo script precedente contiene anche una riga che effettua l'unbind (disassociazione) di un dispositivo fastidioso che si trova sulla stesso IRQ della scheda audio. L'unbind di un dispositivo è sostanzialmente l'ultima risorsa da utilizzare nel caso in cui un dispositivo dovesse interferire e tutte le altre possibilità, come l'utilizzo di rtirq, non riescano a migliorare le prestazioni della scheda audio. In questo caso particolare, il thread creato per la porta USB iniziava a consumare così tanta CPU che a un certo punto gli xrun erano innumerevoli. Al fine di evitare ciò, l'unbind del driver USB dalla porta USB fisica ha funzionato.

Questa è la situazione sulla macchina interessata:

16:        923   IO-APIC-fasteoi   ohci_hcd:usb2, hda_intel

USB2 condivide IRQ 16 con la scheda audio Intel HDA. Al fine di essere in grado di effettuare l'unbind del driver USB da usb2 è necessario conoscere l'ID del bus usb2:

$ tree /sys/bus/usb/drivers/usb/
/sys/bus/usb/drivers/usb/
|-- 1-4 -> ../../../../devices/pci0000:00/0000:00:13.5/usb1/1-4
|-- bind
|-- uevent
|-- unbind
|-- usb1 -> ../../../../devices/pci0000:00/0000:00:13.5/usb1
|-- usb2 -> ../../../../devices/pci0000:00/0000:00:13.0/usb2
|-- usb3 -> ../../../../devices/pci0000:00/0000:00:13.1/usb3
|-- usb4 -> ../../../../devices/pci0000:00/0000:00:13.3/usb4
`-- usb5 -> ../../../../devices/pci0000:00/0000:00:13.4/usb5
6 directories, 3 files

Così l'ID di USB2 è 0000:00:13.0. Se lo scrivi nel file unbind contenuto nella directory /sys/bus/pci/drivers/ohci_hcd/, dovresti riuscire a tenerlo disassociato dal driver USB:

# echo -n "0000:00:13.0" > /sys/bus/pci/drivers/ohci_hcd/unbind

Trovare il file unbind giusto potrebbe comportare diversi tentativi e si potrebbe incappare in errori ma /sys/bus/pci/drivers/ohci_hcd/ contiene il file unbind giusto per l'hub USB1.1 principale, come usb2. Ora siamo in grado di verificare con il comando tree (o con lsusb) lo stato attuale, che è il seguente:

$ tree /sys/bus/usb/drivers/usb/
/sys/bus/usb/drivers/usb/
|-- 1-4 -> ../../../../devices/pci0000:00/0000:00:13.5/usb1/1-4
|-- bind
|-- uevent
|-- unbind
|-- usb1 -> ../../../../devices/pci0000:00/0000:00:13.5/usb1
|-- usb3 -> ../../../../devices/pci0000:00/0000:00:13.1/usb3
|-- usb4 -> ../../../../devices/pci0000:00/0000:00:13.3/usb4
`-- usb5 -> ../../../../devices/pci0000:00/0000:00:13.4/usb5
5 directories, 3 files

Come si può vedere, usb2 non è più presente, neanche usando lsusb:

$ lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 04f2:b175 Chicony Electronics Co., Ltd 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Usb2 che corrispondeva al bus 002, proprio quello che sembra essere scomparso, ultima verifica:

$ cat /proc/interrupts | grep 16
 16:        924   IO-APIC-fasteoi   hda_intel

Molto bene, la scheda audio si trova ora da sola su IRQ 16 e lavora in maniera più stabile rispetto a prima, quando ancora condivideva un IRQ con la porta USB. Lo svantaggio principale di questo metodo, naturalmente, è che si perde una porta USB.

Altre informazioni: http://lwn.net/Articles/143397/

Filesystems

Per l'uso audio, è opportuno usare un filesystem che favorisca pochi file di grandi dimensioni piuttosto che numerosi file di piccole dimensioni. Si è detto che ReiserFS e fuseblk sono scelte sbagliate da questo punto di vista, mentre ext3 e ext4 sono buoni. Ext4 ha avuto alcuni problemi di prestazioni in passato, ma che non erano direttamente collegati al trattamento audio e, nel frattempo, la maggior parte dei problemi sono stati comunque risolti.

In ogni caso, si consiglia di montare i filesystem con l'opzione noatime abilitata. Questo passaggio è verificato da QuickScan, ma si potrebbero usare più informazioni circa quali filesystem sono adatti.

Crittografia

Essa non pregiudica la qualità dell'audio, ma cambierà il numero di tracce che il disco è in grado di supportare e siccome la crittografia necessita CPU, questo influenza quanta elaborazione del segnale puoi fare. Quanto appena detto è un modo prolisso per dire "non farlo”.

Tmpfs

Sia Jack1 che Jack2 adesso usano /dev/shm/, così montare tmpfs in/tmp non è più necessario.

Noatime

L'impostazione del parametro noatime nel proprio file /etc/fstab riduce la quantità di I/O su disco (i tempi di accesso agli inode non vengono aggiornati ogni volta che viene letto un file) ed è in grado di migliorare le prestazioni generali del sistema.

/dev/sdax / ext4 noatime,errors=remount-ro 0 1

La maggior parte delle distribuzioni moderne utilizzano atime o relatime. Vedere la pagina di manuale di mount per ulteriori informazioni su questi parametri.

limits.conf/audio.conf

È consigliabile impostare adeguatamente il tuo file /etc/security/limits.conf o /etc/security/limits.d/audio.conf , ad esempio:

 @audio - rtprio 90       # maximum realtime priority
 @audio - memlock unlimited  # maximum locked-in-memory address space (KB)

Settare memlock su unlimited non dovrebbe essere più strettamente necessario da quando la maggior parte delle applicazioni lavora bene anche con valori più bassi (come 500000).

Comunque, alcune applicazioni hanno manifestato problemi o addirittura crash con valori più bassi di unlimited.

D'altra parte, dando capacità illimitata di blocco memoria si potrebbe riscontrare qualche bug alle applicazioni o addirittura temporanei freeze dell'intero sistema.

Vedi http://www.linuxmusicians.com/viewtopic.php?f=10&t=2193 per maggiori dettagli.

Si potrebbe anche consentire al gruppo audio di effettuare il renice dei processi con l'aiuto del file limits.conf, ma dal momento che nice usa SCHED_OTHER che fondamentalmente non aumenta le prestazioni di un ambiente audio a bassa latenza o real-time che si basa su SCHED_FIFO / SCHED_RR. Consultare la pagina di manuale di sched_setscheduler per maggiori informazioni su questo argomento.

Vedi inoltre: http://linuxmusicians.com/viewtopic.php?f=27&t=392

Se non usi PAM (il che è raro), potresti aver voglia di usare invece set_rlimits.


sysctl.conf

Impostazione consigliata per /etc/sysctl.conf:

 vm.swappiness = 10

Questa impostazione cambia la cosiddetta swappiness del tuo sistema, o in altre parole, il momento quando il tuo sistema inizia ad usare la sua partizione di swap. Puoi controllare il valore corrente con cat /proc/sys/vm/swappiness,nella maggior parte dei casi è settato su 60. Tale valore è però troppo alto, dato che il tuo sistema inizierà a usare l'area di swap troppo velocemente, influenzando negativamente le prestazioni generali.

Ci sono riferimenti in rete anche sulla regolazione del valore di fs.inotify.max_user_watches per migliorare le prestazioni. Ma rimane poco chiaro da dove vengano questi riferimenti e se si regola questo valore attualmente non succede nulla.


audio group

Generalmente è buona pratica avere un gruppo 'audio', e aggiungere tutti gli utenti che dovrebbero essere autorizzati a lavorare con l'audio a questo gruppo. Questo previene la maggior parte delle interferenze tra i processi-non-audio e i compiti audio. Per verificare se sei nel gruppo 'audio', lancia il comando groups. Ricorda, dopo aver aggiunto te stesso ad un nuovo gruppo, dovrai fare il log out e rientrare. Fai attenzione quando aggiungi un gruppo 'audio' al tuo sistema: gran parte dei sistemi hanno un gruppo 'audio' pre-configurato e non avvisano quando viene aggiunto un altro gruppo con lo stesso nome, il che porta a molta confusione.

Questo passaggio è verificato da QuickScan.


Timer hardware

NOTA: Questo paragrafo sarà riscritto perché ci sono pochissime applicazioni che usano direttamente i dispositivi /dev/rtc e /dev/hpet. La gran parte delle applicazioni usano il timer ad alta risoluzione provvisto dal kernel. In pratica è diventato un po' obsoleto usare le impostazioni qui descritte.


I sequencer MIDI e simili possono beneficiare dell'utilizzo di timer hardware come il Real-time clock(/dev/rtc) o l'High Precision Event Timer (/dev/hpet). Assicurati che il gruppo 'audio' abbia i permessi di lettura su essi.

Impostando semplicemente un nuovo gruppo con chgrp la modifica non è permanente– per impostare un cambiamento definitivo, crea un nuovo file 40-timer-permissions.rules in /etc/udev/rules.d con le seguenti linee:

KERNEL==”rtc0”, GROUP=”audio”
KERNEL==”hpet”, GROUP=”audio”

E' consigliabile anche consentire agli utenti del gruppo 'audio' di usare questi timer a frequenze più alte, in quanto i valori di default sono troppo bassi:

$ cat /proc/sys/dev/hpet/max-user-freq
64
$ cat /sys/class/rtc/rtc0/max_user_freq
64

Sfortunatamente non c'è un'indicazione precisa sui valori da utilizzare. Molte fonti menzionano un valore minimo tra almeno 1024 o anche 2048 e un settaggio massimo di 8192. Potrebbe essere più saggio usare i valori menzionati nel wiki di Rosegarden, che è un'applicazione che si basa su accurate regolazioni di max user freq. L'impostazione max user freq per hpet può essere settata in /etc/sysctl.conf , mentre l'impostazione per rtc0 può essere settata con un comando echo in fase di avvio con uno script d'avvio o aggiungendo una linea a /etc/rc.local.

/etc/sysctl.conf (o qualcosa del genere /etc/sysctl.d/60-max-user-freq.conf):

dev.hpet.max-user-freq=3072

Script d'avvio o /etc/rc.local:

echo 3072 >/sys/class/rtc/rtc0/max_user_freq

Al prossimo riavvio verranno impostate queste modifiche. Per attivarle immediatamente:

 sudo sysctl -p /etc/sysctl.d/60-max-user-freq.conf
 echo -n 3072 | sudo tee /sys/class/rtc/rtc0/max_user_freq
 sudo chmod 660 /dev/hpet /dev/rtc0
 sudo chgrp audio /dev/hpet /dev/rtc0

Vedi anche: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/306458

Questo passaggio è verificato da QuickScan.

Priorità

Per rtprio valori più alti significano priorità più alta. Puoi visualizzare l'elenco dei threads e le loro priorità con uno dei seguenti comandi:

$ ps axHo user,lwp,pid,rtprio,nei,command
$ ps -eLo pid,cls,rtprio,pri,nic,cmd | grep -i irq

O, se hai lo script rtirq installato:

$ /etc/init.d/rtirq status

La maggior parte delle applicazioni hanno cura di lanciare alcuni threads con una rtprio più alta possibile, come JACK con l'opzione real-time attivata. Il watchdog di JACK ha una priorità più alta di jackd stesso (+10) in modo da scegliere un valore di ragionevole priorità per JACK (per esempio con 70 verrà assegnata prio 80 al thread watchdog di JACK), tenendo presente anche che i dispositivi audio potrebbero avere una priorità nel range 80-90 se si usa rtirq.

Puoi anche impostare rtprio e scheduling manualmente usando chrt da riga di comando, che al giorno d'oggi dovrebbe andare con la gran parte delle distribuzioni, oppure usare lo script di init di rtirq.

Vedi anche: http://subversion.ffado.org/wiki/IrqPriorities

rtirq

rtirq è uno script scritto da Rui Nuno Capela, autore, tra gli altri, di QjackCtl e Qtractor. Questo script consente di usare gli IRQ threaded usati per il Real-time kernel o dai kernel >= 2.6.39 con l'opzione threadirqs attivata. Il termine IRQ threaded è piuttosto astratto, ma quello che di fatto si ottiene è che ogni periferica riceve un IRQ ben preciso e il kernel Linux divide questo IRQ in diverse parti di cui la cosiddetta bottom-halve (la metà di sotto) rappresenta un problema nel contesto dello script rtirq. I bottom-halves sono anche conosciuti come softirqs, che potrebbero rendere questa materia un po' meno astratta, gli hardirqs (la metà di sopra) sono gli IRQ assegnati dal sistema che non possono essere gestiti all'interno del sistema operativo, al contrario dei 'softirqs', che possono essere gestiti.

Softirqs.gif

Questi bottom-halves sono gestiti attraverso i cosiddetti tasklets, che sono parte delle API tasklet. Questa funzionalità può essere verificata con il già menzionato comando ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i “irq”. Il processo chiamato sirq-tasklet (<= 2.6.38, i kernel >= 2.6.39 non hanno tale processo, semplicemente perché quella specifica parte del patchset RT è stata fusa nel kernel principale) è il vero strumento di gestione tasklet che si prende cura di assegnare delle priorità ai diversi bottom-halves, o addirittura i threads in esecuzione in questi bottom-halves (da qui il termine threaded IRQs). La distinzione tra questi tre termini (softirq, bottom-halve and tasklet) è un po' vaga ma un'esposizione più completa di questo argomento va oltre lo scopo di questo articolo. Altre informazioni si possono trovare in questo articolo (dal Wiki FFADO): http://subversion.ffado.org/wiki/IrqPriorities

I tarball rtirq sono disponibili sul sito dell'autore e consistono i due file, lo script stesso (rtirq.sh) e il file di configurazione (rtirq.conf). Nella gran parte dei casi il file rtirq.sh è usato con script di inizializzazione (e, quindi, privato dell'estenzione .sh) e rtirq.conf finisce per lo più in /etc/default/ oppure in /etc/sysconfig/, anch'esso privato della sua estensione.

Vediamo il contenuto del file di configurazione:

 #
 # Copyright (c) 2004-2011 rncbc aka Rui Nuno Capela.
 #
 #   This program is free software; you can redistribute it and/or
 #   modify it under the terms of the GNU General Public License
 #   as published by the Free Software Foundation; either version 2
 #   of the License, or (at your option) any later version.
 #
 #   This program is distributed in the hope that it will be useful,
 #   but WITHOUT ANY WARRANTY; without even the implied warranty of
 #   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 #   GNU General Public License for more details.
 #
 #   You should have received a copy of the GNU General Public License along
 #   with this program; if not, write to the Free Software Foundation, Inc.,
 #   51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 #
 # /etc/sysconfig/rtirq
 # /etc/default/rtirq
 #
 # Configuration for IRQ thread tunning,
 # for realtime-preempt enabled kernels.
 #
 # This program is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License version 2 or later.
 #  
 # IRQ thread service names
 # (lista separata da spazi, dalla priorità più alta alla più bassa).
 RTIRQ_NAME_LIST="rtc snd usb i8042"
 # Highest priority.
 RTIRQ_PRIO_HIGH=90
 # Priority decrease step.
 RTIRQ_PRIO_DECR=5
 # Whether to reset all IRQ threads to SCHED_OTHER.
 RTIRQ_RESET_ALL=0
 # On kernel configurations that support it,
 # which services should be NOT threaded 
 # (space separated list).
 RTIRQ_NON_THREADED="rtc snd"
 # Process names which will be forced to the
 # highest realtime priority range (99-91)
 # (lista separata da spazi, dalla priorità più alta alla più bassa).
 # RTIRQ_HIGH_LIST="timer"

La variabile RTIRQ_NAME_LIST contiene un elenco di nomi di servizi (separati da spazi), di cui la prima voce ha la priorità più alta. Il nome del servizio sembra riferirsi al nome del modulo e alle denominazioni del dispositivo audio (come l'output di lsmod e aplay -l rispettivamente) e non deve corrispondere all'intero output dei due comandi sopracitati, in quanto anche solo usando una parte dell'output, è lo script rtirq a verificare la corrispondenza col nome completo del servizio.

La variabile RTIRQ_PRIO_HIGH setta la priorità massima che può essere assegnata a ogni servizio

RTIRQ_PRIO_DECR imposta il numero con il quale le priorità di ogni servizio menzionato nella variabile RIRQ_NAME_LIST devono essere ridotte.

RTIRQ_RESET_ALL è una variabile posta per retro compatibilità ed è meglio lasciare il valore di default.

La variabile RITIRQ_NON_THREADED è un'altra opzione obsoleta, la configurazione del tuo kernel deve supportarla e in quasi tutti i casi non è così perché la specifica opzione, che faceva parte dell'opzione di configurazione del kernel CONFIG_PREEMPT_VOLUNTARY e che permetteva gli IRQ non-threaded, semplicemente non esiste più. Così, in pratica, questa variabile non fa niente.

La variabile RTIRQ_HIGH_LIST contiene una lista di nomi di servizi (separati da spazi) che ottengono priorità nell'intervallo 99-91, quindi al di sopra del valore settato nella variabile RTIRQ_PRIO_HIGH. Usare questa variabile solo per i servizi di cui si vuole essere sicuri al 100% che non vengano interrotti da qualcosa. Vorrai sicuramente inserire qui timer come rtc o il timer ad alta risoluzione ALSA (snd-hrtimer).

Quando usare rtirq

Un comune caso d'uso per rtirq è quando un controller FireWire condivide l'IRQ con uno o più dispositivi. Con rtirq puoi dare una priorità più alta al bottom-halve FireWire, che dovrebbe ridurre drasticamente le probabilità di incorrere in xruns o addirittura consentire al dispositivo di inizializzarsi correttamente. Il comando grep firewire /proc/interrupts genera l'IRQ in uso dal controller FireWire (quando si usa il JuJu stack corrente):

$ grep firewire /proc/interrupts

16: 88504 215 IO-APIC-fasteoi uhci_hcd:usb3, mmc0, firewire_ohci, jmb38x_ms:slot0, eth1, nvidia

Come puoi vedere l'IRQ 16 è veramente affollato in questo caso, e un dispositivo FireWire collegato a questo controller semplicemente non verrà inizializzato. Con l'aggiunta del modulo firewire_ochi alla lista dei valori (separati da spazi) della variabile RTIRQ_NAME_LIST puoi assegnare una priorità più alta al softirq o al bottom-halve del controller FireWire:

RTIRQ_NAME_LIST=”rtc firewire usb”

Se RTIRQ_PRIO_HIGH è impostata a 90 e RTIRQ_PRIO_DECR a 5 allora il real-time clock (rtc) avrà priorità 90 mentre il controller FireWire avrà 85. Tutte gli altri bottom-halves di IRQ 16 avranno di default priorità 50, cosicché il controller FireWire abbia sempre la precedenza. In questo caso specifico (un HP DV7-1040) usando rtirq in questo modo consentiamo al dispositivo FireWire (una Focusrite Saffire Pro 10 IO) di inizializzarsi correttamente e funzionare in modo stabile a basse latenze (128 frames / 48Khz samplerate * 3 periods = 8ms). E dato il fatto che il controller (un chipset JMicron integrato) si poggia su un IRQ molto affollato (condiviso da una scheda di rete, un lettore di schede, una porta USB e una GPU) risulta evidente da questo esempio la forza dello script rtirq.

Latenza del bus PCI

Le periferiche PCI convenzionali offrono un tipo di bus condiviso che offre un numero limitato di IRQ. Se questi interrupt vengono condivisi possono disturbarsi reciprocamente, a causa del ritardo di risposta di alcuni device e alla lunghezza dei pacchetti, che pu ò causare lo svuotamento del buffer negli altri device ( http://en.wikipedia.org/wiki/Conventional_PCI#PCI_bus_latency ). Il successivo PCI­X , soffre meno di questo problema di latenza perchè supporta una maggiore larghezza di banda, ma è comunque uno standard che prevede la condivisione di interrupt. Invece lo standard più recente è basato su un collegamento “punto­punto”, con collegamenti separati e seriali per ogni dispositivo all'host. (http://en.wikipedia.org/wiki/PCI_Express#Architecture).

Se voi usate una scheda audio PCI tradizionale, potreste considerare di massimizzare il timer di latenza della scheda audio, aumentando di poco quello delle altre periferiche (di default è 64). Questo può sembrare controproducente tuttavia il timer della latenza del bus PCI determina per quanto tempo un device può occupare il bus, quindi se la scheda video ha occupato il bus per un tempo relativamente lungo intasandolo, ha limitato la scheda audio l'occupazione del bus solo per brevi periodi, quindi le performace audio possono risentirne.

Questo script resetta tutti i device con un'impostazione media accettabile del timer, ed in seguito imposta la scheda audio ad occupare il bus per un periodo maggiore. (http://lists.linuxaudio.org/pipermail/linux­audio­user/2007­April/044532.html)

#!/bin/sh 
 case $1 in 
       start) 
             # "aprire" il bus PCI consentendo un aumento della performance per tutti i 
             #dispositivi
             setpci ­-v -­s "*:*.*" latency_timer=b0 
             # massimizzare la latenza per la RME Hammerfall, consentendo così
             # più dati per trasferimento sul bus PCI minimizzando gli xruns 
             setpci ­-v -­s 01:04.0 latency_timer=ff 
             # idem come sopra per la scheda audio integrata AC97 
             setpci -­v ­-s 00:07.5 latency_timer=ff 
  esac 
  exit 0


La sorgente dello script è: http://lists.linuxaudio.org/pipermail/linux­audio­user/2007­April/044371.html


Rimane la questione di fino a che punto le impostazioni del bus PCI influiscono sulle performance del bus PCI­X. PCIe invece, per la sua struttura, non soffre del problema della latenza del bus PCI. Inoltre, i dispositivi

PCIe hanno il loro timer di latenza PCI impostato a 0 ed il comando setpci non ha alcun effetto (con

l'impostazione latency_timer = ff sui dispositivi PCIe produce ancora l'impostazione 0).

Salvaschermi

Quando ci sono processi audio, i salva­schermi possono attivarsi, quindi dovreste considerare la possibilità di disinstallarli. Noterete che X tenterà comunque di oscurare lo schermo dopo un po'. Per disabilitare completamente questo comportamento è possibile aggiungere queste righe al file “.bashrc”:


 xset ­-dpms 
 xset s off 
 setterm ­-powersave off -­blank 0 


Questo dovrebbe disabilitare completamente tutte le attività sopra descritte.

PulseAudio

Fondamentalmente tutte le moderne distribuzioni prevedono PulseAudio installato. PulseAudio (PA) è un server audio (come Jack) che si occupa di mixare l'audio di tutte le applicazioni che producono suono. Essendo PulseAudio progettato per lavorare in varie situazioni e con molti tipi di hardware, non è la scelta migliore per un utilizzo audio real­time. In altre parole PulseAudio è più indicato per le configurazioni standard, mentre JACK è indicato per le configurazioni professionali. Ci sono distribuzioni che offrono script o configurazioni per consentire l'utilizzo di entrambi i server audio contemporaneamente. E' giusto chiedersi quando la creazione di una workstation Linux audio ha realmente bisogno di due server sonori quando il software che si vuole utilizzare è probabilmente tutto compatibile con JACK. Inoltre, è giusto pensare al sovraccarico ed ai possibili problemi che si potrebbero manifestare quando si utilizzano due server audio. Quindi non è raro che molti disattivino o disinstallino PulseAudio sulle loro macchine Linux audio.

Su una workstation audio Linux che non viene utilizzata per altro si può disinstallare PulseAudio, su una workstation che viene utilizzata anche per altre attività, potrebbe essere una scelta migliore disabilitare PulseAudio per la sessione specifica in cui si vuole fare l'audio e produzione musicale . PulseAudio è il server audio predefinito su un sacco di distribuzioni, non fa parte delle applicazioni di avvio e non viene chiamato neanche attraverso il sistema init e viene sempre avviato o attivato appena un'applicazione vuole riprodurre l'audio. Aggiungete a questo il fatto che la maggior parte delle distribuzioni PA è impostato per il respawn automatico, e quindi dopo l'uscita o quando si blocca capirete che PA non permette di essere disattivato facilmente. C' è un modo relativamente semplice per disabilitare PA in una specifica sessione. Primo, modificate o create il file “~/.pulse/client.conf e assicuratevi che contenga la seguente linea:

autospawn = no 

Ora potete inviare un segnale di kill al server pulseaudio:

killall -9 pulseaudio 

Oppure con:

pulseaudio -­k 

Non dovrebbe più riattivarsi, ed avrete così una sessione senza PA.

Link esterni

- Alcuni consigli e trucchi Esben-Stein­

- Alcuni consigli: Rosegarden wiki

- Qui alcuni esempi per Linux-Gentoo

- Articolo di Sound on Sound sui problemi PCI: http://www.soundonsound.com/sos/dec04/articles/pcnotes.htm


Utilizzo di FireWire

Quando si utilizzano le interfacce audio FireWire è generalmente consigliato utilizzare un kernel real­time. Naturalmente questo non è necessario, ci sono anche utenti che segnalano successi con i kernel generici, ma se avete difficoltà a raggiungere la stabilità sul vostro sistema (ad es. quando si riscontrano troppi xrun) le prime cose oltre l'installazione di rtirq, sarebbe provare ad installare o compilare un kernel real­time.


Legacy FireWire stack

Accertatevi che il modulo raw1394 sia caricato. Dovreste avere il modulo caricato automaticamente aggiungendolo al vostro file /etc/modules con questa riga:

raw1394 

Caricando questo modulo viene creato il device /dev/raw1394. L'utente standard non ha permesso di usare questo device, ma aggiungendo la regola ad udev in /etc/udev/rules.d/ potrete controllare questi permessi.

Le più recenti distribuzioni installano anche le corrispondenti regole udev quando si installano pacchetti FFADO, ma se la vostra distro non lo fa allora potete creare un nuovo file, 50-raw-firewire.rules, con la seguente riga per consentire al gruppo audio di utilizzare questo nodo:

KERNEL=="raw1394", GROUP="audio"

Saranno inoltre necessari i driver FFADO (molte distro mettono a disposizione già i pacchetti per questi driver) e impostare il driver in JACK su 'firewire' sia in qjackctl oppure sulla riga di comando con l'argomento -dfirewire.

JuJu FireWire stack

Dal kernel 2.6.37 lo stack FireWire legacy è stato rimosso dai sorgenti del kernel in favore dello stack JuJu. Se avete installato FFADO dovrebbe prendersi cura di configurare correttamente il dispositivo(i). Invece di creare un nodo /dev/raw1394, lo stack JuJu crea nodi per ogni dispositivo in /dev/, il primo dispositivo è sempre /dev/fw0. Tenete presente che il dispositivo principale è sempre il vostro controller, non la scheda audio.


Per utilizzare JACK con i dispositivi FireWire, impostare il driver su 'firewire' in qjackctl oppure utilizzare l'opzione -dfirewire sulla riga di comando.


Troubleshooting (Risoluzione dei problemi)

Dopo aver impostato e configurato il vostro sistema potrebbe ancora non essere così performante come lo volevate.

Esistono molti strumenti utili che possono aiutarvi ad analizzare perchè la perfomance generale non è quella che vi aspettavate, questi potrebbero rivelare qual'è la causa dei colli di bottiglia presenti nel vostro sistema.


Top

Top è probabilmente lo strumento più utilizzato per visualizzare le informazioni di sistema come CPU o memoria. È installato di default nella maggior parte delle distribuzioni.

Top2.png


Con l'aiuto di Top potete scoprire quale processo sta utilizzando tutta la vostra CPU o memoria. Premendo h si ottiene una schermata di aiuto. Per ordinare secondo l' utilizzo della memoria, invece che per utilizzo della CPU è possibile premere F + N + Invio.

Htop

Htop è per certi versi il fratello maggiore più sofisticato di top.

Htop2.png

Latencytop

Latencytop è uno strumento molto utile in grado di scoprire quale processo sta generando latenza nel sistema. Latencytop.png

Cyclictest

Proprio come Latencytop misura le latenze del sistema, cyclictest misura le latenze del kernel. Cyclictest ha diverse opzioni, ma uno dei modi più utilizzati per eseguire il comando è:

# cyclictest -t1 -p 80 -n -i 10000 -l 10000 -m


Un thread singolo (-t1), priorità di 80 (-p80), uso clock_nanosleep (-n), utilizzare 10000 us intervallo base del thread (-i 1000), utilizzare 1000 loop e quindi uscire (-l 10000), blocco allocazioni di memoria attuali e futuri (-m). Altre informazioni su clock_nanosleep si possono trovare nella sua pagina di manuale (man clock_nanosleep).

Altri esempi d'uso di cyclictest:

http://code.goto10.org/projects/puredyneold/wiki/KernelAndSystemOptimization#TestingandBenchmarking

https://rt.wiki.kernel.org/index.php/Cyclictest#Expected_Results

DA FARE:

  • Il modulo snd-hrtimer
  • Di più sulla sincronizazzione midi (midi timing)
  • Harddrive tuning (si applica anche ai dischi SATA?)
  • Strumenti per il Troubleshooting (ffado-diag, alsa latency tool, alsa midi latency tool, jack_delay)
Strumenti personali
Namespace
Varianti
Azioni
Navigazione
Strumenti