Lennart Poettering ci fa un po’ il punto della situazione di PulseAudio e di come potrebbe/dovrebbe diventare il nuovo server audio per il Desktop, così come Esound è per GNOME e arts è/era per KDE.
Perché dovremmo volere ancora un altro server audio? Me lo chiedo anche io, effettivamente… La risposta è semplice, ed è molteplice e richiede anche la creazione di nuove API per l’audio:
In poche parole:
- ALSA è più complicato del necessario – confermo
- ALSA è specifico solo a Linux
- PortAudio non è adottato da nessuno (ad es. lo usa Audacity)
- Molte app multimediali importanti cercano di reinventare un livello di astrazione audio (MPlayer, Xine…)
Tutto questo fa sì che ci sia bisogno di un ulteriore spinta, stavolta compatta e unilaterale, per ottenere finalmente qualcosa di sano: un sistema audio che sia semplice da usare per gli sviluppatori, abbastanza generico da andare bene per i compiti più diversi, a latenza abbastanza bassa per poter finalmente avere qualcosa di funzionante per la produzione audio (vedi recente articolo su Jokosher)
Ecco il post originale, che merita una lettura approfondita, e qui trovate il video della presentazione fatta al Linux.conf.
Beh, da musicista pinguino… non so se ci siano altri metodi per ottenere qualcosa del genere, ma se fosse l’unica soluzione: perché non adottarla? L’unico appunto è che siamo sinceramente stanchi di vedere tutto rivoluzionato ogni 2 o 3 anni…
Dovrebbe avere lo stesso intento di Phonom di KDE4…
Stanchi? di più!
Se conti che solo adesso si riesce ad avere un desktop funzionante quasi esclusivamente con alsa, ma che ci sono ancora un mondo di applicazioni che pretendono oss, senza contare tutte quelle citate e altre che reinventano la ruota per questo o quel motivo…
Ma anche questo PulseAudio è destinato a far la fine di tutto il resto, cioè a trovare il suo piccolo giardino di estimatori e andare ad arricchire il parco dei server audio.
A meno che:
1) Non fornisca prestazioni immensamente superiori a qualsiasi altra cosa (dubito) o
2) non fornisca dei layer di compatibilità validissimi e assolutamente trasparenti alle applicazioni per cui ogni applicazione trova in apparenza quel che vuole (alsa, oss, jokosher, portaudio, xinelib…) anche se dietro c’è sempre il solo PA
domanda: e jackd?
E’ l’ennesimo tentativo di riinventare la ruota.
Perchè non migliorare Jack invece di buttare via i soliti anni uomo nella programmazione di progetti destinati ad essere mediocri?
Sono stufo di fork e reimplementazioni fatte a metà. Meglio concentrarsi su un progetto e portarlo alla fine.
Un esempio di progetto a metà? Gstreamer. Piattaforma fantastica e codice molto efficiente… Ma documentazione scarsa, schifosa e per lo più inesistente.
@ Vime
Phonon sarà più una sorta contenitore per altri server audio. L’idea è quella di fornire un layer alle applicazioni che vedono Phonon come server audio, ma in realtà Phonon potrà sfruttare ad esempio GStreamer, ESD o aRts per riprodurre i contenuti multimediali. In questo modo non si reinventa la ruota
@EnricoTuxMind
Esattamente Enrico, mi fa piacere che tu abbia precisato.
La cosa bella di Phonon è che sarà portabile, andando a sfruttare,
tramite backend, i ‘server’ audio specifi di ogni piattaforma.
(Magari DirectSound di Windows, alsa su linux e l’equivalente su mac).
Questa sembra la vera novità di KDE4. Codice specifico per ogni task,
indipendente dal resto e quindi portabile.
Sperem :)
E Jack dove lo mettiamo?
Non saprei dal lato programmazione, ma è un server audio semplice da utilizzare lato user, potente da utilizzare lato enginering/routing delle sorgenti, e soprattutto risposta in termini dei 5-10ms con schede audio professionali (quindi si escludono creative e company), anche di 100euro (consiglio la audiophile 24/96).
Capacità di missaggio di fonti multiple, non multipiattaforma, vero, ma non ha più senso portarlo altrove che creare l’ennesimo a.s.s. ?
E, per inciso, anche jack e arts sono dei backend; jack può utilizzare oss come può utilizzare alsa.
Arts può utilizzare oss, alsa e perfino jack, insomma, se il tutto si riduce alla portabilità, che si porti jack, no?
jack è un server audio dedicato a chi ha bisogno di prestazioni superiori: usarlo su un sistema desktop quadratico medio è un insulto a jack e ai suoi sviluppatori, in primis, e uno spreco.
esd è un relitto del passato, che è sopravvissuto alla transizione tra gnome 1.x e 2.x perché linux non aveva una piattaforma audio moderna e/o funzionante come alsa.
infine, alsa non c’entra nulla con un server audio: un server audio deve fare il mixing degli eventi sonori, cosa troppo a basso livello per il dmix alsa.
pulseaudio è solo un primo passo; il secondo sarebbe un’interfaccia per le applicazioni semplice, ad esempio gnome_play_sound(uri); il terzo sarebbe una specifica per un “tema sonoro” simile a quella per le icone, così da permettere notifiche sonore senza dover conoscere dove il file audio si trova, ma usando solo costanti simboliche.
@j_zar: gstreamer non è “a metà”. se manca della documentazione, apri un bug. se vuoi dei tutorial, perché non ne scrivi uno tu?
ah, per ultimo: gstreamer *non* è un server audio. può essere usato come base per un server audio aggiungendo caching e queueing per non avere collisioni tra due applicazioni che tentano di suonare due eventi contemporaneamente.
io non ho capito ancora bene una cosa. correggetemi se sbaglio: lo schema di funzionamento di vari sound daemon è questo:
“app –> sound daemon (esd, alsa, pulse audio, ecc.) –> alsa –> scheda audio”.
giusto?
con phonon si avrà un funzionamento del genere, da quello che ho capito.
“app –> phonon –> sound daemon –> alsa –> scheda audio”.
dal momento che alsa (a differenza di oss) puo gestire tranquillamente più flussi audio contemporaneamente, a cosa sevono i sound daemon????
non sono un programmatore, ma mi pare di capire che tutti questi passaggi non permetteranno MAI di avere prestazioni decenti con l’audio, o sbaglio?
ciao
bobo
@bobo
alsa può mixare, ma se tutte le applicazioni devono aggiungere il supporto per alsa non se ne esce vivi (tonnellate di codice replicato, bug fixing che deve propagarsi, etc.). in più, anche se alsa può mixare, non può mettere in coda due eventi sonori. ecco a cosa serve un sound server.
quanto alle prestazioni: se ti servono prestazioni, jack è un sound server che permette di avere risultati (tramite real-time processing) degni di uno studio di registrazione (è stato sviluppato con queste finalità).
@bobo: non penso che alsa possa gestire più flussi audio contemporaneamente, perlomeno non con tutte le schede audio
@Emmanuele
“Un esempio di progetto a metà? Gstreamer. Piattaforma fantastica e codice molto efficiente… Ma documentazione scarsa, schifosa e per lo più inesistente.”
Leggi: “Ho capito che Gstreamer non è un server audio ma volevo portare un esempio di progetto a metà.”
So benissimo che il tutorial me lo posso scrivere da solo… Che la documentazione me la posso scrivere da solo e che ci sono tante cose che posso fare da solo… Non mi sembra una argomentazione intelligente soprattutto perchè non sono uno che non contribuisce. Evitiamo arroganza gratuita.
Tuttavia c’è una cosa che non è stata detta, ovvero che prima il progetto PulseAudio si chiamava Polypaudio, è che sono almeno 3 annetti buoni che è già in fase di sviluppo. Questo cambia abbastanza le cose visto che non è un progetto “nuovo”.
@j_zar
non hai capito quello che volevo dire; se una persona trova insufficiente la documentazione di un progetto o la scrive da sé, oppure dice come la vuole. non sapendo che documentazione vuoi, posso solo consigliare di scrivere quello che pensi sia “buona documentazione”. per esempio: io non uso gstreamer ma ho una (vaga) idea di come funzioni, quindi mi serve un tutorial per capire come mettere in piedi una pipeline in un programma per sentire un file di musica. un completo neofita avrà bisogno di qualcosa di ancora più di base; un esperto vorrà realizzare un completo set di playback multitraccia con la possibilità di muovere frammenti o applicare filtri+effetti, quindi avrà bisogno di qualcosa di più specializzato. di tutorial del primo tipo per gstreamer ce ne sono; del secondo pure; del terzo no. è documentazione fatta a metà, quindi? oppure mancanza di documentazione ad alto livello?
niente arroganza gratuita, per carità; prospettiva, forse.
poi, se vogliamo andare a vedere, le librerie di sviluppo di GNOME mancano di documentazione (gnome-vfs su tutte ;-)), quindi direi che GNOME è un progetto lasciato a metà.
Purtroppo al di là delle disgressioni sui vari sound server/daemon bisogna dire che siamo ancora molto lontani da quello che è directsound per windows e coreaudio per MacOSX.
Sicuramente esistono ottimi progetti per Linux (come Jack), ma “mettere su” un sistema audio decente, anche solo per usare programmi emuli di GarageBand o FruityLoops (vedi Jokosher e LMMS) è ancora una roba riservata agli smanettoni.
Avere un minimo di sistema audio che gestisce più di una traccia alla volta e magari anche un sintetizzatore software (come timidity) è una roba fattibile solo da chi si sa destreggiare con shell e file di configurazione.
A me piacerebbe poter giocare con gioiellini tipo MIxxx e Hydrogen senza dover ricompilare il kernel o fare a pugni con Jack e gli xruns.
Allo stato attuale suonare anche solo un cavolo di file midi è un impresa.
Cosa che sia con Winzoz che con MacOSX è possibile dal primo avvio del sistema.
Speriamo che qualcuno metta un po’ di ordine in questo caos, magari freedesktop.org…!
@emanuelle
[quote]
jack è un server audio dedicato a chi ha bisogno di prestazioni superiori: usarlo su un sistema desktop quadratico medio è un insulto a jack e ai suoi sviluppatori, in primis, e uno spreco.
[/quote]
Dici che in termini di prestazioni sarà preferibile pulseaudio (meno cpu) o che pulseaudio è bene rispetto a jack pechè gli sviluppatori di jack non si offendano ?!
@anonimo
(il nome è “emmanuele”, non ho fatto filmini soft-core negli anni ’80 ;-))
che te ne fai di un server audio orientato all’uso (semi-)professionale su un desktop? di cosa hai bisogno per i tuoi bisogni quadratici medi? useresti un bazooka per far fuori una zanzara?
Ciao… ho scritto un post che sfiora l’argomento PulseAudio… vorrei trovare un modo per ottenere un mixer di volume “per-application”… kiedo a te ke magari sai come si fa :)