Guida a Logitech Media Server, Squeezelite e derivati.

[bigtube]

Viene mostrato quanto descritto nel testo del precedente post
il primo comando rtirq.sh status evidenzia per la porta USB ( irq/19-ehci_hcd ) una priority = 80
ridando rtirq.sh start la priority della USB passa a 93.
La shell ci racconta la verità o meglio come stanno le cose.

[luigigi]

P.S. Prossima puntata > Montare i dischi con i file musicali
un po' piu' impegnativo.....mo' che son partito non mi fermo piu'....visto che apprezzate..... e vi ringrazio

sei una macchina da guerra....

[bigtube]

sei una macchina da guerra....

E questo è niente Luigi ....beh cosa combini con la Soekris...

[luigigi]

E questo è niente Luigi ....beh cosa combini con la Soekris...

stà ancora a magnà a pizza.... Development Cirografici... assolutamente autorizzati ed auspicati.. sia ben inteso...
ora, consegnato il douk all'amico proprietario, "ho sotto" la scheda audio dell maudio che uso per registrarmi.... pensavo peggio. si lascia più che ascoltare..

[bigtube]

Un' altra modifica al file rtirq.conf sperimentata di recente e molto efficace
come impatto finale riguarda la stringa riportata nel file con questa sintassi
nell'ultima riga :

#RTIRQ_HIGH_LIST=”timer”

si puo' osservare che questa stringa appare commentata per presenza del
simbolo "#"
La modifica consiste nel togliere questo simbolo e scrivere la nuova stringa cosi :

RTIRQ_HIGH_LIST=”timer jackd”

Per accedere al file ricordo di scrivere nel terminale :

nano /etc/rtirq.conf

Eseguita la modifica come di consueto si salva il file con CTRL+x > Y > Enter
Riavvio della macchina.

A macchina riavviata si dovra' riaggiornare le priority eseguendo di nuovo

rtirq.sh start

per vedere se ha funzionato e controllare che le modifiche siano attive
dare il comando :

top

si osserverà che a questo punto jackd assumerà la priority rt con nice -20


A questo punto buon ascolto....il risultato sarà direi abbastanza significativo
soprattutto se si usa l'ultima versione di Daphile con il kernel 4.1.2
la ISO è disponibile con questo kernel aggiornatissimo a questo link ( ultime due in elenco ):
Index of /tmp.qSPQbWD3rw

[hifi25nl]

Scusa, ma ho alcune osservazioni da fare:

1) Nice è irrilevante per l'audio realtime:

"You could also allow the audio group to renice processes with the help of the limits.conf file, but since nice uses SCHED_OTHER it basically does nothing to increase the performance of a low-latency real-time audio environment that relies on SCHED_FIFO/SCHED_RR. Consult the sched_setscheduler manpage for more info on this subject."
fonte http://wiki.linuxaudio.org/wiki/system_configuration

2) Jackd lavora ad una frequenza di campionamento fissa. Se ad esempio lo facciamo lavorare a 192 kHz e gli mandiamo un file da 44,1 (o viceversa) lo sovracampionerà con l'algoritmo standard di bassa qualità proprio di alsa.

3) Non ha senso abilitare RTIRQ_HIGH_LIST="timer" a meno che non si voglia per qualche motivo dare una speciale priorità a timer (tra 91 e 99) e una priorità molto diversa, cioè più bassa, a tutto il resto. Un caso molto particolare che secondo me non si applica all'utilizzo audio non pro.

4) rtirq non può essere utilizzato per dare priorità ai programmi (come jackd). E' per questo che ho scritto l'applicazione rtapp da utilizzare in combinazione con rtirq.
Nota: nella schermata pubblicata jackd non ha una priorità FIFO (RTPRIO) e quindi, anche se è abilitato per il realtime, in realtà non lo sta utilizzando effettivamente.

[bigtube]

Scusa, ma ho alcune osservazioni da fare:

1) Nice è irrilevante per l'audio realtime:

"You could also allow the audio group to renice processes with the help of the limits.conf file, but since nice uses SCHED_OTHER it basically does nothing to increase the performance of a low-latency real-time audio environment that relies on SCHED_FIFO/SCHED_RR. Consult the sched_setscheduler manpage for more info on this subject."
fonte http://wiki.linuxaudio.org/wiki/system_configuration

l'ho letto anch'io ....ho voluto provare lo stesso e siccome il kernel lo accetta e l'ho gradito all'ascolto mi permetto di consigliarlo....io non pontifico,ma provo

2) Jackd lavora ad una frequenza di campionamento fissa. Se ad esempio lo facciamo lavorare a 192 kHz e gli mandiamo un file da 44,1 (o viceversa) lo sovracampionerà con l'algoritmo standard di bassa qualità proprio di alsa.

Qui ti do' ragione infatti dopo prove avevo intenzione di correggere il tiro perchè ho capito il meccanismo ( che pero' nessuno spiega con chiarezza )
ma poi ci vuole il tempo.....il mio è limitato, faccio quello che posso

3) Non ha senso abilitare RTIRQ_HIGH_LIST="timer" a meno che non si voglia per qualche motivo dare una speciale priorità a timer (tra 91 e 99) e una priorità molto diversa, cioè più bassa, a tutto il resto. Un caso molto particolare che secondo me non si applica all'utilizzo audio non pro.

sarà come dici tu ma era proprio quello che cercavo e mi sta bene fino a prova contraria.

4) rtirq non può essere utilizzato per dare priorità ai programmi (come jackd). E' per questo che ho scritto l'applicazione rtapp da utilizzare in combinazione con rtirq.
Nota: nella schermata pubblicata jackd non ha una priorità FIFO (RTPRIO) e quindi, anche se è abilitato per il realtime, in realtà non lo sta utilizzando effettivamente.

Sara pure ma dando il comando top nella schermata per jackd compare rt -20 ....come lo devo interpretare?
Ma sopratutto chissa' perchè all'ascolto funziona....certo puo' essere che sono colto dalle visioni....ma io me lo tengo cosi. Anche altri utenti hanno approvato pero'....avranno
anche loro le visioni....puo' essere

Comunque in conclusione ho dato qualche dritta.....gli utenti e anch'io siamo soddisfatti....errori fondamentali mi pare di non averne fatto
tenendo conto che non è il mio mestiere e che inoltre non chiedo nulla in cambio. Cio' che ho suggerito non sono certo le tavole della legge.
Ognuno è libero di fare quello che vuole.
Tra l'altro anche senza queste ottimizzazioni Daphile và molto bene .....basta metterle in opera per rendersi conto da soli se le cose
cambiano ....a quanto pare il feedback positivo c'è e io mi accontento.

[hifi25nl]

"rt -20" significa che jackd è stato lanciato con realtime abilitato e il livello di nice è -20. Il fatto che il realtime sia abilitato non significa necessariamente che sia utilizzato.
Per verificare utilizzare il comando sotto indicato, cioè ps -eLo rtprio,pri,cmd | grep jackd (nella parte iniziale della schermata riportata non c'è la colonna relativa a rtprio)

[piero@archlinux ~]$ ps -eLo rtprio,pri,cmd | grep jackd
    91 131 /usr/bin/jackdbus auto

Il primo numero è la priorità realtime. In questo caso è 91. Per verificare la priorità realtime (SCHED_FIFO) di qualsiasi altro programma sostituire a jackd il nome del programma.
Ovviamente tale controllo ha senso se il kernel è effettivamente realtime, non un kernel semplicemente low latency.

In relazione all'aggiunta di jackd a RTIRQ_HIGH_LIST (supposto che funzioni, bisogna verificare con il comando riportato sopra) potrebbe (dipende dalle altre configurazioni di rtirq) succedere che a jackd sia assegnata una priorità maggiore della scheda audio con risultati potenzialmente nefasti per la riproduzione, in particolare in situazioni di stress. Sarebbe come aumentare la larghezza di un fiume prima della foce (visto da un altro punto di vista sarebbe come restringere la foce rispetto alla larghezza immediatamente precedente)

Non considerate queste mie osservazioni come delle critiche. Le scrivo nell'ambito di una prospettiva scientifica, dove la discussione di eventuali errori può portare ad una reale comprensione del problema. Nessuno è esente da errori, nemmeno il sottoscritto...

[UnixMan]

4) rtirq non può essere utilizzato per dare priorità ai programmi (come jackd). E' per questo che ho scritto l'applicazione rtapp da utilizzare in combinazione con rtirq.

perché non utilizzare banalmente schedtool? (man page).

[hifi25nl]

Perché nell'ultima versione che ho utilizzato non assegnava la priorità realtime a tutti i threads ma ad uno soltanto. Non so se la situazione è cambiata nel frattempo.
rtapp è in grado inoltre di assegnare la priorità scelta anche per threads creati successivamente al lancio, come è il caso di HQPlayer, controllando la situazione ogni 60 secondi.