Audio Linux: passato, presente, e futuro discussi all’ LPC (2° Parte)

Audio linux. Audio e video hanno molto in comune. OOS è basato sul sistema di chiamate standard POSIX, come open(), read(), write(), map(), etc, mentre ad ALSA (che supporta le stesse chiamate) si accede generalmente tramite libasound che ha un enorme set di funzioni.

Queste funzioni forniscono vari modi di controllare la configurazione hardware e software tra un gran numero di comandi.

Sotto molti aspetti, l’audio è simile al video secondo Davis. Entrambi generano “un’esperienza umana sensoriale renderizzando un buffer di dati tramite una periferica di output. Ci sono certo varie differenze, a differenza dell’audio, i dati video non cambiano così frequentemente quando qualcuno sta semplicemente usando una GUI a meno che non stia guardando un video.

Così, Davis si chiede, le applicazioni video/grafiche dovrebbero comunicare con l’hardware direttamente via open/read/wite/etc.?
Per la grafica, questo è stato mediato da un server o da una api che agisce come server per vari anni. L’Audio dovrebbe funzionare allo stesso modo, nonostante ci siano molti in disaccordo, “ma loro sbagliano” dice Davis.

Il problema con unix

I metodi UNIX standard per la gestione dei dispositivi, usando open/read/write/etc., non sono necessariamente interfacce sfruttabili per interagire in realtime con l’hardware. Davis fa notare che lui ha utilizzato UNIX per 25 anni e l’adora, ma il driver API manca di parti importanti per la gestione dell’audio (e del video).
Sia i dati temporali che i dati in formato semantico non fanno parte dell’API, ma sono necessari per gestire i dati audio/video.

E’ necessaria una “architettura server-esque” e API che possano esplicitamente gestire il formato dei dati, routing, latency inquiries e sincronizzazione. Questo server dovrebbe mediare tutta l’interazione con i dispositivi e vivere nello spazio utente.
L’API non dovrebbe richiedere che altri servizi siano messi nel kernel. Le applicazioni dovrebbero smettere di credere che possano e debbano controllare l’hardware da sole.

L’API OSS deve morire

L’API OSS richiede che tutti i servizi dell'audio Linux (come la conversione del formato dati, routing, etc.) siano implementati nel kernel. Inoltre incoraggia le applicazioni a fare cose che non funzionano bene con altre applicazioni che provano anch’esse a realizzare qualche tipo di operazione audio. Le applicazioni OSS sono scritte in modo che pensino di essere le uniche a gestire l’hardware.

Per via di questo, Davis dice chiaramente che l’API OSS “deve morire”.
Fa notare come fedora già non lo supporti più e si augura che altre distribuzioni seguano la stessa direzione.
Quando ALSA fu adottato, ci poteva essere l’opportunita di sbarazzarsi di OSS, ma all’epoca c’erano varie ragioni per non farlo secondo Davis.

Guardando OS X e l’audio Windows

Apple ebbe un approccio completamente diverso quando ridisegnò l’API audio per Mac OS X. Il Mac OS 9 aveva una “architettura audio grezza” che fu completamente rimpiazzata con OS X. Non fu supportata compatibilità backward, fu semplicemente detto agli sviluppatori di riscrivere le loro applicazioni. Così, i componenti CoreAudio forniscono una singola API che supporta sia gli utenti desktop che le applicazioni audio professionali.

L’altra faccia della medaglia, Windows, ha avuto tre interfacce audio separate durante il cammino. Ognuna ha mantenuto compatibilità backward a livello API, cosicchè gli sviluppatori di applicazioni non ebbero bisogno di cambiare i propri codici, sebbene fosse richiesto di riscrivere i drivers.
Windows ha impiegato molto per ottenere low latency rispetto a Linux e Mac OS X.
La chiara implicazione è che la compatibilità backward tende a rallentare le cose, il che non è una grande sorpresa.

Repost: 22 Ott 2009

Scarica subito una copia gratis

3 Commenti

  1. Avatar photo Gibson 22 Febbraio 2011
  2. Avatar photo linus 22 Febbraio 2011
  3. Avatar photo Fabrizio87 29 Marzo 2011

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend