In pratica l'ALSA sound driver accetta i flussi audio che noi gli mandiamo solo in formato non compresso raw PCM.
L'ALSA rispetto a OSS può accettare più flussi "raw PCM" contemporaneamente e miscelarli insieme.

In pratica, tutti i vari formati multimediali più o meno compressi come MP3, OGG, WAV, ACC, WMA, RMA, etc. perchè possano essere riprodotti, è necessario che vengano tradotti in raw PCM ed è questo che fanno i riproduttori multimediali che usiamo, quando ascoltiamo musica (mp3, wav, WMA ecc..) o guardiamo un video (mpg, avi, ecc..).

Sicchè uno sviluppatore di un riproduttore multimediale si perde nel mare dei migliaia di formati audio/video che la sua opera dovrebbe gestire.. A venirgli in aiuto subentrano i cosiddetti "multimedia framework", tipo Gstreamer, NMM, Xine, Helix, e anche il vecchio aRTS di KDE 3. Lo sviluppatore adotta quindi le API di Gstreamer, ad esempio, e si preoccuperà lui di decodificare il formato video dell'utente..

Gli sviluppatori di GNOME consigliano di usare il framework Gstreamer al momento.. Altra strada hanno scelto gli sviluppatori di KDE 4.4. Hanno infatti tolto il vecchio soundserver aRTS (che era anche un audio framework, tra l'altro) dichiarando che "non era la soluzione ideale", in quanto mancante di diverse importanti funzioni , e l'hanno sostituito con Phonon, che un soundserver NON è, ma è un ulteriore livello di astrazione. In sostanza Phonon ha le sue proprie API per gestire i formati multimediali, scritte nel modo più semplice possibile, ed è Phonon stesso a preoccuparsi di dialogare con i frameworks vari (Xine-lib, che sembra essere il "piu scelto", Gstreamer, libvlc, libsmplayer, persino Directshow di Windows, QuickTime di Apple o altro), essendo in grado di cambiare il framework usato addirittura al volo.. In molti sono favorevoli a questo approccio, in quanto si libera lo sviluppatore della preoccupazione di scegliere un framework, gli si fornisce delle API semplici da gestire e per di più multipiattaforma. Ma in molti altri non sono daccordo all'uso di tale sistema adducendo le motivazioni più varie. Il futuro vedrà chi ha ragione..

In linea di massima chi usa GTK+ tenderebbe ad usare GST (GStreamer) o libcanberra.
Chi usa Qt o QtLibs tenderebbe ad usare Phonon.

Per ora è francamente troppo presto per parlarne, e la lotta Phonon Vs Gstreamer Vs altri Framework, lotta che di striscio o in pieno investe anche la solita lotta fra toolkit GTK+ Vs Qt Vs Qt/KDELibs, almeno per il momento si aggiunge alle centinaia di lotte che si infiammano all'interno della comunità del pinguino, che creano un mare di divisione, lotte, confusione, ma anche libertà di scelta..

LADSPA (Linux Audio Developers Simple Plugin Architecture): per quanto riguarda LADSPA, ritengo necessario fare una piccola premessa. Di questi tempi, nello sviluppo di un qualsiasi sotware, si va sempre di più alla ricerca della "modularità", ovvero della possibilità di aggiungere, ad un programma già esistente, nuove funzionalità semplicemente mediante dei "plugin".

Questo succede in linux per moltissimi programmi. Chiunque può creare e distribuire nuovi plugin, e contribuire così attivamente allo sviluppo.

Considerate LADSPA come un sistema per realizzare plugin per manipolare audio, per tutti quei programmi che accettano i plugin realizzati usando le API di LADSPA.

I plug-in scritti usando LADSPA possono essere facilmente integrati in altri programmi.

Sono stati realizzati con LADSPA effetti audio strabilianti: delay, flanger, equalizzatori, riverberi, pitch shifter (servono a modificare la tonalità di un brano), e numerosissimi altri.

L'idea non è del tutto nuova a dire il vero, un altro sistema simile sono i plugin VST (non free, usati ad esempio, su sistemi Windows, da programmi come l'ottimo Cubase).

DSSI (Disposable Soft Synth Interface) invece è un linguaggio per scrivere plugins che viene definito "LADSPA per gli strumenti", come una sorta di "estensione di LADSPA". DSSI può addirittura funzionare con strumenti VSTi mediante il wrapper plugin dsst-vst. DSSI è supportato da sofware come Rosegarden, ma in linea di massima non ha conosciuto una grande diffusione.

In questo periodo si sente sempre più parlare di un nuovo standard per la creazione di plugins audio, nato per "superare le limitazioni di LADSPA" e DSSI, detto LV2 (Ladspa Version 2), buono sia per effetti che per strumenti e sembra essere molto promettente.

Audacity, Ardour, l'applicazione "jack-rack" (jackd invia l'audio a jack-rack, e questo glielo restituisce in tempo reale rimodulato dai plugin LADSPA che gli avete installato. Jack-rack è come una sorta di "rack" per effetti LADSPA..), il sequencer Rosegarden sono programmi capaci di usare i plugin LADSPA, aprendo a possibilità enormi.

I plugin LADSPA sono di solito contenuti in "/usr/lib/ladspa/", e sono file con estensione ".so".

GStreamer, non è un soundserver ma una piattaforma di sviluppo, una serie di API scritte in linguaggio C. In sostanza i contenuti multimediali vengono spesso distribuiti in formato compresso secondo determinati algoritmi (codecs), che per essere letti devono essere prima "tradotti in un linguaggio comprensibile" (raw PCM). Alla base di GStreamer sta il concetto di Pipeline (tubatura). In sostanza la "tubatura" consiste di tre parti:

1. Source: lettura della sorgente (ad esempio un file mp3) attraverso le API di GStreamer.
2. Decoder filter: GStreamer decodifica il sorgente in formato PCM. A questo punto il sorgente è perfettamente comprensibile e quindi manipolabile.
3. Sink: GStreamer fornisce le API per decodificare e anche per riprodurre la sorgente. L'ultimo elemento della catena, quindi, è praticamente la riproduzione.

Per quel che riguarda l'audio, GStreamer vi dà la possibilità di scegliere il vostro intermediario con l'ALSA driver. In altre parole voi eseguite un mp3 con un programma che usa GStreamer ("source", ad esempio Rhythmbox), GStreamer lo decodifica e lo manda a.... A chi volete voi! Eseguite da terminale "gstreamer-properties" e scegliete come completare la vostra "pipeline".. Scegliete se questo segnale decodificato deve andare ad alsa-libs (pipeline "alsasink"), a OSS ("osssink"), a PulseAudio ("pulsesink"). GStreamer e la struttura a "pipeline" consumano parecchie risorse della CPU.

In sostanza il funzionamento di GStreamer è legato ai plugin installati (ancora una volta ricorre il concetto di "plugin"). Se volessimo potremmo persino usare ESound, basta soltanto procurarsi il plugin "esdsink" che si trova in qualche pacchetto della vostra distribuzione (per ubuntu Jaunty è gstreamer0.10-esd).

Anche i "codecs" ovvero gli algoritmi usati per comprimere i contenuti multimediali, vengono decodificati da Plugin.

I plugin per i codec di GStreamer sono raggruppati, in base al livello decrescente di "qualità" del loro sviluppo, in 3 gruppi: Good, Bad, Ugly. In bad e Ugly si trovano gli algoritmi per la decompressione di codecs proprietari il cui sviluppo è spesso complicato da problematiche persino legali.

Esempi di applicazioni che usano GStreamer sono Amarok (audio player), Banshee (audio player), Elisa (media center), Exaile (audio player), Pitivi (video editor), Rhythmbox, Serpentine (audio cd recorder), Sound Converter, Sound Juicer (cd ripper), Totem (movie player) e altre.

In realtà GStreamer non è il solo decoding engine in Linux, sistema "gia pronto", in linux, per decodificare codec. "libavcodec" sono librerie per encoding/decoding video e audio usate da software quali FFmpeg (un convertitore di formato video, che rientra in realtà nell'ambito di un progetto più vasto, che include diversi programmi per audio-video, compresi player e convertitori), Avidemux, MPlayer, VLC, Xine. Ricordiamo inoltre le "xine-libs", che sono le librerie di decoding di "xine", ma anche di programmi come "Totem" e "Kaffeine". Alcuni programmi possono usare anche più di un sistema di decodifica, ad esempio "Totem" può usare le xine-libs ma anche GStreamer.

SDL (Simple Directmedia Layer): si tratta di librerie multipiattaforma utili per creare finestre, svolgere operazioni grafiche complesse, gestire audio, cd-rom, video, trattare contenuti multimediali (non solo "audio" quindi..). Le librerie SDL sono usate ad es. da software quali DOSBox, Bochs (SDL plugin per la sua GUI), MPlayer, ScummVM, VLC con SDL plugin ed altri.

OpenAL (Open Audio Library, multipiattaforma), sono delle API per gestire audio in 3D (e quindi multi-speakers). Le librerie OpenAL sono usate in videogiochi come Doom3, Quake3, Unreal tournament 2003, Prey.

FMOD (prodotto commerciale, multipiattaforma) sono librerie audio (con API). Sono usate in videogiochi come Call of Duty 4, Far Cry, Second Life. Il loro uso è gratuito per prodotti non commerciali, altrimenti è un prodotto che si paga (e costa..).

Questo è il punto, alcune applicazioni usano le API ALSA, altre quelle aRts, altre le API di JACK, alcune gestiscono l'audio da se, ma solo se l'audio passa tutto da un server solo, può essere realmente controllabile. Pensate in che situazione si trova uno sviluppatore di un software, che deve prima di tutto scegliere come gestire l'audio della sua applicazione e adottarne le API. Allora quindi scegliere le API più performanti? Quelle in più fervente sviluppo? Quelle apparentemente più supportate (oggi..)? O quelle più "multipiattaforma"?..


Tor na al menù principale di "Audio e Linux"