[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
In generale, per gestire l'«audio» in qualche modo non è strettamente necessario disporre di componenti speciali. Per esempio, il lettore CD-ROM può essere gestito in modo indipendente per ascoltare i CD musicali, eventualmente anche per estrarre le tracce audio (anche se poi mancherebbe la possibilità di ascoltare quanto estratto senza una scheda audio).
Prima ancora di affrontare gli aspetti tecnici legati alla gestione dell'audio in forma digitale, vale la pena di annotare il significato e lo scopo del numero ISRC (International standard recording code), che rappresenta un sistema di identificazione per tutte le registrazioni sonore, comprese quelle che si compongono anche di una parte video.
In pratica, questo numero viene richiesto da chi desidera controllare la diffusione e l'utilizzo di un opera sonora, ottenendo un'attribuzione univoca a una registrazione singola.
Volendo fare un'associazione con le pubblicazioni dei libri, questo numero è l'equivalente del numero ISBN (capitolo 629).
Per maggiori informazioni si può consultare l'indirizzo: <http://www.ifpi.org/site-content/online/isrc_intro.html>.
Esistono diversi modi per arrivare a ottenere la gestione dell'audio con i sistemi GNU/Linux. Con kernel 2.6.* si considera attuale il modello denominato ALSA (Advanced Linux sound architecture, mentre il modello precedente, noto con la sigla OSS (Open sound system), è obsoleto.
Qualunque sia il tipo di gestione dell'audio che si vuole utilizzare, nel caso del sistema GNU/Linux occorre predisporre un kernel con le funzionalità necessarie all'adattatore audio di cui si dispone, possibilmente utilizzando dei moduli. C'è però il problema di scegliere attentamente l'hardware e per ogni situazione si possono presentare degli imprevisti.
Se si intende realizzare un kernel modulare, come viene suggerito qui, occorre poi fare in modo che i moduli relativi vengano caricati opportunamente, soprattutto specificando i parametri necessari a raggiungere correttamente la scheda. A titolo di esempio, nel caso di moduli per OSS, supponendo di disporre di una vecchia scheda SoundBlaster a 8 bit, predisposta per utilizzare l'indirizzo di I/O 22016, il livello di IRQ 5 e il canale DMA 1, si può caricare il modulo relativo con il comando seguente:
#
modprobe sb irq=5 io=0x220 dma=1
[Invio]
In questo modo vengono caricati automaticamente anche i moduli da cui dipende sb.o. Lo si può verificare con lsmod:
#
lsmod
[Invio]
Per verificare che la scheda sia stata riconosciuta correttamente, si può «interpellare» il file di dispositivo /dev/sndstat
, ovvero il file virtuale /proc/sound
:
#
cat /dev/sndstat
[Invio]
#
cat /proc/sound
[Invio]
OSS/Free:3.8s2++-971130 Load type: Driver loaded as a module Kernel: Linux dinkel.brot.dg 2.2.5 #4 SMP lun mag 10 15:02:40 CEST 1999 i586 ... |
In seguito, è possibile sistemare meglio la cosa inserendo nel file /etc/modules.conf
le righe seguenti:
|
Per quanto riguarda il caricamento dei moduli ALSA, il procedimento è analogo. In questo esempio viene caricato il modulo per una scheda PCI EMU10K1:
#
modprobe snd-emu10k1
[Invio]
Per verificare che la scheda sia stata riconosciuta correttamente, si può «interpellare» il file di dispositivo /dev/sndstat
, che però in questo caso corrisponde a /proc/asound/oss/sndstat
:
#
cat /dev/sndstat
[Invio]
#
cat /proc/asound/oss/sndstat
[Invio]
Sound Driver:3.8.1a-980706 (ALSA v1.0.2c emulation code) Kernel: Linux nanohost 2.6.3 #1 Sun Mar 7 13:36:24 CET 2004 i686 Config options: 0 Installed drivers: Type 10: ALSA emulation Card config: Sound Blaster Live! (rev.8) at 0xdc00, irq 5 Audio devices: 0: EMU10K1 (DUPLEX) Synth devices: NOT ENABLED IN CONFIG Midi devices: 0: EMU10K1 MPU-401 (UART) Timers: 7: system timer Mixers: 0: TriTech TR28602 |
Anche per ALSA è bene intervenire nel file /etc/modules.conf
o in altri file da cui il sistema operativo attinge per costruire il primo; tuttavia, per questo occorre verificare prima come è organizzata la propria distribuzione GNU/Linux, per sapere se e dove può essere conveniente mettere le mani.
La complessità di ALSA richiede normalmente la presenza di uno script nella procedura di inizializzazione del sistema, per l'avvio e l'arresto della gestione dell'audio (per esempio /etc/init.d/alsa
). In questo modo, vengono caricati automaticamente i moduli necessari, in base alla configurazione, e così vengono anche creati al volo i file di dispositivo adatti.
I file di dispositivo relativi alle funzionalità audio sono descritti nel file sorgenti_linux/Documentation/devices.txt
, assieme a tutti gli altri. Il documento in questione è precisamente Linux allocated devices, curato da Peter H. Anvin. Quello che segue è l'estratto significativo di questo file, riferito alla gestione di OSS:
|
A titolo di esempio, dovendo creare il dispositivo /dev/audio
, si potrebbe usare il comando seguente:
#
mknod /dev/audio c 14 4
[Invio]
Sono importanti anche i permessi di questi file. In generale dovrebbero appartenere all'utente root e al gruppo audio, oppure sys in sua mancanza. Inoltre, per cominciare potrebbero avere i permessi di lettura e scrittura per tutti gli utenti: 06668.
In seguito è il caso di ridurre i permessi, in modo di abilitare l'accesso alle funzionalità audio solo ad alcuni utenti. |
I file di dispositivo usati da ALSA sono collocati nella directory /dev/snd/
e valgono le stesse considerazioni fatte a proposito dei permessi. La cosa importante da considerare a proposito dei file di dispositivo usati da ALSA è che questi vengono generati automaticamente, attraverso lo script snddevices (potrebbe trattarsi del file /usr/share/alsa-base/snddevices
, o qualcosa di simile). In generale, non è necessario preoccuparsi dell'esistenza di questo snddevices, perché l'infrastruttura ALSA dovrebbe essere organizzata in modo tale da funzionare senza interventi particolari da parte dell'utente; tuttavia, quando si tenta di gestire ALSA al di fuori dei canoni prestabiliti, se mancano questi file di dispositivo, non si può ottenere alcun risultato.
Volendo utilizzare il lettore CD-ROM per ascoltare dei CD audio normali, occorre regolare anche i permessi del dispositivo corrispondente al lettore stesso. In pratica, occorre prendersi cura del dispositivo a cui punta il collegamento simbolico /dev/cdrom
. Questo dispositivo, dal momento che è riferito a un'unità in sola lettura, potrebbe essere accessibile in lettura e scrittura a qualunque utente (a meno che si voglia controllare per qualche motivo). Per questo, di solito si attribuiscono i permessi 06668.
#
chmod 0666 /dev/cdrom
[Invio]
Quando l'elaboratore che dispone di scheda audio è collegato a una rete, potrebbero porsi dei problemi di sicurezza riguardo ai permessi per gli utenti comuni sui file di dispositivo di questa. Infatti, un utente che può accedere all'elaboratore, avrebbe la possibilità di attivare la scheda audio e ascoltare attraverso il microfono, ammesso che questo sia collegato. Nello stesso modo potrebbe attivare il canale della linea in ingresso e così anche tutte le altre fonti disponibili. Pertanto, generalmente, questi file di dispositivo sono sprovvisti del permesso di lettura per gli utenti diversi dal proprietario e dal gruppo di questi file. |
La distribuzione GNU/Linux Red Hat disponeva di un programma che facilitava la configurazione dei moduli per la gestione delle funzionalità audio OSS, provvedendo eventualmente anche a sistemare la configurazione Plug & Play delle schede ISA. Il programma era molto utile, soprattutto perché era in grado di predisporre il file /etc/modules.conf
correttamente, inoltre, ammesso che la scansione Plug & Play si fosse conclusa senza incidenti, si otteneva il file di configurazione /etc/isapnp.conf
corretto (e completo) per la propria scheda audio ISA Plug & Play.
Il programma in questione era Sndconfig e poteva essere disponibile anche in altre distribuzioni GNU/Linux:
sndconfig [--noprobe] [--noautoconfig] |
Se l'eseguibile sndconfig veniva utilizzato senza opzioni, si preparava immediatamente a eseguire una scansione dell'hardware Plug & Play. Eventualmente, questo poteva portare anche al blocco del sistema operativo; pertanto conveniva utilizzare questa verifica solo quando l'elaboratore non stava svolgendo alcuna attività importante (meglio ancora se il livello di esecuzione era quello singolo). Era molto importante che non venisse avviata questa scansione se non c'era alcuna scheda ISA di tipo Plug & Play.
L'opzione --noprobe serviva per evitare che venisse eseguita una scansione Plug & Play. Così era possibile selezionare in modo guidato il tipo di scheda audio e gli indirizzi necessari a gestirla.
L'opzione --noautoconfig serviva per evitare che venisse configurata automaticamente una scheda audio Plug & Play. In questo modo si lasciava all'utilizzatore la scelta dei parametri di configurazione relativi.
La figura 527.5 mostra la maschera di sndconfig con la quale si indicavano le caratteristiche di una vecchia scheda audio SoundBlaster (configurata attraverso ponticelli), in modo che venisse generato il file /etc/modules.conf
più adatto (in questo caso, il file /etc/isapnp.conf
non serviva perché non si trattava di una scheda Plug & Play).
|
Per comprendere meglio il funzionamento di questo programma, ma soprattutto per capire come ci si deve comportare con la configurazione del file /etc/isapnp.conf
, è opportuno dare un'occhiata al capitolo 62, in particolare per quello che riguarda il pacchetto Isapnptools.
Jeff Tranter, The Linux Sound HOWTO
<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>
Madhu Maddy, Alsa-HOWTO
<http://www.alsa-project.org/alsa-doc/alsa-howto/alsa-howto.html>
sorgenti_linux/Documentation/sound/
Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome introduzione_alla_gestione_dell_x0027_audio.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]