Jack ..impostazioni ottimali

.. vediamo se qualcuno raccoglie la sfida e fa un vademecum di massima su come impostare Jack in modo da ottenere il massimo delle prestazioni .. in barba agli xruns ...

  

mmm beh l'impostazione ideale secondo me non esiste. Io ho queste due impostazioni:
- per utilizzo standard del pc, non produzione audio (navigazione, ascolto musica, ecc): buffer size 1024, sample rate 44100 Hz, periods/buffer 2;
- per utilizzo produzione audio (registrazione, mixing, ecc): buffer size 64 o 128, sample rate 44100 Hz per produzioni audio/48000 Hz per produzioni video, periods/buffer 2.

secondo te è corretto tenere il più basso possibile il buffer size in registrazione e aumentarlo in fase di mixing con i plugins in modo da avere più margini con la CPU e abbassare così il rischio degli xruns?

A proposito di campionamento, su questa guida si consiglia 48000 come ottimale. Usare 44100 produce differenze apprezzabili sul carico della CPU?

@Rael, sì scusa mi sono sbagliato, la seconda impostazione va divisa in due sotto-casistiche: una quella di registrazione (buffer size che ho indicato) e una quella di mixing ed editing, con buffer size intorno ai 512 (cerco di non andare oltre finché il sistema regge, comunque anche con 1024 la situazione è abbastanza accettabile).

@franki: la questione è dibattuta e se ne era parlato parecchio anche qui se non sbaglio; più che una questione di carico di cpu bisognerebbe valutare il carico del chip che esegue il campionamento, cioè quello integrato nel convertitore A/D, che sarebbe la scheda audio, ma è comunque trascurabile la differenza di carico visto che la maggior parte dei convertitori lavorano benissimo anche a frequenze di 96 kHz e oltre.
A mio avviso la questione è più legata alla matematica della conversione e del campionamento (se dovrò avere un risultato a 44100 Hz - lo standard mondiale per il compact disc, il più elevato al momento in termini audio - è preferibile lavorare con quella frequenza o suoi multipli diretti come 88200, 174000, ecc; se lavoro a 48000 Hz costringo il convertitore a dover ricalcolare l'intero campionamento una volta che devo scrivere il file d'uscita).
E' sicuramente vero che facendo mix tutti in digitale più qualità si ha e meglio è, ma posso anche dirti che una volta ho fatto una prova d'ascolto di un campionamento a 44100 Hz e uno a 192000 Hz e non c'era assolutamente nessuna differenza percettibile: ciò è dovuto al fatto che i 44100 Hz sono stati calcolati appositamente per coprire più che correttamente tutto il range delle frequenze udibili dall'uomo, così come detta il teorema del campionamento (giusto per i fan della matematica)
Comunque come detto la questione è dibattuta e profonda e di certo non si esaurisce con le poche considerazioni fatte da me ora. Però se ne può parlare molto volentieri   

Per chi utilizza ubuntu studio, quindi con un kernel RT di default, è corretto inserire queste righe nel limits.conf?

Codice:

@audio - rtprio 99
@audio - memlock 256000
@audio - nice -10

dove di default si trova questa situazione

Codice:

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain>        <type>  <item>  <value>
#
#Where:
#<domain> can be:
#        - an user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                for maxlogin limit
#        - NOTE: group and wildcard limits are not applied to root.
#          To apply a limit to the root user, <domain> must be
#          the literal username root.
#
#<type> can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
#<item> can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open files
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: [-20, 19]
#        - rtprio - max realtime priority
#        - chroot - change root to directory (Debian-specific)
#
#<domain>      <type>  <item>        <value>
#

#*              soft    core            0
#root            hard    core            100000
#*              hard    rss            10000
#@student        hard    nproc          20
#@faculty        soft    nproc          20
#@faculty        hard    nproc          50
#ftp            hard    nproc          0
#ftp            -      chroot          /ftp
#@student        -      maxlogins      4

# End of file

La situazione di default, come vedi, è 'pulita' in quanto non c'è nessuna direttiva attiva (il '#' davanti a una riga la rende un commento e perciò non operativa).
Quelle ultime tre righe servono a dire che i processi lanciati da utenti o altri processi facenti parte del gruppo 'audio' acquisiscono una serie di caratteristiche che il kernel controllerà durante l'esecuzione. Perciò io credo che servano proprio perché tu un kernel di tipo realtime, altrimenti non riusciresti a sfruttarne al meglio le caratteristiche.

.. file modificato .... vedremo nei prossimi test se servirà a migliorare le prestazioni.

   

... dopo un check veloce .. mi sembra che la situazione peggiori con il limit.conf modificato
dopo un po' che andava qsynth e Rosegarden .. è fioccato un xrun e sia il la percentuale di RT in Jack che il valore della CPU di Rosegarden era maggiore rispetto a prima .. per cui l'ho riportato come di default ed effettivamente non ho xruns e i valori sono più bassi.

  

Felix, ma come fai ad arrivare a 64? È merito della super-scheda RME? O del processore?
Scusate per l'off topic

sampipol ha scritto:Felix, ma come fai ad arrivare a 64? È merito della super-scheda RME? O del processore?
Scusate per l'off topic

Credo le due cose messe insieme .. più qualche ottimizzazione .. tipo spegnere la rete wifi e altri servizi che non servono in quel momento ma che impegnerebbero la CPU ... dico bene Felix?

Beh il processore è sempre lo stesso da quando ho iniziato a fare audio, perciò non credo c'entri, credo sia più una questione di scheda e di sistemi che diventano sempre più 'intelligenti', probabilmente anche grazie ai kernel a bassa latenza (ma forse sto dicendo una baggianata...)
Sotto ai 64 non ho mai fatto prove, magari ci provo giusto per vedere come va, ma non avrebbe neanche troppo senso   

Sul mio sistema posso impostare buffer 64, ho provato per alcuni minuti e ha
girato senza xrun, ma con strana voce robotica. Penso di essere al limite della
scheda audio. Sto parlando di una semplice riproduzione di mp3, non certo di
una sessione di Ardour. Un buffer di 32 semplicemente non é selezionabile.