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

JACK e PulseAudio: sono entrambi necessari?
JACK e PulseAudio attulmente servono a scopi diversi, secondo Davis, c’è la speranza che convergano nella stessa direzione.
Jack è fondamentalmente pensato con bassa latenza, mentre PulseAudio è finalizzato per il desktop, dove la compatibilità tra applicazioni e i bassi consumi sono due delle maggiori priorità.

Entrambi sono certamente necessari attualmente, visto che Jack va in conflitto con le applicazioni di numerosi sistemi desktop, mentre PulseAudio non è in grado di supportare applicazioni audio professionali.

Anche se è stata disegnata un interfaccia per gestire tutti i fabbisogni che sono soddisfatti da Jack e da PulseAudio, Davis immagina che ci sia un modo di forzare l’adozione di una nuova API.

Se non fosse possibile, si pongono alcune questioni serie su come migliorare l’infrastruttura audio di Linux. Continuare ‘esistenza di entrambi, insieme con il supporto di API più vecchie, porta a continuare la confusione su quale sia la giusta via da seguire veramente.
Lui crede che una API unificata sia possibile dal punto di vista tecnico – Apple Core Audio è un buon esempio – ma può succedere solo con una “manipolazione poitica e sociale”.

Poettering: lo stato attuale dell’audio Linux

Il nocciolo della discussione con Poettering è stato l’audio desktop, piuttoto che l’audio professionale. Ha iniziato parlando di ciò che è cambiato dalle ultime LPC evidenziando come EsounD e OSS fossero ufficialmente spariti, almeno in Fedora.
OSS può essere ancora abilitato in Fedora, ma per lui è stato un grande obiettivo averlo rimosso .

Ci furono bugs in solo tre aplicazioni dovute alla rimozione di OSS, VMware e quake2 tra esse. Ci ha detto che non furono “grosse preoccupazioni”, ma un menbro del pubblico ha fatto notare che “12.000 utenti urlanti” di VMware sono un problema significante.

Poettering non ha dato grande importanza dicendo che lui incoraggiava altre distribuzioni a seguire l’esempio.

La confusione alle LPC degli ultimi anni lo ha portato a creare la “Guida alla API Audio Linux”, che ha aiutato a chiarire la situazione, sebbene ci fossero reclami su ciò che diceva riguardo KDE e OSS.
Con Fedora 12 e in altre distribuzioni, è arrivato l’tilizzo del realtime scheduling nelle applicazioni audio per desktop. C’è un nuovo meccanismo per gestire la priorità realtime che previene applicazioni maliziose dal monopolizzare la CPU. I desktop attualmente fanno uso di timers ad alta risoluzione, perché “veramente necessitano qualcosa in più di una risoluzione di 1/hz” per le applicazioni audio.

Il supporto per buffers di più di due secondi è stato aggiunto. ALSA generalmente restringe la dimensione del buffer a 64K, consentendo al server di “prendere decisioni in base ala latenza e all’interrupt rates”. Un nuovo abstraction mixer è stato aggiunto anche se ce n’erano già quattro esistenti in ALSA . Questi erano molto specifici per l’hardware secondo Poettering, mentre il nuovo è un “abtraction molto basic”

Linux Audio - Le sfide per il prossimo anno

Ci sono un certo numero di problemi con i drivers audio attuali che Poettering ha listato perchè necessitano attenzione per il prossimo anno. Attualmente, per scopi di riparmio energetico, PulseAudio spegne i dispositivi due secondi dopo che diventano idle. Questo può portare problemi per quei drivers che generano rumore quando sono accesi o spenti.
In più, ci sono aree in cui i drivers non riportano le informazioni corrette al sistema.

Il range di decibel delle applicazioni è una di queste, insieme con le stringhe dei dispositivi che possono essere rotte o mancanti in vari browser, il che rende difficile scoprire automaticamente l’hardware.
La logica di negoziazione non è standardizzata. L’ordine on cui questi parametri vengono cambiati pu essere interpretato diversamente da ogni driver, il che porta ad altri problemi a livelli più alti econdo lui.

Ci sono altri problemi nel timing per la sincronizzazione tra audio e video che devono essere indirizzati a livelo driver.

Poettering ha anche un’itera lista di cambiamenti che è necessario siano fatti nell’API ASA in modo che PulseAudio (e altri) possano ricevere maggiori informazioni riguardanti l’audio. Ci dice che sarebbe perfetto se ALSA potesse darci un indizio su come la roba è connessa.
C’è anche la necessità di sincronizzare clocks PCM multipli all’interno di un dispositivo, inoltre ci sono un buon numero di altri problemi da risolvere.

Il codec pass-trough spedendo dati codec inalterati come SPDIF, HDMI, o A2DP, ai dispositivi è molto “incasinato” e nessuno ha immaginato una buona soluzione per gestire i problemi di sincronizzazione con esso. C’è la necessità di un API PCM più semplice, dice Poettering, in modo che le applicazioni possano utlizzare i  pull model piuttosto che essere forzate al push model.
Un’altra aerea che necessita interventi è la gestione di un buffering di 20 secondi. C’è un intero nuovo set di problemi che arriva con questo cambiamento.

Conclusioni

Entrambe le presentazioni ci hanno dato un chiaro senso di come le cose stiano migliorando nell’audio Linux, sebbene forse non con la velocità che gli utenti vorrebbero vedere. Sono stati fatti dei chiari progressi ed è stata tracciata una strada. Se rimane da vedere l’idea di Davis di unificare l’API audio linux, ci sono comunque una bel po’ di bravi hacker che ci lavorano e prima o poi qualcosa arriverà.

 

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend