Eliminare/ridurre processi inutili.

di saguan67 il 25.10.11, 19:17:58

Domanda:
Al fine di prevenire latenze, xrun e quant'altro possa
causare problemi audio; sarebbe il caso di eliminare e /o ridurre
all'osso tutti quei processi che al fine dell'utilizzo del pc solo ed
esclusivamente come DAW, si rivelano inutili e "distraggono" la cpu dal
lavoro primario che gli chiediamo?
Solo a titolo d'esempio, il
network manager o altri processi (non so quali) in quella determinata
sessione può non interessare....

Se questo é vero:
1. quali processi eliminare/fermare?
2. Come eliminarli/fermarli?
3. Come automatizzare il tutto all'avvio della "sessione musicale"?

di Rael il 25.10.11, 19:44:53

sarebbe bello che i "veterani" mettessero un post che faccia da tutorial
mirato agli xrun .. un prontuario su come aggredirli e ridurli
all'impotenza!

Non sò se la mia è un idea campata per aria o se ha un fodamento ....

di el_Felix il 26.10.11, 10:39:20

Potresti creare degli script che bloccano i servizi di base del sistema,
tipo cupsd (stampa), atd (servizio che manda in esecuzione programmi),
lo stesso servizio internet può essere bloccato, disconnettendo
l'interfaccia, ecc.
In ogni caso non credere che togliere
dall'esecuzione tali servizi sia risolutore dei problemi di latenza e
degli xrun: l'importante è che il kernel sia quello giusto (che dà già
di per sé più priorità ai processi in realtime che a quelli in
background) e che la scheda sia ben supportata e che jack sia ben
configurato. Tutto il resto è un di più, ma a me capita di registrare o
missare anche mentre sto su internet o mentre leggo la posta. Non è una
cosa molto consigliabile, ma non è nemmeno troppo traumatica per il
sistema.

di saguan67 il 27.10.11, 09:11:19

Il fatto é che con il mio portatilino (hp6710b 1 gb ram - 2.20GHz.) ogni "decimo di micronanosecondo" risparmiato serve... .
Comunque devo dire che, abbinandolo alla Fast Track Ultra, sono
riuscito a registrare 6 tracce (3 di batteria microfonata + chitarra +
basso + voce) in diretta e simultaneamente. In onor del vero buona parte
del materiale (circa 2 ore di registrazione) é inascoltabile ma 2 ò 3
pezzi (da circa 2 - 3 min. cadauno) sono riuscito a definirli. C'é
qualche "scoreggina" di troppo qua e là, ma non credo che con quel
portatile si riesca a fare di più. Appena torno a casa vi linko il sito
per ascoltare il risultato.

Tornando
in topic, penso (e chiedo conferma) che tutto il lavoro che si riesce a
far risparmiare alla cpu sia guadagnato alla registrazione.

di el_Felix il 27.10.11, 17:59:49

In realtà la gestione delle risorse in realtime è affidata a script e
parti del kernel. Pur togliendo dall'esecuzione servizi e programmi poco
utili non si guadagna niente di particolare. Al massimo se hai meno
programmi aperti usi meno RAM, se non lanci programmi mentre registri
non sovraccarichi il processore, ma se ci sono dei problemi che
riguardano la registrazione, ci saranno a prescindere dalla quantità di
programmi in esecuzione. Magari saranno di meno, ma ci saranno lo
stesso! una cosa importante invece è assicurarsi che la linea di
interrput su cui comunica la scheda audio con la cpu non sia condivisa
con troppi dispositivi, quello è un problema che potrebbe invalidare la
stabilità di un sistema!
per capirlo basta consultare l'output di questo comando:

Codice:

cat /proc/interrupts

di Rael il 29.10.11, 00:16:36

Felix .. come si interpretano questi valori?

Codice:

rossano@rossano-record-studio:~$ cat /proc/interrupts
            CPU0      CPU1     
  0:        137          0  IO-APIC-edge      timer
  1:          2          0  IO-APIC-edge      i8042
  6:          3          0  IO-APIC-edge      floppy
  7:          0          0  IO-APIC-edge      parport0
  8:          0          0  IO-APIC-edge      rtc0
  9:          0          0  IO-APIC-fasteoi  acpi
  12:          4          0  IO-APIC-edge      i8042
  14:          0          0  IO-APIC-edge      pata_via
  15:      75471          0  IO-APIC-edge      pata_via
  16:    196583    244020  IO-APIC-fasteoi  via@pci:0000:01:00.0
  17:    4625632        512  IO-APIC-fasteoi  ICE1712
  20:          0          0  IO-APIC-fasteoi  uhci_hcd:usb2
  21:      4130      21842  IO-APIC-fasteoi  ehci_hcd:usb1, uhci_hcd:usb4, sata_via
  22:        242      95781  IO-APIC-fasteoi  uhci_hcd:usb3
  23:      3104          0  IO-APIC-fasteoi  uhci_hcd:usb5, eth0
  28:          0          0  IO-APIC-fasteoi  ahci
  29:          0          0  IO-APIC-fasteoi  pata_jmicron
 NMI:          0          0  Non-maskable interrupts
 LOC:    8214672    8360393  Local timer interrupts
 SPU:          0          0  Spurious interrupts
 PMI:          0          0  Performance monitoring interrupts
 PND:          0          0  Performance pending work
 RES:    592150    864721  Rescheduling interrupts
 CAL:      9446      1007  Function call interrupts
 TLB:      2261      2754  TLB shootdowns
 TRM:          0          0  Thermal event interrupts
 THR:          0          0  Threshold APIC interrupts
 MCE:          0          0  Machine check exceptions
 MCP:        25        25  Machine check polls
 ERR:          1
 MIS:          0
rossano@rossano-record-studio:~$


di el_Felix il 29.10.11, 09:35:46

Quella è la lista delle linee di interrupts (una per riga, indicate dal
numero a sinistra) e alla fine di ogni riga c'è il chip hardware che le
utilizza. Per capire quale chip è la tua scheda audio devi visualizzare
il risultato di questo comando:

Codice:

cat /proc/asound/modules

di Rael il 07.11.11, 13:55:35

.... vediamo se con il tuo aiuto comincio a capirci qualcosa ...

la scheda audio dovrebbe essere in questa riga

17: 4625632 512 IO-APIC-fasteoi ICE1712 ......... in effetti la ICE 1712 è la M-audio Delta 1010LT

l'interrupt è questo? IO-APIC-fasteoi

Il fatto che questi abbiano il medesimo interrupt può incasinare?

Codice:

  16:    196583    244020  IO-APIC-fasteoi  via@pci:0000:01:00.0
  20:          0          0          IO-APIC-fasteoi  uhci_hcd:usb2
  21:      4130      21842      IO-APIC-fasteoi  ehci_hcd:usb1, uhci_hcd:usb4, sata_via
  22:        242      95781      IO-APIC-fasteoi  uhci_hcd:usb3
  23:      3104          0        IO-APIC-fasteoi  uhci_hcd:usb5, eth0
  28:          0          0          IO-APIC-fasteoi  ahci
  29:          0          0          IO-APIC-fasteoi  pata_jmicron


Se si, questo potrebbe essere il motivo perchè a volte Ardour crasha?

Si può fare qualcosa per sistemare la cosa?

di el_Felix il 07.11.11, 16:36:29

Allora, quella è la tua scheda audio, ma quello che mi hai postato ora è
la lista degli interrupt ma diversa da quella che hai postato il post
precedente
in quella la scheda audio era sull'interrupt 17, da sola, il che significa che non dovrebbe aver problemi.
Comunque
più che i crash di Ardour avere la scheda su una linea di interrupt
affollata può causare problemi a jack: non parte, oppure non riesce a
gestire bene latenze basse, crasha ma lui, non ardour, e problemi del
genere!

di Rael il 07.11.11, 17:04:10

No la lista è sempre quella, l'ho tolta io nel post per evidenziare meglio quello che volevo dire.

Quindi se ho ben capito gli interrupt sono ok giusto?

Mi piacerebbe capire allora perchè a volte Ardour crasha ... ma stò andando OT .. rifarò la domanda nella sezione appropriata.

di saguan67 il 12.11.11, 16:51:49

Beh, non chiedetemi come, cosa e quando (soprattutto perché...) é
successo: All'improvviso l'audio mi funziona solo ed esclusivamente con
Jack, ivi compreso youtube. Se provo con Alsa mi dà errore (ogni volta
uno diverso...)

di el_Felix il 12.11.11, 19:50:05

Controlla che con i repo di KXstudio non ti si sia installato jackd: è
un demone (servizio) che si avvia in automatico all'avvio, dai questo
comando in un terminale all'avvio del pc:

Codice:

ps ax | grep jack

e posta il risultato.

Se ti si avvia jackd è come se avessi
costantemente jack abilitato, di conseguenza la soluzione è creare
l'alsa2jack bridge e il pulseaudio bridge, che sono due servizi offerti
da Cadence (lo trovi nei repo di kxstudio sempre, comodissimo) che puoi
attivare e stoppare a tuo piacimento.

di saguan67 il 13.11.11, 19:02:27

Scusatemi per la lunghezza del post

Allora:
ho provato tutti i kernel che sono riuscito a trovare (ho un grub
talmente lungo che non bastano neanche i rotoloni regina per stamparlo).

Tralasciando
(!!!) il riconoscimento della Fast Track Ultra, che, per quanto
riguarda le porte MIDI, solo i due kernel forniti da Munny le vede (per
l'audio la vedono tutti i kernel siano essi lowlatency, realtime,
preempt), non emergono grosse differenze prestazionali tra tutti e il
brutto é che nessuno mi soddisfa. (Qualche xrun di differenza, ma
comunque siamo sempre oltre a una media di 1 xrun ogni 3 minuti)...

Ho provati tutti i kernel, sia quelli di munny che quelli scaricati dai repo di KXstudio, ecco come:

ho
registrato con ardour due tracce audio di circa 3 minuti. Messo in loop
il progetto, l'ho mandato in riproduzione continua per circa 2 ore (sì,
proprio così. Per ogni kernel!!!).

Le impostazioni di jack erano:
BUFFER SIZE: 512;
SAMPLE RATE: 44.100;
LATENCY: 11.6 ms.;
PERIODS/BUFFER: 3;
MODE: "duplex";
DITHERING MODE (ma che cos'é?): "none".

Il PC é un HP AMD_64 3 GHz - 2 Gb di ram.

A
questo punto, considerato che ho provato tutti i kernel conosciuti,
tutte le versioni di ubuntu, ubuntu studio, ecc... (attualmente sto
usando la 10.04 con i pacchetti di KX studio) e che i risultati non si
differenziano molto, giungo a queste (tristi) conclusioni:

a) il problema sta nei driver della fast track ultra
b) il problema sta nelle porte usb;
c) il problema risiede nella scarsa potenza del pc.
d) la Fast Track Ultra non funziona bene.

- nel caso a): non mi resta che aspettare che i ragazzi di alsa trovino la soluzione... ma quando?;
-
nei casi b) e c) mi sveno e mi compro un I7 con porta usb eSATA; ma se
poi non funziona ancora? Come faccio a provarlo in negozio?
- nel caso d) (escluso in quanto provata in negozio con mac e win e funziona bene), mi dò una botta in testa

Detto quanto sopra chiedo:

1) mi potreste dire quale é il vostro hardware e quale scheda audio usate?
2) quali sono le vostre impostazioni di jack?
3)che risultati ottenete in termini di prestazione (xrun, crash, ecc...)?

Grazie a tutti...

di el_Felix il 13.11.11, 19:29:42

Considera che per quanto sia ottima, la tua scheda non è a livelli
stratosferici, che non ti riesca a offrire delle prestazioni eccellenti è
anche normale. Se l'abbini al fatto che è una usb, che non hai un
processore all'ultimo grido, che probabilmente non è la scheda più
supportata del mondo, ottieni che avere un xrun ogni 2-3 minuto non è
poi nemmeno così malaccio.
Io, quando avevo la MOTU (altro tipo di
scheda, qualche gradino sopra la tua, ma nemmeno troppo) collegata via
firewire a un pc con i7 e bla bla bla, visti i problemi di driver,
quando avevo un xrun si inchiodava tutto (jack, ardour, certe volte pure
tutto il sistema) e fischiava a un volume pazzesco dalle uscite
monitor. Mi sono preso certi vaffa da gente che stava registrando con
cuffie chiuse che nemmeno ti immagini...

Tornando
a noi: io credo che non valga la pena né cambiare scheda, né tantomeno
farti un pc nuovo (a meno che non sei già in procinto di cambiarlo, io
alla fine col mio quad core del 2008 ci vado ancora alla grande) né
stare a impazzire dietro a mille impostazioni.
Al massimo, se non
devi fare niente di eccessivamente professionale, e soprattutto quando
non registri, non scendere mai sotto a valori di buffer size di 1024.

Ma,
per capire, quando hai degli xrun ti si blocca tutto? ti crasha
qualcosa? se ti capitano in registrazione ti registra qualche scoppietto
o rumoraccio? no perché sennò...fregatene! anche a me capitano -
soprattutto quando sono costretto a lavorare a basse latenze e ho
progetti molto pesanti - ma oltre allo scoppiettio istantaneo di quel
momento non mi creano nessun problema!

di saguan67 il 13.11.11, 19:47:59

Beh, ad essere sinceri, crash mi capitano rarissimamente. Scopiettii e rumori strani sì. ogni volta che mi appare un xrun...

Come faccio a fregarmene!? poi me li ritrovo in riproduzione di quello che ho registrato

di el_Felix il 13.11.11, 19:55:00

Sei sicuro? hai fatto una prova? Quando capitano a me, come ti dicevo,
mentre registro, se vado a riprodurre il materiale registrato non ho
niente che non va!

di saguan67 il 13.11.11, 21:45:32

Urkaaaaa! Ma lo sai che forse hai ragione? Stavo proprio sentendo una
registrazione e in effetti quando ci sono gli xrun non si sentono rumori
strani

In compenso ci sono qua e là delle "scoreggine". che sono?

(ti sto mandando una mail al riguardo...)

di el_Felix il 13.11.11, 22:04:35

Beh possiamo parlarne anche qui, in fondo riguarda pur sempre
l'ottimizzazione del sistema per evitare questi "inconvenienti" o, come
li hai chiamati tu, "peti digitali" - questo è il termine tecnico.

Comunque, fai una cosa per toglierti ogni scrupolo, vai su
Ardour->Opzioni e da quelle parti dovresti trovare l'opzione "Marker
at xrun location" o qualcosa del genere, abilitala flaggandola e prova a
registrare, ti dovrebbe mettere un indicatore chiamato "xrunN" per ogni xrun, dove N è il numero progressivo dell'xrun.
A
quel punto vai a riascoltare e senti se in quei punti c'è qualcosa che
non va: se non c'è vuol dire che l'xrun non è entrato in registrazione e
che, se anche te ne capita qualcuno, non crea danni alle tracce
registrate.

Per quanto riguarda le scoreggine, non saprei, le
senti a caso? non dipendono né da clip digitali/analogici (il segnale
arriva al rosso nella channel strip di Ardour)?
spiega bene il fenomeno e vediamo che riusciamo a capire

di saguan67 il 13.11.11, 22:34:01

la mail che ti sto mandando contiene il link per scaricare il file, poi
ne parliamo qui senza problemi, ma non saprei spiegare bene....
per
quanto riguarda il "Marker at xrun location" mi sa che era gà impostato
perché me li fa vedere e in effetti i "peti digitali" non coincidono con
i marker degli xrun.

nel file che ti mando vedrai che la
chitarra é completamente distorta (non c'ho pensato a tagliare il
guadagno del canale), ma ho provato a metterla in mute e i "peti" si
sentono comunque. Ho provato a mettere ogni singolo canale in solo o in
mute ma comunque si sente.

di N i n U il 05.03.12, 17:47:43

Tornando al discorso di disabilitare i processi inutili,ad es. in Ubuntu
si potrebbe considerare la creazione di un account utente dedicato al
solo utilizzo audio e da li in sistema --> preferenze -->
applicazioni di avvio togliere la spunta ai processi inutili/fastidiosi.
Inoltre
"blacklistare" i moduli non indispensabili (soprattutto nei notebook
nel caso delle schede integrate) potrebbe aiutare, almeno a liberare
ram.
Il classico "blacklist snd_hda_intel" da inserire in
/etc/modprobe.d/blacklist.conf cosí come suggerito nella guida di Senbee
é un esempio.
Ovviamente mi riferisco a macchine datate o poco performanti dove ogni tentativo di ottimizzazione potrebbe portare migliorie.

Poi ci sono questi walkthrough che ho trovato sul wiki linuxmusicians:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration
Sono ottime soluzioni a cui ci si puó ispirare.
Per
esempio, unbind ovvero un metodo per non far utilizzare una specificata
porta usb ad un dato driver, nel caso, come ha spiegato el_Felix, di
una linea di interrupt molto affollata ,se il bios non offre molte
possibilitá si potrebbe ricorrere a questo metodo (se qualcuno ha
conoscenze dettagliate a riguardo potrebbe aiutare ad approfondire la
questione).
Poi ci sono dei trucchetti che vanno dal disinstallare
synaptic o almeno a rimuoverne la funzione "quick search" disinstallando
il pacchetto relativo apt-xapian-index che a detta di alcuni
provocherebbe xrun (in realta' la causa sarebbe xché si affida a cron
per aggiornare il suo database cosi dice la guida) oppure l‘opzione di
montaggio "noatime" da inserire nel file /etc/fstab (non aggiorna i
tempi di accesso al file quando il file é letto) aiuterebbe la
performance generale soprattutto in registrazione.

Io sono un fan di queste guide e di quel geniaccio di Jeremy Jongepier alias Autostatic, penso ne sia l‘autore.
E‘
un attivista di linuxaudio ed ho avuto il piacere di assistere ad
alcuni suoi talk in Irlanda l‘anno scorso in occasione del LAC2011.
A proposito sono disponibili i pdf e video dei suoi workshop per tutti quelli che sono interessati (li consiglio vivamente):
http://lac.linuxaudio.org/2011/?page=program
Gia' che ci sono vi linko anche il suo succulento PPA:
https://launchpad.net/~autostatic/+archive/ppa

p.s.Sarebbe bello in futuro costituire un gruppo di traduzione o tester di queste guide magari poi da inserire in linuxaudio.it

di N i n U il 05.03.12, 18:00:07

Ah dimenticavo una cosa banale, utilizzare lxde, xfce o openbox come DE al posto di gnome o ancor meglio kde...

di el_Felix il 06.03.12, 09:54:08

I consigli da te postati sono tutti molto preziosi! se posso mi permetto giusto di fare qualche precisazione:

per
quanto riguarda le linee di interrupt, c'è da dire che se anche una
presa usb si trova sulla linea di interrupt condivisa dalla scheda
audio, per esempio, non serve disabilitarla o liberarla del tutto,
l'importante è non usare quella presa usb mentre si sta usando la scheda
audio per non incorrere in xrun. La linea di interrupt (ma immagino che
lo sai
) è un canale diretto che il kernel mette a disposizione per un
dispositivo hardware per comunicare direttamente con il processore: se
su quel canale non si si posiziona nessun dispositivo, che sia abilitato
o meno non fa molta differenza;
per quanto riguarda i moduli da
caricare per risparmiare memoria, dico che a parte una situazione in cui
si trovano decine e decine di moduli inutili, coi pc moderni (più di 2
Gb di ram) non ha molto senso stare ad ammazzarsi per risparmiare magari
qualche megabyte (a dir tanto) blacklistando dei moduli. Il discorso
della scheda audio interna ovviamente è diverso perché potrebbe creare
conflitti o il fastidioso problema che jack parte usando quella invece
che quella desiderata;
per quanto riguarda cron invece c'è da dire
che gira principalmente nelle ore notturne (anche se viene richiamato
dal servizio anacron appena si accende il pc nel caso in cui lo si
spenga la sera) e che comunque si può fare in modo di affinare il suo
intervento così da non doverlo "avere tra i piedi" durante le
registrazioni o un mixing importante, senza necessariamente
disabilitarlo o disinstallarlo (o disinstallare synaptic e compagnia
bella).

Comunque, come dicevo, in linea di massima avere delle
linee guide, dei consigli del genere, è molto utile e ti ringrazio
tantissimo per averli postati (se ti va metti un post nella sezione
"Link utili" linkando sia i pdf che i video e spiegando cosa sono
oviamente) e sarebbe anche un'ottima idea quella di creare delle risorse
in italiano o direttamente tradotte da quelle o comunque "ispirate" a
quei lavori.

di N i n U il 06.03.12, 14:06:55

Per quanto riguarda unbind ed interrupts se vuoi possiamo continuare ad
approfondire analizzando il mio caso che mi genera diversi dubbi.(non so
se va off topic ma penso di no).
Allora il portatile é quello che
trovi in firma un Packard bell dual core del 2005-2006, quindi non piú
giovanissimo, che utilizzo con la mia roland ua25-ex ed il kernel rt di
Tango studio stable.
Premetto che riseco a raggiungere latenze buone
quindi va bene cosí com‘é non mi lamento, infatti con jack a 44100-128-2
(sample rate, frames/period, period/buffer) a 5,8 ms di latenza
ottengo qualche xrun (dipende poi da sessione a sessione, e qua andiamo
sul mistico ) ed a 48000-64-3 riesco a a spingermi fino a 4 ms con qualche x-run.

Ho 3 porte usb, solitamente una la uso per il mouse ed un altra che utilizzo sempre per la scheda.
Controllo il mio bus usb con lsusb:

Codice:

Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 002: ID 093a:2510 Pixart Imaging, Inc. Hama Optical Mouse
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 0582:00e6 Roland Corp.
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
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 002 Device 004: ID 0bda:0158 Realtek Semiconductor Corp. Mass Storage Device
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Quindi sul bus 006 ho la mia scheda audio e sul bus 007 ho il mouse ottico.
Notare,
se spostassi la scheda nell unica altra porta libera disponibile ,quest
ultima rimarrebbe sul bus 006 cambierebbe il device in 003.
Insomma le porte usano o il bus 007 o il bus 006, se non ho sbagliato i conti.
Infine, il bus 002 viene occupato dal lettore di sd card integrato che non posso disattivare da bios.

Le schede rilevate dando cat /proc/asound/cards sono:

Codice:

 1 [UA25EX        ]: USB-Audio - UA-25EX
                      EDIROL UA-25EX at usb-0000:00:1d.0-2, full speed


Analizziamo quindi le linee di interrupts rilevate dal kernel dando cat /proc/interrupts:

Codice:

  0:    3309380    3308076  IO-APIC-edge      timer
  1:      5749          1  IO-APIC-edge      i8042
  8:          1          0  IO-APIC-edge      rtc0
  9:        49        54  IO-APIC-fasteoi  acpi
  12:        88      18369  IO-APIC-edge      i8042
  16:          0          0  IO-APIC-fasteoi  uhci_hcd:usb3
  17:      54266      45865  IO-APIC-fasteoi  wlan0
  18:          0          0  IO-APIC-fasteoi  uhci_hcd:usb8
  19:      60867      1509  IO-APIC-fasteoi  ata_piix, ata_piix, ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb7
  21:          0          0  IO-APIC-fasteoi  uhci_hcd:usb4
  23:      3722      61095  IO-APIC-fasteoi  ehci_hcd:usb2, uhci_hcd:usb6
  26:          0          0  PCI-MSI-edge      eth0
  27:        264      18257  PCI-MSI-edge      i915


Apparentemente non vi é nessuna voce riguardo il driver della scheda,
quindi considero il controller uhci_hcd:usb6 relativo al bus 006 della
mia scheda che si trova sulla linea 23 insieme al controller ehci_hcd2
del bus 002 dove si giace il lettore di sd card che non uso.
Dalla mia analisi non mi vengono in mente molte soluzioni se volessi migliorare la situazione da questo punto di vista se non:
1)
fare un unbind come dice la guida del controller ehci_usb2 sul bus 006,
ma cosí facendo otterrei che i driver ehci che sono i driver per usb
2.0 non mi andrebbero sul bus 006 costringendomi ad utilizzare la scheda
solo a 1.1
2) disabilitare APIC all avvio cosi da non permettere la
condivisione degli interrupt, ma sinceramente non ho mai provato e la
cosa mi spaventa un pó.

Lo so é un pó intricato ma che idea vi siete fatti ?
Magari sbaglio qualcosa nella mia analisi....

di el_Felix il 06.03.12, 17:37:46

La storia dei bus usb è un po' una rogna purtroppo.

Però puoi
provare a fare una prova: hai un portatile, perciò dovresti poter usare
il trackpad, giusto? prova a staccare il mouse e usa soltanto il
trackpad, così ti togli lo scrupolo.

Comunque se tu usi la scheda
audio come usb 2, hai solo due possibili interrupt in utilizzo: la
linea 19 (decisamente troppo affollata, con i moduli ata che gestiscono
dischi e lettori cd) e la linea 23. Se vuoi fare una prova, metti la
scheda in tutte le prese usb che hai, e vedi che cosa succede: se noti
delle differenze sostanziali (cerca di usare magari progetti pesanti, o
fai delle prove di registrazione a bassa latenza di qualche traccia in
contemporanea) allora usa quella che ti dà meno xrun possibili.

Di
fare magheggi strani non te lo consiglio: se non devi registrare un
disco a livello professionale (nel senso che qualcuno ti sta pagando per
un lavoro) se ti capita qualche xrun, con l'attrezzatura che hai e le
impostazioni che hai, non succede niente. Se qualcuno ti sta pagando,
cioè lo stai facendo per lavoro, già potrebbe avere più senso: ma
t'assicuro che con 5 ms di latenza avere degli xrun è più che normale!

di N i n U il 06.03.12, 17:55:50

Ok grazie per il tuo parere
Potrei
fare delle prove ma secondo me non cambierebbe poi molto, anzi se
usassi la porta dove adesso si trova il mouse mi ritoverei la scheda sul
bus 007 che giace sull interrupt piú affollato.

p.s. odio il trackpad lo staccherei via a morsi
Ciao !