Etnablog.altervista.org :)

Visitatore: 1311415
Welcome ospite
Menu di accessibilità:
Dimensione carattere:

Home > Linux > La gestione dei devices audio su Linux
Contenuto della pagina:
21 Maggio 2010

La gestione dei devices audio su Linux

Come sappiamo "i devices", in generale, in linux, per essere usati, vengono "montati" in delle cartelle.

In sostanza, la cartella /dev è usata in linux per conservare, come files, i "device nodes" che fanno riferimento a certi devices del sistema (devices che ci sono, ma anche devices che nel nostro sistema non ci sono..). In pratica programmi, giochi, per interfacciarsi ai devices sfruttano questi nodes.

ALSA monta i devices audio nella cartella /dev/snd/ (invece OSS le monta in /dev/dsp) ed è proprio questa la cartella che le applicazioni usano per eseguire funzioni audio (registrare, riprodurre, modificare i volumi). Diamo uno sguardo dentro la cartella /dev/snd/, potreste vedere diversi devices, riconoscibili come diversi file "pcm", "control", "timer", "seq", dipende dal vostro hardware. Per esempio il /dev/snd/pcmC0D6c che io vedo tra i miei devices, indica la scheda audio 0, device 6, "c" sta per "capture", come ad esempio un "microfono" ("p" invece starebbe per "playback", quindi si parlerebbe di un device di "riproduzione").

Come fa ALSA a cacciare dentro quella cartella /dev/snd/ i propri devices?

I Kernels dal 2.6 controllano un filesystem chiamato sysfs, montato sulla cartella "/sys", che contiene informazioni sui devices attualmente collegati al sistema. In generale per vedere i file system montati nel vostro sistema, digitate su shell "mount" (il che è equivalente a scrivere "cat /etc/mtab").

udev, il "device manager" del kernel 2.6 (rimpiazza il vecchio devfs), sfrutta proprio le informazioni contenute nel sysfs per creare una directory /dev "dinamica".
udev sta in esecuzione in sottofondo ("demone udevd") e usa queste informazioni date direttamente dal kernel (gli "uevents") per creare in tempo reale i "device nodes" corrispondenti all'hardware attualmente in vostro uso proprio nella cartella "/dev" .
Gli uevents inviati dal kernel sono gestiti sulla base di specifiche "regole", che possono così portare dal caricamento di specifici moduli del kernel, la creazione dei device nodes, l'assegnazione costante dei permessi per un device node ad un owner o a un gruppo, fino all'esecuzione di un programma che gestisca il device.
Tali regole si trovano in /etc/udev/rules.d/ sotto forma di files con estensione ".rules". Potete impostare voi stessi, ad esempio, una regola che assegni ad una determinata scheda sempre lo stesso valore hwplug:x,y .
Considerate inoltre che udev si crea persino un proprio database dei device collegati nel sistema.
Se date un'occhiata nella cartella /sys, vi rendete conto di come sia ben strutturata, bene suddividendo i devices in cartelle e persino sottocartelle e files, che definiscono così delle "gerarchie ad albero". Strumento di gestione di udev è il comando udevadm (una volta "udevinfo"). Il comando "udevadm monitor" mette il vostro pc in attesa, provate in questa fase ad inserire una periferica usb (come una memorietta usb, un mouse o altro) e vedete se viene riconosciuta.

E una volta creato il device node che succede?.. Beh Il riconoscimento dell'hardware in linux non si ferma qui.. Quando ad esempio inserite una memorietta usb nel vostro pc, il kernel la intercetta mediante udev (che ne crea il "node" in /dev), e poi comunica la cosa, mediante D-Bus, a Devicekit (una volta invece la comunicava ad "HAL").

D-bus (e le sue API) è un protocollo IPC (interprocess communication) che permette il passaggio di informazioni tra applicazioni (mediante le librerie libdbus). Tale passaggio di informazioni può avvenire direttamente tra le applicazioni ("peer to peer") o anche attraverso il "D-bus daemon". Fra le applicazioni che ne fanno uso ricordiamo gnome-mount (contiene programmi per il montaggio, smontaggio e l'espulsione di dispositivi di archiviazione. La sua configurazione è modificabile da gconf-editor).

D-bus rimpiazza:
- Bonobo (che era basato sull'architettura di CORBA, uno standard sviluppato da OMG) su Gnome
- DCOP usato in KDE 3 (in sostanza Bonobo, CORBA, DCOP servivano/servono a consentire a software diversi di interoperare e condividere informazioni fra loro anche se si tratta di applicazioni sviluppate con linguaggi di programmazione diversi).

D-bus è fra i progetti di freedesktop.org (un progetto che lavore per risolvere i problemi di incompatibilità fra diverse piattaforme) quindi diciamo che è "cross-desktop" che, tradotto in soldoni, significa che in un certo senso e da questo punto di vista D-bus ha messo daccordo KDE e GNOME, e il che non è un male..

D-bus oggi svolge un ruolo chiave persino nella gestione del filesystem con gvfs.
L'accesso i/o ai files è oggi gestito da GNOME mediante gvfs, che rimpiazza il vecchio gnome-vfs.
GVFS opera mettendo in esecuzione un singolo demone principale (gvfsd) che tiene traccia dei mount GVFS attuali. Ogni mount è eseguito in un demone separato (anche se alcuni mount condividono un processo demone, la maggior parte non lo fa).
Le applicazioni controllano gvfs mediante la libreria "gio" (libgio, parte di glib) che contiene le API (in pratica il "livello di astrazione").
L'interazione coi demoni vari avviene per lo piu mediante D-Bus.
GIO fornisce funzioni per il monitoraggio dei file, per l'IO asincrono e per il completamento dei nomi file.

HAL (Hardware Abstraction Layer), ha rappresentato una tappa evolutiva importantissima: col suo demone hald, in sostanza manteneva un database dei devices connessi al pc in tempo reale (per vederlo bastava installate il pacchetto gnome-device-manager, che aggiungeva l'apposito strumento "device manager" nel menu applicazioni di Gnome. Ll'elenco dei devices si modificava in tempo reale inserendo e disinserendo dispositivi nelle porte USB). HAL forniva inoltre delle API che le applicazioni potevano usare per rilevare i devices, monitorarli, eseguire operazioni su di loro se PolicyKit (sistema di autenticazione) lo consentiva. I processi HAL in esecuzione potevano essere visti col comando ps -eaf | grep hal
Vi domanderete perchè parlare di come vengono gestite le periferiche usb in una guida che parla di audio.. Beh il fatto è che al giorno d'oggi, sempre più spesso, si fa ricorso ad accessori audio o persino vere e proprie schede, che fanno uso di porta usb.

Il mio cat /proc/asound/devices del pc da cui sto scrivendo adesso è:

2: : timer
3: : sequencer
4: [ 0- 6]: digital audio playback
5: [ 0- 6]: digital audio capture
6: [ 0- 0]: digital audio playback
7: [ 0- 0]: digital audio capture
8: [ 0] : control


Subito dopo avere inserito il mio Mixer 8 uscite per porta USB, diventa:

2: : timer
3: : sequencer
4: [ 0- 6]: digital audio playback
5: [ 0- 6]: digital audio capture
6: [ 0- 0]: digital audio playback
7: [ 0- 0]: digital audio capture
8: [ 0] : control
9: [ 1- 0]: digital audio playback
10: [ 1- 0]: digital audio capture
11: [ 1] : control



Inoltre dopo l'inserzione del mixer nuovi devices compaiono nella cartella /dev/snd, a testimonianza del fatto che il mio mixer viene immediatamente visto come scheda audio.

HAL, progetto molto importante, col tempo si è parecchio ingrandito perchè è necessario che le sue capacità di "leggere" l'hardware siano elevate ed accurate (si tratta di un computer che può essere sospeso? puo ibernare? ACPI?), e che le sue API siano efficienti. Alla fine si è reso necessario dividerlo in un insieme di progetti detto Devkit, che sta pian piano prendendo il posto del sempre più grosso monolitico HAL.

DeviceKit numera i devices, li "identifica" e assegna in classificazioni tipo "audio players, cameras" e altro, emette segnali se queste sono aggiunte o rimosse dal pc.

Beh in realtà DeviceKit stesso, neanche il tempo di entrare in scena, ha subito un mare di cambiamenti al punto tale che è difficile ricostruirne la storia.. Esisteva un demone DeviceKit, presto sostituito dalle librerie libudev e libgudev per reperire le informazioni di udev sui devices e sugli eventi (scavalcando D-bus?). In verità quello che sta succedendo è che si sta cercando la massima integrazione possibile tra udev e DeviceKit, prova ne è il fatto che cominciano a condividere insieme librerie fondamentali. Ne vedremo delle belle, ma forse è ancora troppo presto per parlarne, e per il momento vi è una forte confusione tra HAL e DeviceKit, che ancora parzialmente coesistono insieme.

Nel contesto di DeviceKit troviamo:
- upower (ex "DeviceKit-Power"): si occupa del power management del pc (e quindi anche della gestione della batteria di un pc portatile).
- udisks (ex "DeviceKit-disks"): serve a tenere traccia dei devices block ("storage devices", tipo hard-disks e memoriette usb). GNOME vi interagisce mediante un frontend grafico chiamato palimpsest (programma utile a gestire la creazione di filesystems, partizionamenti, encryption, raid e altro) contenuto nel pacchetto gnome-disk-utility. Nello stesso pacchetto vi è anche una estensione di nautilus chiamata nautilus-gdu, che serve a Nautilus per sfruttare proprio DeviceKit-disks.
- udev-extra: fornisce delle regole di funzionamento a udev in modo tale che lo stesso deviceKit possa funzionare. Anche HAL poteva essere "regolato" nel suo funzionamento, creando delle regole in degli appositi files XML con estensione .fdi .


Torna al menù principale di "Audio e Linux"

Descrizioni usate nelle foto: 
Postato da: Etnablog in Linux alle 23:01

Permalink | Commenti(0)
Inserisci commento

Commenti:

Nessun commento. Vuoi essere il primo?
Solo gli utenti registrati possono lasciare commenti
*1 user online
Caricamento pagina: 0.02 s