Reverse engineering che ho fatto del primo sottosistema audio di Linux nel 1999. Magari a qualcuno può tornare utile per motivi storici. :-)

1. IL LINUX OPEN SOUND SYSTEM
ANTONIO TRINGALI
maggio 1999

2. ii

3. Indice
1 LA SCHEDA AUDIO E OSS 4
1.1 Modello della scheda audio . . . . . . . . . . . . . . . . . . . . . . 4
1.2 L’interfaccia di programmazione di OSS . . . . . . . . . . . . . . 6
1.3 Inizializzazione di OSS . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Gestione degli errori . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 L’exit handler . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.3 Il signal handler . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Scrittura di codice portabile . . . . . . . . . . . . . . . . . . . . . 14
1.5 Anatomia del driver . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 Scrittura sul buffer DMA . . . . . . . . . . . . . . . . . . . 17
1.5.2 Lettura dal buffer DMA . . . . . . . . . . . . . . . . . . . 18
1.6 Schede audio ISA e PCI . . . . . . . . . . . . . . . . . . . . . . . 19
1.7 File system e device file . . . . . . . . . . . . . . . . . . . . . . . . 20
1.8 Le versioni di OSS . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 IL MIXER E LA GESTIONE DEI CANALI 23
2.1 Descrizione di /dev/mixer . . . . . . . . . . . . . . . . . . . . . . 23
2.2 I canali del mixer . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Lettura della configurazione . . . . . . . . . . . . . . . . . 26
2.2.2 Selezione del canale da campionare . . . . . . . . . . . . . 27
2.3 Livelli di volume dei canali . . . . . . . . . . . . . . . . . . . . . . 28
2.4 Dipendenza dall’hardware . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Nuove caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6 Esempio di programma . . . . . . . . . . . . . . . . . . . . . . . . 31
3 CAMPIONAMENTO E RIPRODUZIONE 36
3.1 I device file audio . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Il buffer audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Parametri di campionamento . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Reset dei parametri . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Pause nelle operazioni . . . . . . . . . . . . . . . . . . . . 39
3.4 Il campionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 La riproduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 Il formato audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
iii

4. 3.6.1 Little e big endian . . . . . . . . . . . . . . . . . . . . . . 42
3.6.2 La codifica lineare . . . . . . . . . . . . . . . . . . . . . . 43
3.7 Il tempo reale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7.1 Le capacit` del driver . . . . .
a . . . . . . . . . . . . . . . . 45
3.7.2 Gestione del buffer DMA . . . . . . . . . . . . . . . . . . . 46
3.7.3 I/O non bloccante . . . . . . . . . . . . . . . . . . . . . . 48
3.7.4 La sincronizzazione . . . . . . . . . . . . . . . . . . . . . . 52
3.7.5 Accesso diretto al buffer DMA . . . . . . . . . . . . . . . . 53
3.8 Il full duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9 Uso di coprocessori . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.10 Nuove caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.11 Esempio di programma . . . . . . . . . . . . . . . . . . . . . . . . 59
4 SINTETIZZATORI E MIDI 64
4.1 I device file del sequencer . . . . . . . . . . . . . . . . . . . . . . . 64
4.1.1 I chip sintetizzatori . . . . . . . . . . . . . . . . . . . . . . 65
4.1.2 I sintetizzatori MIDI . . . . . . . . . . . . . . . . . . . . . 66
4.2 Il buffer degli eventi . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 Lettura della configurazione . . . . . . . . . . . . . . . . . . . . . 69
4.3.1 Parametri generali . . . . . . . . . . . . . . . . . . . . . . 70
4.3.2 Le porte MIDI . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4 Predisposizione dei chip sintetizzatori . . . . . . . . . . . . . . . . 72
4.4.1 Caricamento degli algoritmi FM . . . . . . . . . . . . . . . 73
4.4.2 Caricamento delle patch wavetable . . . . . . . . . . . . . 76
4.4.3 Caricamento delle sysex patch . . . . . . . . . . . . . . . . 81
4.5 La temporizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.5.1 La sincronizzazione per /dev/music . . . . . . . . . . . . . 83
4.5.2 La sincronizzazione per /dev/sequencer . . . . . . . . . . . 85
4.6 Output degli eventi . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.6.1 Messaggi di canale . . . . . . . . . . . . . . . . . . . . . . 86
4.6.2 Messaggi di sistema . . . . . . . . . . . . . . . . . . . . . . 89
4.6.3 Controllo della coda degli eventi . . . . . . . . . . . . . . . 91
4.7 Formato degli eventi . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.8 Input degli eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.8.1 Eventi per /dev/music . . . . . . . . . . . . . . . . . . . . 95
4.8.2 Eventi per /dev/sequencer . . . . . . . . . . . . . . . . . . 97
4.9 Nuove caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.9.1 SoftOSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.9.2 OSSlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.10 Esempio di programma . . . . . . . . . . . . . . . . . . . . . . . . 102
iv

5. 5 IL MIDI A BASSO LIVELLO 106
5.1 Descrizione dei device file MIDI . . . . . . . . . . . . . . . . . . . 106
5.2 Lettura dalla porta MIDI . . . . . . . . . . . . . . . . . . . . . . . 107
5.3 Scrittura sulla porta MIDI . . . . . . . . . . . . . . . . . . . . . . 109
5.4 Programmazione della MPU–401 . . . . . . . . . . . . . . . . . . 109
5.5 Esempio di programma . . . . . . . . . . . . . . . . . . . . . . . . 110
A GENERAL MIDI 121
A.1 Timbri strumentali . . . . . . . . . . . . . . . . . . . . . . . . . . 121
A.2 Timbri delle percussioni . . . . . . . . . . . . . . . . . . . . . . . 125
1

6. Sommario
Questo lavoro si propone come tutorial per la programmazione della scheda audio
tramite l’Open Sound System (OSS) per il sistema operativo Linux, ponendo
particolare enfasi sulle strategie di programmazione pi` opportune per la sintesi
u
audio in tempo reale.
Capitolo 1 Si introduce un modello “medio” delle varie schede audio presenti
sul mercato; dopo sono descritte la visione orientata a UNIX che ne ha OSS
(in particolare alla fine descrivendo il funzionamento interno del driver), la
sua inizializzazione e la gestione delle uscite da programma e dei segnali in
un ambiente multiutente e multiprogrammato, con qualche riferimento alla
scrittura di programmi portabili
Capitolo 2 Il mixer gestisce i canali di ingresso/uscita facenti capo alla scheda
audio; ` spiegato come scoprire le capacit` di quest’ultima, selezionare i
e a
canali e regolare i livelli di volume per campionamento e riproduzione
`
Capitolo 3 E spiegato come campionare da un qualsiasi canale del mixer e ripro-
durre i campioni sintetizzati o immagazzinati su un file, eventualmente in
maniera non bloccante
Capitolo 4 Ci si occupa della programmazione ad alto livello, cio` in maniera
e
indipendente dai dispositivi, del chip sintetizzatore interno alla scheda audio
e delle porte MIDI
Capitolo 5 Si tratta della programmazione MIDI a basso livello, cio` a livello
e
di I/O di byte dei messaggi
`
Appendice A E riportata una tabella di corrispondenza fra i preset timbrici
definiti nello standard General MIDI level 1 e i nomi delle patch wavetable
per la Gravis UltraSound

7. INTRODUZIONE ALL’OPEN SOUND SYSTEM
All’inizio degli anni ’90 Hannu Savolainen scrisse la prima versione di un driver
per la scheda audio Sound Blaster 1.5 sotto Minix–386; nel 1992 ne fece il porting
sotto Linux: era nato il Linux Sound Driver (LSD).
Al crescere del numero di versione e delle funzionalit` implementate, nonch´
a e
all’aumentare del numero di porting ad altre variet` di UNIX, il driver cambi`
a o
il nome in VoxWare; sfortunatamente era omonimo della VoxWare Incorporat-
ed, quindi per problemi di copyright per un certo periodo rest` il Temporarily
o
Anonymous Sound Driver (TASD).
Poco dopo la 4Front Technologies, con la collaborazione dello stesso Hannu
Savolainen, svilupp` l’Unix Sound System (USS), avente qualche caratteristica in
o
pi` rispetto al driver freeware e un maggior numero di schede audio supportate;
u
lo stesso Savolainen continuava indipendentemente a sviluppare il driver freeware
(il cui codice sorgente era differente da quello di USS), noto ora come USS/Lite.
In ossequio a POSIX e alla gran variet` di sistemi di tipo UNIX al quale `
a e
stato portato, il nome ` cambiato nuovamente e il driver ` commercializzato dalla
e e
4Front Technologies come Open Sound System, mentre nella versione freeware
` noto come OSS/Free. Di questo Savolainen non mantiene pi` il codice: la
e u
responsabilit` ` passata a Alan Cox dagli inizi del 1998.
ae
D’ora in poi ci si riferir` a questi driver globalmente come OSS, sottinten-
a
dendo che ci` che sar` detto vale per entrambi (evidenziando, ove necessario,
o a
le differenze); la versione assunta come “riferimento” ` la 3.5.4. A seguire dal
e
Capitolo 2, la penultima Sezione di ogni Capitolo elenca le differenze di program-
mazione introdotte dalla versione 3.6 in poi e l’ultima Sezione ospita un breve
programma di esempio in C che illustra le caratteristiche di OSS introdotte nel
Capitolo stesso. Delle chiamate alla libreria di OSS elencate in soundcard.h, si
` scelto di riportare solo quelle pienamente supportate.
e
OSS ` in pratica il primo tentativo di unificare l’architettura di audio digitale
e
per UNIX: alle capacit` di campionamento e riproduzione (piuttosto articolate
a
rispetto a quanto prima disponibile per questo ambiente) sono affiancate le possi-
bilit` del MIDI, con il supporto dell’audio sincronizzato alla riproduzione video.
a
`
E allo stato attuale un insieme modulare di device driver che garantiscono un’in-
terfaccia di programmazione uniforme e compatibile a livello di codice sorgente
per tutte le piattaforme su cui ` stato portato, tanto che per queste ` valido la
e e
quasi totalit` di ci` che ` scritto nel seguito di questo lavoro.
a o e
Una panoramica generica delle caratteristiche supportate sia dall’OSS com-
merciale (OSS/Linux) che da OSS/Free ` la seguente:
e
• supporto di vari formati audio per i campioni (8 e 16 bit signed e unsigned,
8 bit µ–Law e A-Law, IMA–ADPCM)
• supporto di canali stereo e mono
• frequenze di campionamento comprese tra 4kHz e 48kHz
2

8. • supporto half e full duplex (con apposite schede audio)
• possibilit` di accesso diretto al buffer audio DMA (per applicazioni con
a
richieste temporali pi` stringenti, come i giochi)
u
• possibilit` di accesso indipendente dall’hardware a MIDI e a sintetizzatori
a
FM o wavetable sulla scheda audio
• caricamento delle patch in maniera indipendente dall’hardware
• supporto per SMPTE/MTC
• supporto per UART di tipo MP–401, Sound Blaster MIDI e XG MIDI
• supporto di IBM/Motorola PowerPC (bus ISA e PCI), 386/486/Pentium
(bus ISA, EISA e PCI), Sun SPARC e DEC Alpha/AXP (bus ISA e PCI)
Rispetto a OSS/Free, OSS/Linux ha in pi` le seguenti caratteristiche:
u
• supporto diretto dello standard PnP (senza dover inizializzare precedente-
mente le schede con il comando isapnp)
• supporto di un maggior numero di schede audio
• non si deve ricompilare il kernel ad ogni cambio di configurazione o driver
(questo ` un modulo separato)
e
• supporto delle schede Sound Blaster 16/32/64/AWE in full duplex
• supporto delle patch wavetable E–mu SoundFont 2.0
• librerie DirectAudio per l’accesso diretto ai chip sintetizzatori FM e alle
porte MIDI
si ` scelto di non trattare gli ultimi due punti, in quanto di interesse marginale
e
per la sintesi in tempo reale.
CONVENZIONI TIPOGRAFICHE
Per tutto il testo sono seguite per le parole le seguenti convenzioni:
corsivo indica una sigla o un termine tecnico rilevante introdotto per la prima
volta
neretto indica un identificatore o una variabile (con specificato il tipo) per
l’interfaccia di programmazione di OSS o di Linux
spaziatura fissa indica una parola chiave appartenente alla libreria di
OSS o codice sorgente di esempio; se le parole sono contenute tra parentesi an-
golate, come ad esempio per <valore>, si intende che il programmatore debba
sostituirvi un adeguato valore numerico
3

9. Capitolo 1
LA SCHEDA AUDIO E OSS
1.1 Modello della scheda audio
Una scheda audio ha diverse funzioni: converte i suoni immagazzinati nel sistema
(ad esempio, su file) dalla forma digitale all’analogica affinch´ li si possa udire
e
o registrare, converte da opportuni canali di ingresso (Line–In1 , microfono, CD
audio) i segnali da analogico a digitale affinch´ possano essere immagazzinati o
e
manipolati dal computer, pu` consentire essa stessa di creare nuovi suoni tramite
o
eventuali sintetizzatori interni.
Secondo le specifiche MPC2 deve anche essere dotata di una porta MIDI perch´ e
il computer possa controllare strumenti musicali o sintetizzatori esterni con tali
capacit`, invece di generare da s´ i suoni. Il PC diventa in pratica un sequencer,
a e
cio` un direttore d’orchestra allo stato solido; virtualmente non ` pi` di una
e e u
memoria e un sistema di messaggi dalla e alla strumentistica, con capacit` di a
editing.
L’OSS cerca di offrire una visione idealizzata della scheda audio al program-
matore, nascondendo le differenze tecniche fra le varie schede presenti sul mercato;
essa pu` essere vista come un mixer, di cui il programmatore (il Disc Jockey) ha
o
possibilit` di controllare ogni canale3 .
a
Per la riproduzione (conversione D/A) la sorgente ` da file (brano digitaliz-
e
zato o MIDI) o i campioni sono creati con un opportuno algoritmo di sintesi, da
CD audio4 (il segnale ` semplicemente spedito alla sezione analogica della scheda
e
1`
E un ingresso con livelli simili a quelli d’ingresso per un amplificatore HI–FI, utile per
campionare il segnale proveniente da un registratore analogico o da un CD player esterni
2
Specifiche rilasciate da Microsoft e Intel nel 1991 per definire una configurazione hardware
minima affinch´ un computer potesse essere definito “multimediale”: si doveva cio` disporre
e e
almeno di un PC 386SX/16MHz con 4MB di RAM e 40MB di hard disk, una VGA a colori, un
mouse, una scheda audio e un CD–ROM player
3
Indipendentemente o meno dagli altri; relativamente alle capacit` della scheda audio stessa,
a
con il programmatore che pu` interrogare OSS sulle capacit` di quest’ultima
o a
4
Non ` presa in considerazione la programmazione del drive CD in questo tutorial, solo come
e
si fa a campionare o riprodurre il segnale che ` presente sull’eventuale canale CD Audio In della
e
scheda audio
4

10. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.1. MODELLO DELLA SCHEDA AUDIO
audio senza che sia stato campionato prima), da Line–In e da microfono. In cam-
pionamento (conversione A/D) si pu` acquisire dagli ingressi CD Audio, Line–In
o
e microfono o si possono acquisire eventi MIDI.
La coppia di convertitori A/D e D/A viene spesso chiamata PCM, DSP,
CODEC o ADC/DAC ; nella Tabella seguente sono elencate le massime frequenze
di campionamento5 per le varie generazioni di schede audio che OSS supporta (la
minima ` sempre intorno ai 5 kHz); la fc ` generata dividendo l’alta frequenza di
e e
un oscillatore di riferimento, per cui non ` possibile ottenere tutte le frequenze
e
dell’intervallo: le differenze di qualche percento dovrebbero essere ignorate perch´
e
solitamente non avvertibili (OSS cerca di ottenere dalla scheda audio la frequenza
pi` vicina a quella richiesta). La risoluzione di campionamento pu` essere di 8 o
u o
16 bit, in mono o stereo.
Generazione Max fc Note
1a 22.05 kHz in riproduzione
11.025 kHz in campionamento
2a 44.1 kHz mono
22.05 kHz stereo
3a 44.1 kHz qualit` audio CD
a
48 kHz qualit` DAT
a
4a 96 kHz Ultra Hi–Fi
Oltre alle succitate possibilit` di sintesi FM6 e di gestione dei dispositivi MI-
a
DI, alcune schede consentono la wavetable synthesis e la possibilit` di caricare
a
campioni di uno strumento (patch) in una speciale memoria della scheda stessa.
In figura 1.1 ` evidenziata la visione che possiamo dare della nostra scheda
e
audio idealizzata come output mixer per quanto riguarda la riproduzione, che ben
si conf` alle caratteristiche pi` comuni riscontrabili nelle schede audio attualmente
a u
presenti sul mercato (1999). In figura 1.2 ` invece schematizzato l’input mixer a
e
cui fare riferimento per quanto riguarda il campionamento.
Infatti dentro una scheda audio possono esserci realmente due mixer che gestis-
cono separatamente i casi di campionamento e riproduzione, ma OSS gestisce
automaticamente il passaggio dall’uno all’altro in base ai comandi del program-
matore di lettura o scrittura dalla/alla scheda audio. In particolare, se tali attivit`
a
sono implementate dalla scheda audio come mutuamente esclusive ` definita half
e
duplex, mentre ` definita full duplex se possono aver luogo contemporaneamente.
e
5
Alcune vecchie schede permettono di scegliere solo fra frequenze di campionamento fisse:
11025 Hz, 22050 Hz, 32000 Hz e 44100 Hz
6`
E sfruttata la tecnica degli operatori per produrre pi` voci: i chip “classici” sono lo Yamaha
u
OPL–2 (a due operatori, nove voci con timbri non realistici) e OPL–3 (a quattro operatori,
diciotto voci): aumentando il numero di operatori per voce migliora la qualit` della sintesi
a
5

11. 1.2. L’INTERFACCIA DI PROGRAMMAZIONE DI OSS CAPITOLO 1. LA SCHEDA AUDIO E OSS
Memoria del computer
o Hard-Disk
LINE-OUT
ALTOPARLANTI
L R L R L R
L R L R L R L R STEREO MONO
STEREO MONO
TREBLE
BASS
RECORD CD Audio LINE-IN MIC
MASTER DAT CD Audio LINE-IN MIC MIDI ON/OFF
VOLUME ON/OFF ON/OFF ON/OFF
MIDI ON/OFF
VOLUME ON/OFF ON/OFF ON/OFF ON/OFF
Figura 1.1: Modello come mixer della
Figura 1.2: Modello come mixer
scheda audio in riproduzione
della scheda audio in campiona-
mento
1.2 L’interfaccia di programmazione di OSS
Per gestire il “mixer virtuale” delle figure 1.1 e 1.2 OSS sfrutta la visione orientata
al file–system che Linux ha di ogni device 7 . I canali del mixer, campionamento
e riproduzione possono quindi essere gestiti manipolando degli speciali file che
si trovano nella directory /dev tramite le primitive di sistema open(), ioctl(),
read(), write() e close().
In figura 1.3 sono evidenziati i device file relativi alla manipolazione dei vari
canali per la riproduzione, mentre in figura 1.4 c’` lo schema equivalente per il
e
campionamento.
Quest’organizzazione ` conveniente, poich´ in tal modo sono schermate sia le
e e
complessit` dell’hardware e del software sottostante (la scheda audio, ma anche
a
la gestione del DMA, della memoria virtuale e del multitasking), sia le diversit` a
fra le varie schede audio in commercio.
Si pu` ora procedere alla descrizione di ogni device file:
o
/dev/mixer Questa ` l’interfaccia di accesso alle funzioni del mixer e pu`
e o
essere un link simbolico a /dev/mixer0; se ` presente un secondo mixer, ci
e
si riferisce ad esso come /dev/mixer1
/dev/dsp Identifica il DSP della scheda (per default con codifica lineare 8 bit
unsigned) e pu` essere un link simbolico a /dev/dsp0; in genere ` presente
o e
7`
E un’interfaccia a un dispositivo hardware (dischi, linee seriali, etc.) o a “entit`” a cui
a
non corrisponde un vero e proprio dispositivo hardware (memoria di sistema, kernel, etc.); a un
device fisico — come la scheda audio — corrisponde un device driver — come OSS — che ha
il compito di pilotarlo
6

12. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.2. L’INTERFACCIA DI PROGRAMMAZIONE DI OSS
= Link simbolico
OSS driver
OSS driver
Memoria del computer
o Hard-Disk
/dev/dsp /dev/dsp0
/dev/dsp1 MIDI in
/dev/dsp
/dev/dspW /dev/dspW0
/dev/dspW
MIDI file (out) /dev/dspW1
/dev/audio
/dev/audio /dev/audio0
CD Audio /dev/music
/dev/audio1
/dev/sequencer
CD Audio /dev/midi00 Memoria del computer
/dev/midi01 o Hard-Disk
/dev/sndstat
/dev/sndstat /dev/midi02
/dev/sndproc Line-In
/dev/music /dev/sndproc /dev/midi03
Line-In /dev/sequencer
/dev/midi00
/dev/midi01 MIXER
MIXER /dev/midi02
/dev/midi03 Mic
Mic
/dev/mixer /dev/mixer0 /dev/mixer /dev/mixer0
/dev/mixer1 /dev/mixer1
Figura 1.3: Visione della scheda au- Figura 1.4: Visione della scheda
dio in riproduzione che OSS d` al audio in campionamento che OSS
a
programmatore d` al programmatore
a
anche /dev/dsp1, che pu` identificare un secondo DSP o lo stesso con una
o
diversa funzione
/dev/dspW Se presente (dipende dalla versione di OSS), si riferisce al DSP con
codifica lineare 16 bit signed e little endian8 ; pu` essere un link simbolico
o
a /dev/dspW0 ed eventualmente ` presente anche /dev/dspW1
e
`
/dev/audio E presente per limitata compatibilit` con le workstation Sun (non
a
sono supportati cambiamenti da 8 kHz/mono/8 bit) e utilizza la codifica
µ–Law9 ; ` disponibile in mutua esclusione con /dev/dsp e generalmente `
e e
un link a /dev/audio0, potendo essere presente anche /dev/audio1
/dev/music Permette di accedere al sintetizzatore interno alla scheda audio e
alle porte MIDI in maniera indipendente dal dispositivo (sono trattati allo
stesso modo dal punto di vista dell’interfaccia di programmazione), con
modalit` di temporizzazione piuttosto articolate; pu` essere presente il link
a o
simbolico ad esso /dev/sequencer2 (obsoleto)
`
/dev/sequencer E un device file a pi` basso livello di /dev/music, rispetto al
u
quale ha capacit` limitate di temporizzazione, sincronizzazione e gestione
a
automatica del chip sintetizzatore interno alla scheda audio
8
Little endian e big endian si riferiscono a come sono conservati i campioni in memoria dalla
CPU: per il primo l’indirizzo del dato corrisponde all’indirizzo del byte meno significativo (Intel,
Alpha), per il secondo al byte pi` significativo (Motorola, Sparc, PowerPC, HP–PA)
u
9
Un campione a 12 o 16 bit ` compresso logaritmicamente a 8 bit: OSS in riproduzione
e
non effettua l’operazione opposta, ma converte in un campione a 8 bit lineare prima di inviare
al device audio (sono introdotti un overhead per il calcolo e della distorsione); ` un formato
e
derivante dalla tecnologia telefonica digitale
7

13. 1.2. L’INTERFACCIA DI PROGRAMMAZIONE DI OSS CAPITOLO 1. LA SCHEDA AUDIO E OSS
`
/dev/midi00 E un’interfaccia a basso livello al canale MIDI, orientata ai carat-
teri come tty (raw mode) e indirizzata ad applicazioni che non richiedono
una sincronizzazione in tempo reale come i sequencer (pu` essere usata
o
per inviare sysex, per caricare campioni sugli strumenti o per effettuare il
dump dei canali); se presenti, possono essere gestite altre porte MIDI con
/dev/midi01, /dev/midi02 e /dev/midi03
/dev/sndproc Rappresenta l’interfaccia interna di accesso a un eventuale co-
processore presente sulla scheda audio; pu` essere una soluzione tempo-
o
ranea, da eliminare in seguito
/dev/sndstat Questo, a differenza degli altri, ` un device file a sola lettura:
e
stampa informazioni diagnostiche riguardo la configurazione di OSS in for-
ma leggibile agli umani, ma se ne sconsiglia l’utilizzo da parte dei programmi
perch` in futuro il formato delle informazioni da esso fornite potrebbe cam-
e
biare; non ci si far` pi` riferimento d’ora in poi. L’output ha una sezione
a u
per ogni categoria di dispositivi, e questi sono numerati nell’ordine in cui il
driver li inizializza (che non ` fisso, per cui ` meglio non fare assunzioni a
e e
priori); un esempio del suo utilizzo ` il seguente:
e
~>cat /dev/sndstat
Sound Driver:3.5.4-960630
Kernel: Linux papo 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i486
Config options: 0
Installed drivers:
Card config:
Audio devices:
0: Sound Blaster 16 (4.13)
Synth devices:
0: Yamaha OPL-3
Midi devices:
Timers:
0: System clock
Mixers:
0: Sound Blaster
OSS consente di avere pi` schede audio installate nel computer, il che si
u
traduce in un maggior numero di device file indirizzabili, elencati nell’output
8

14. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.3. INIZIALIZZAZIONE DI OSS
di /dev/sndstat: l’esempio sopra rivela che il computer ha solo /dev/dsp0,
ma in generale con pi` DSP li si potrebbe indirizzare operando su /dev/dspn;
u
analogamente per il mixer su /dev/mixern, etc.
1.3 Inizializzazione di OSS
Il minimo insieme di header file da includere ` rappresentato da stdio.h (per le
e
funzioni di libreria tipo printf() e perror()), unistd.h, fcntl.h (per open(),
ioctl(), read(), write() e close()) e sys/soundcard.h (le definizioni vere e
proprie per la libreria di OSS).
Adesso si riporter` uno scheletro di codice C per l’apertura di un device file di
a
OSS (nell’esempio ` /dev/dsp, ma potrebbe essere /dev/mixer, . . . ); nei succes-
e
sivi Capitoli lo si dar` come sottinteso man mano che si introducono le primitive
a
per una gestione vieppi` sofisticata della scheda audio.
u
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/soundcard.h>
int main()
{
int dspfd; /* File descriptor per /dev/dsp */
dspfd = open("/dev/dsp", O_WRONLY); /* Apre il device */
if (dspfd == -1) {
perror("/dev/dsp"); /* Gestione errore */
exit(-1);
}
/* Qui ci puo’ andare tutto il codice per sfruttare il */
/* device file, con le ioctl() necessarie a configurare */
/* il driver poste prima delle read() o write() */
close(dspfd); /* Chiusura del device file */
return 0;
}
Il secondo argomento di open() ` la modalit` di accesso al device file, che nel
e a
caso di OSS pu` essere una fra le seguenti:
o
O RDONLY Accesso in sola lettura (read() o ioctl())
O WRONLY Accesso in sola scrittura (write() o ioctl())
O RDWR Accesso in lettura/scrittura (read(), write() o ioctl())
9

15. 1.3. INIZIALIZZAZIONE DI OSS CAPITOLO 1. LA SCHEDA AUDIO E OSS
Per read() e write() i flag O_NDELAY o O_NONBLOCK, affinch´ le operazioni di
e
I/O sul device file non blocchino il processo chiamante, non hanno effetto: se il
processo effettua una read() e i campioni richiesti non sono ancora disponibili,
questo viene messo in wait finch´ l’operazione ` completata (analogamente con
e e
una write(), se il buffer del driver non ha spazio sufficiente per i campioni che
si vogliono riprodurre).
Per la open() il funzionamento ` sempre del tipo O_NDELAY; se fallisce il
e
file descriptor ` posto uguale a -1 e la macro errno ` impostata a un oppor-
e e
tuno valore (questa ` messa a disposizione del programmatore per mezzo di
e
#include <errno.h>).
1.3.1 Gestione degli errori
I codici di errore pi` comuni riportati da errno sono i seguenti:
u
ENOENT Il device file che si ` tentato di aprire non ` presente in /dev
e e
ENODEV Esiste il device file in /dev, ma il driver non ` stato caricato dal
e
kernel (si pu` controllare con cat /dev/sndstat o dmesg | more)
o
ENOSPC Esiste il device file in /dev, ma il driver non ` stato in grado di
e
allocare la memoria per il buffer DMA tramite sound_mem_init() durante
il boot del sistema; il modulo del driver dovrebbe essere uno dei primi ad
esser caricato dal kernel, in modo da garantire tale operazione anche in caso
di poca memoria installata
ENXIO Esiste il device file in /dev e il driver ` presente nel kernel, ma non
e
esiste il dispositivo hardware che si tenta di indirizzare (ad esempio, perch´
e
la configurazione del driver non corrisponde all’hardware audio)
EINVAL Uno degli argomenti della chiamata a una funzione non ha un valore
valido
EBADF Il file descriptor non si riferisce a un device file aperto, una read() `
e
stata rivolta a un device file aperto con O_WRONLY o una write() ` stata
e
rivolta a un device file aperto con O_RDONLY
EBUSY Solo un processo alla volta pu` gestire /dev/dspn e /dev/audion, per
o
cui si verifica se un altro processo (anche appartenente allo stesso utente)
tenta di accedervi (si verifica anche se l’IRQ o il canale DMA sono occupati);
pu` essere gestito dal programma tentando di riaprire il device file che ha
o
causato l’errore dopo qualche tempo, ma non ` garantito che esso divenga
e
mai disponibile
`
EINTR E ritornato da read() o write() qualora queste siano risultate bloccan-
ti e durante lo stato di wait il processo utente abbia ricevuto un signal()
10

16. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.3. INIZIALIZZAZIONE DI OSS
EAGAIN La risorsa a cui si ` cercato di accedere ` temporaneamente non
e e
disponibile (ad esempio, si ` cercato di scrivere su un buffer pieno o leggere
e
da un buffer vuoto con il device file aperto in O_NONBLOCK)
EACCES Per i device /dev/dspn e /dev/audion l’accesso ` consentito solo al
e
root (a meno che il sistema sia stato configurato in altro modo), e questo
errore si verifica se un utente normale cerca di accedere a tali device file;
questa ` una misura di sicurezza per impedire che, ad esempio, qualora il
e
computer sia connesso in rete e abbia un microfono qualcuno possa ascoltare
remotamente le conversazioni che si svolgono nella stanza ove si trova il
computer
Un error handler un po’ pi` sofisticato potrebbe rassomigliare a:
u
if ((dspfd = open("/dev/dsp2", O_WRONLY)) == -1) {
switch (errno) {
case ENOENT: perror("/dev/dsp2");
exit(-1);
case EBUSY: close(dspfd); /* Aspetta un po’ per riaprire */
sleep(10);
if (dspfd = open("/dev/dsp2", O_WRONLY)) == -1) {
perror("/dev/dsp2");
exit(-1);
}
break;
default: perror("Altro tipo di errore");
fprintf(stderr, "Errore numero: %dn", errno);
exit(-1);
}
}
Per quanto invece riguarda il seguito di questo lavoro, si demander` la gestione
a
degli errori a una semplice routine del tipo:
void errore(const char *msgerr)
{
perror(msgerr);
exit(-1);
}
Sarebbe corretto mettere un error handler non solo dopo una open(), ma an-
che dopo read() o write() per verificare se siano stati letti o scritti il numero
corretto di byte; tuttavia nella sintesi in tempo reale ci` tende a rappresentare
o
cicli di CPU sprecati. Invece dopo una ioctl() conviene controllare quasi ob-
bligatoriamente il valore ritornato dal driver nell’ultimo dei suoi argomenti, per
vedere cosa si riesce a ottenere rispetto a quanto richiesto dal programmatore.
11

17. 1.3. INIZIALIZZAZIONE DI OSS CAPITOLO 1. LA SCHEDA AUDIO E OSS
Un altro buon accorgimento di programmazione ` di installare un exit handler
e
e/o un signal handler subito dopo una open() riuscita: il primo pu` essere utile
o
10
per operazioni di routine alla chiusura del programma (regolare o in seguito a
exit()), il secondo pu` gestire i segnali impostati da altri processi, dal kernel
o
o dal processo stesso. Per una dettagliata descrizione di questi argomenti si
veda [10].
1.3.2 L’exit handler
Un exit handler richiede la funzione di libreria atexit(), disponibile in segui-
to a #include <stdlib.h>. Essa registra le funzioni di tipo void f() date in
argomento come exit handler (max 32), venendo richiamate nell’ordine inverso
rispetto a quello con cui sono state registrate; atexit() restituisce 0 se la regis-
trazione ` stata possibile, altrimenti -1 con errno==ENOMEM (memoria insufficiente
e
per aggiungere la funzione).
Nell’esempio seguente si dimostra l’utilizzo di atexit() chiudendo un device
file all’uscita dal programma (anche se ci` non ` strettamente necessario per
o e
quanto prima affermato):
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/soundcard.h>
int dspfd; /* Variabile globale */
void Messaggio() /* Chiamata per prima */
{
puts("Premi <Invio> per chiudere /dev/dsp...");
getchar();
}
void ChiudiTutto() /* Chiamata per ultima */
{
close(dspfd);
puts("Fine del programma");
}
void errore(const char *msgerr) /* Gestione degli errori */
{
perror(msgerr);
10
Linux svuota i buffer di I/O e chiude automaticamente i device file rimasti eventualmente
aperti prima che il processo termini, tramite librerie a livello utente o tramite kernel
12

18. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.3. INIZIALIZZAZIONE DI OSS
exit(-1);
}
int main()
{
if ((dspfd = open("/dev/dsp", O_RDONLY)) == -1)
errore("/dev/dsp");
if (atexit(ChiudiTutto) == -1) /* Registrata per prima */
errore("ChiudiTutto()");
if (atexit(Messaggio) == -1) /* Registrata per ultima */
errore("Messaggio()");
return 0; /* Uscita dal programma */
}
L’exit handler ` richiamato in seguito ad exit(), abort()11 , return o alla
e
consegna di un segnale la cui azione di default ` di uccidere il processo; l’output
e
del programma sarebbe:
Premi <Invio> per chiudere /dev/dsp...
Fine del programma
Per evitare la chiamata all’exit handler lo standard POSIX.1 (1990) prevede
_exit(), che inoltre evita lo svuotamento dei buffer prima della chiusura dei file.
1.3.3 Il signal handler
Un signal handler funziona in modo molto simile ad un exit handler: previo
#include <signal.h>, si usa la funzione di libreria signal() per registrare delle
funzioni (non di libreria) che hanno il compito di reagire a segnali provenienti da
altri processi o dallo stesso processo12 (rispettivamente generati tramite le funzioni
di libreria kill() e raise()).
In signum.h sono definiti una trentina di segnali che si conformano ad ANSI,
POSIX, System V e BSD 4.2, per i quali esistono delle disposizioni di default
(ci` equivale a signal(<segnale>, SIG_DFL)); se si vuole ignorare un partico-
o
lare segnale si pu` porre nel codice signal(<segnale>, SIG_IGN). La signal()
o
ritorna il valore precedente del signal handler o SIG_ERR se si verifica un errore.
11
Viene impostato un segnale SIGABRT al processo chiamante: non ` ignorabile o bloccabile
e
da un signal handler
12
Un segnale ` definibile come un’interruzione asincrona software nel flusso di un processo:
e
esso ` “impostato” dal processo che lo genera ed ` “consegnato” al processo che lo riceve; il
e e
modo in cui quest’ultimo reagisce al segnale si chiama “disposizione”
13

19. 1.4. SCRITTURA DI CODICE PORTABILE CAPITOLO 1. LA SCHEDA AUDIO E OSS
Per esempio, se si vuole che il processo reagisca a un segnale di interruzione
(SIGINT) e a un segnale di terminazione del programma (SIGTERM) con una
disposizione diversa dalla predefinita, all’inizio di main() si potr` porre:
a
signal(SIGINT, SignalHandler); /* Le funzioni possono essere */
signal(SIGTERM, SignalHandler); /* uguali o diverse */
ove SignalHandler ` una funzione del tipo:
e
void SignalHandler(int segnale) /* Il segnale invocante */
{ /* e’ passato all’handler */
switch (segnale) {
case SIGINT:
case SIGTERM: puts("SIGINT o SIGTERM");
exit(0);
default:
}
}
il processo relativo termina se da shell di comando si digita kill -s SIGINT <PID>
o kill -s SIGTERM <PID>, ove <PID> ` l’identificatore del processo (visualizz-
e
abile tramite il comando ps).
Sono da tenere presenti i seguenti fatti:
• non possono essere variate le disposizioni di SIGKILL e SIGSTOP (signal()
ritorna EINVAL)
• il comportamento di un programma ` indefinito se sono ignorati SIGFPE,
e
SIGILL o SIGSEGV
• ignorare il segnale derivante dalla divisione intera per zero ha un compor-
tamento indefinito, che potrebbe condurre a un blocco del computer
• per certi segnali la disposizione di default implica la terminazione del pro-
cesso e il salvataggio dell’area dati e heap in un file core a fini di debug;
altri provocano la semplice terminazione del processo o sono ignorati
• a differenza di BSD, Linux non ridispone il signal handler a SIG_DFL dopo
la consegna di un segnale
Si veda man 7 signal per una dettagliata descrizione dei segnali e della loro
disposizione di default, e in ogni caso [10] per una gestione pi` sofisticata.
u
1.4 Scrittura di codice portabile
Di seguito sono elencati alcuni consigli per la scrittura di programmi che siano
portabili sotto i vari sistemi operativi per cui sia stato portato anche OSS:
14

20. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.4. SCRITTURA DI CODICE PORTABILE
• Come si vedr` nei successivi Capitoli, conviene usare delle specifiche macro
a
per impostare dei parametri, ad esempio del mixer, tramite ioctl() (queste
schermano i dettagli dell’implementazione dei parametri per le future ver-
sioni del driver); in particolare bisognerebbe controllare se ` adeguato il
e
valore ritornato nell’ultimo argomento (per le chiamate che lo prevedono)
`
• E meglio riferirsi a un link simbolico per un device piuttosto che utilizzare un
riferimento assoluto, ad esempio usando /dev/dsp al posto di /dev/dsp0;
ci` d` flessibilit` all’utente per poter far puntare i link simbolici ad altri
o a a
device file, se questi garantiscono migliori risultati (i programmi dovrebbero
sfruttare i nomi “veri” solo se resi facilmente configurabili)
• Non bisogna sfruttare delle caratteristiche non documentate (in quanto
obsolete — scompariranno in futuro — o non ancora ben testate)
• L’appesantimento di un programma con caratteristiche al di fuori dell’essen-
ziale o con “trucchi” pu` compromettere la compatibilit` del codice con le
o a
future versioni del driver
• Se si utilizza la risoluzione a 16 bit bisogna fare attenzione che la CPU
memorizzi i campioni come il DSP della scheda audio, cio` coincida per
e
entrambi la codifica big endian o little endian; in tal senso bisogna evitare
di accedere ai campioni a 16 bit ciecamente come signed short
• Non bisogna fidarsi delle impostazioni di default di un device (anche perch`
e
potrebbero essere state modificate da un precedente processo); ad esempio,
anche se il default per /dev/dsp ` 8 kHz/8 bit unsigned/mono, molte schede
e
non supportano la frequenza di campionamento di 8 kHz e si corre il rischio
di ottenere solo rumore con le future schede audio a 24 bit; analogamente,
non bisogna assumere per /dev/sequencer il clock di default di 100 Hz
(Linux/Alpha ha un clock di 1024 Hz), mentre non ci sono valori di de-
fault per /dev/music (bisogna sempre impostare per primi i parametri di
temporizzazione)
• Non si devono scrivere programmi che funzionano solo a 16 bit, poich´ molte
e
schede vecchie sono a 8 bit: campioni da 16 bit riprodotti su queste danno
luogo solo a rumore ad alto volume
• Non si deve dare per scontato che per ogni scheda audio ci sia /dev/mixer
(non lo possiedono le pi` vecchie, o quelle non ancora pienamente support-
u
ate, o le schede audio completamente digitali); non tutti i mixer hanno un
controllo di master volume (ma se ce l’hanno bisogna tenere presente che
questo influenza il volume di tutti i canali), inoltre si deve sempre testare
la presenza di un canale prima di cercare di indirizzarlo (ad esempio, non
tutte le schede possiedono un sintetizzatore interno e/o una porta MIDI)
15

21. 1.5. ANATOMIA DEL DRIVER CAPITOLO 1. LA SCHEDA AUDIO E OSS
• Non si deve usare il full duplex senza prima controllare che la scheda audio
supporti tale modalit`a
• I device audio non devono essere tenuti aperti quando non sono richiesti,
altrimenti altri programmi non vi possono accedere; in tal senso un pro-
gramma dovrebbe gestire flessibilmente le situazioni di EBUSY, ad esempio
riprovando ad accedere dopo qualche tempo al device file
1.5 Anatomia del driver
OSS sfrutta il Direct Memory Access (DMA) per trasferire i campioni dalla scheda
audio a un’opportuna area di RAM e viceversa: questa in genere non coincide
con il buffer del processo che li elabora, per cui il driver deve copiare i campioni
dal/al buffer DMA a/da quest’ultimo13 .
Nei PC–compatibili della copia se ne occupa la CPU, dal momendo che il
DMA Controller (DMAC) compatibile Intel 8237 ha dei pesanti limiti: non pu` o
effettuare copie fra le porte di I/O o fra memoria e memoria; inoltre il buffer
DMA deve risiedere al di sotto dei primi 16 MB di RAM per le schede audio
ISA (non per le PCI), poich´ questo ` il limite di indirizzamento del bus, e deve
e e
essere un blocco di memoria non frammentato che inizia e finisce nella stessa
pagina DMA. Quest’ultima ha dimensione di 64 kB per i canali 0÷3 a 8 bit e
128 kB per i canali 5÷7 a 16 bit: ci` rende difficile usare direttamente il buffer
o
locale del processo come buffer DMA con le schede ISA e pi` di 16 MB, poich´
u e
dovrebbe risiedere al di sotto del limite dei 16 MB; tuttavia i nuovi controller nelle
periferiche bypassano l’Intel 8237 completamente (fly–by), per cui in particolari
condizioni si pu` arrivare a mappare il buffer DMA all’interno dell’area dati del
o
processo (ci` ` sempre possibile con le schede PCI).
oe
L’elaborazione dei campioni da parte del processo deve avvenire almeno un
po’ pi` velocemente del ritmo al quale il DMAC trasferisce i campioni, affinch´
u e
non ci siano pause in fase di campionamento o riproduzione. Se ci` si verifica
o
bisogner` usare una frequenza di campionamento inferiore all’attuale, o usare un
a
formato audio pi` “compatto” per i campioni, in modo da ridurre la quantit` di
u a
byte trasferiti dal DMAC.
Linux ha il “problema” di essere multiutente e multiprogrammato, per cui
i processi competono per l’utilizzo della CPU e un processo a pi` alta pri-
u
orit` potrebbe porre il processo che sfrutta i servizi di OSS in stato di wait
a
per diversi ms: in tal modo il tempo che questo ha per elaborare i campioni
13
Alcune schede possono auto–iniziare il trasferimento senza attendere risposta dal driver,
usando il DMAC in modalit` auto–restart (ci` non ` supportato da tutti i sistemi operativi, ad
a o e
esempio da BSD)
16

22. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.5. ANATOMIA DEL DRIVER
diminuisce. In pratica ci deve essere abbastanza spazio nel buffer DMA per
garantire l’operativit` per il tempo di wait14 .
a
OSS gestisce il buffer DMA con la tecnica del multi–buffering: in pratica
questo ` diviso in frammenti di uguale dimensione, per default calcolata dal driver
e
in modo tale che la latenza15 sia attorno a 0.5s per la riproduzione e attorno a 0.1s
per il campionamento. In tal modo ` possibile aumentare la dimensione del buffer
e
senza influire sulla latenza stessa poich´ il DMAC lavora solo su un frammento
e
per volta, mentre l’applicazione legge o scrive sul resto del buffer.
memoria
wait Scheda audio
Kernel
Processo
1111
0000 DMAC
1111
0000
bus ISA o PCI
OSS
buffer audio driver
read() o
write()
buffer DMA
Figura 1.5: Schema di utilizzo del multi–buffering
1.5.1 Scrittura sul buffer DMA
In fase di riproduzione, quando il programma chiama write() per la prima volta
dopo l’apertura del device, si verificano i seguenti eventi:
• il driver programma la scheda audio con i parametri di campionamento
predisposti (risoluzione, numero di canali e frequenza)
• di default ` calcolata la dimensione adeguata per un frammento, se tramite
e
un’opportuna chiamata ioctl() non se ne ` stabilita un’altra
e
• viene iniziato il riempimento del primo frammento del buffer con i dati
passati dalla write()
• se il primo frammento ` stato riempito completamente, il DMAC ne inizia
e
il trasferimento alla scheda audio
14
Alcune schede dispongono di RAM locale per la riproduzione, ma prima che questa possa
avvenire i campioni devono esservi trasferiti (per la Gravis UltraSound ci sono 256 kB per
canale, ovvero sono “coperti” 2.9 s di suono continuo in modalit` 16 bit/stereo/44.1 kHz)
a
15
La latenza ` il tempo che il processo deve aspettare per avere accesso a un frammento
e
in campionamento o perch´ questo venga suonato in riproduzione quando il buffer ` pieno;
e e
essa dipende dal data rate, che ` la quantit` di dati che il DMAC deve trasferire nell’unit` di
e a a
tempo (per esempio, con un campionamento 16 bit/stereo/44.1 kHz il data rate ` 2 · 2 · 44.1 =
e
176.4 kB/s), nonch´ dalla dimensione del frammento
e
17

23. 1.5. ANATOMIA DEL DRIVER CAPITOLO 1. LA SCHEDA AUDIO E OSS
• il driver copia il resto dei dati nel buffer, eventualmente riempiendo altri
frammenti; se tutti i frammenti del buffer sono stati riempiti il processo
relativo al programma che ha chiamato la write() ` messo in stato di wait
e
finch´ non ` libero almeno un frammento (condizione di overrun)
e e
Alle successive chiamate di write() i dati sono immagazzinati nel buffer
secondo la disponibilit` di frammenti liberi.
a
L’overrun si verifica normalmente per un processo che scriva i campioni nel
buffer pi` velocemente di quanto vengano riprodotti. Se al contrario il processo
u
` leggermente pi` lento a scrivere i campioni rispetto alla velocit` con la quale
e u a
sono riprodotti si verifica la condizione di underrun, per uno dei seguenti motivi:
• l’applicazione ` troppo lenta nell’elaborazione dei campioni (perch´ la CPU
e e
` troppo lenta rispetto al data rate richiesto o ci sono troppi processi in
e
esecuzione che competono per la CPU)
• ci sono leggere variazioni nel tempo di CPU ricevuto (un’applicazione gen-
eralmente ben funzionante pu` occasionalmente andare in underrun)
o
• l’applicazione tenta di lavorare troppo in tempo reale (frammenti pi` piccoli
u
decrescono la latenza, tuttavia bisogna sempre scrivere altri campioni prima
che il buffer si svuoti)
Un underrun provoca in genere un difetto udibile nel segnale riprodotto: pu`o
essere una breve pausa, un “click” o la ripetizione di una parte del segnale
(looping); se quest’ultima si verifica con frequenza uniforme si avvertir` un tono
a
sovrapposto al segnale riprodotto, con frequenza pari a quella con cui si verifica
l’underrun.
1.5.2 Lettura dal buffer DMA
In fase di campionamento, quando il programma chiama read() per la prima
volta dopo l’apertura del device, si verificano i seguenti eventi:
• il driver programma la scheda audio con i parametri di campionamento
predisposti (risoluzione, numero di canali e frequenza)
• di default ` calcolata la dimensione adeguata per un frammento, se tramite
e
un’opportuna chiamata ioctl() non se ne ` stabilita un’altra
e
• sono attivati il processo di campionamento da parte della scheda audio e il
trasferimento dei campioni nel primo frammento del buffer
• il processo ` messo in wait finch´ non ` riempito un numero di frammenti
e e e
che forniscono globalmente una quantit` di campioni maggiore o uguale a
a
quella richiesta
18

24. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.6. SCHEDE AUDIO ISA E PCI
• i campioni richiesti sono copiati nel buffer del processo; gli eventuali cam-
pioni in pi` rimangono nel buffer DMA
u
Le read() successive funzionano come sopra, senza che sia necessario ripredis-
porre la scheda audio.
Un overrun in campionamento si verifica se il buffer ` completamente riempito:
e
in tal caso gli ulteriori campioni sono scartati; le ragioni per cui si verifica sono
simili a quelle per cui si verifica in riproduzione.
1.6 Schede audio ISA e PCI
L’approccio seguito in questo lavoro ` di essere il pi` indipendenti possibile dal-
e u
l’hardware, in modo da poter creare dei programmi che girino su ogni piattaforma
per cui ` stato portato OSS con tutt’al pi` una semplice ricompilata del codice
e u
sorgente. Tuttavia si vogliono elencare i motivi per i quali le schede audio PCI
sono superiori alle schede audio ISA (al di l` della qualit` audio); al momento in
a a
cui si scrive (1999) la quasi totalit` delle schede audio in commercio sono PCI, ma
a
fino a un anno fa erano quasi tutte ISA: un musicista professionista dovrebbe pren-
dere in considerazione l’acquisto di una scheda audio PCI, anche se attualmente
OSS non supporta del tutto le nuove caratteristiche, come l’audio 3D.
Si elencheranno ora le differenze fra ISA e PCI pertinenti le schede audio:
• Il bus ISA ha un clock nominale di 8 MHz, il che darebbe un throughput
teorico di 16 MB/s; in realt`, a causa di overhead vari nella gestione dei seg-
a
nali, nonch´ il fatto che sono richiesti due cicli di clock per il trasferimento
e
dei dati, il throughput si aggira attorno ai 5 MB/s. Se si guarda la quantit` a
di dati da trasferire per una scheda che campiona a 16 bit/stereo/44.1 kHz
(circa 176 kB/s) questo throughput appare adeguato, ma si pu` verificare
o
che il DMA blocchi l’accesso della CPU al bus durante il trasferimento dei
campioni o se la richiesta d’interrupt ` occupata (con ISA le IRQ non sono
e
condivisibili), il che pu` causare click nel suono in sistemi pesantemente
o
caricati. La capacit` di indirizzamento massima per ISA ` di 16 MB, per
a e
cui sono difficilmente applicabili le tecniche di allocazione del buffer DMA
nel buffer del processo, che dovrebbe risiedere al di sotto di tale limite anche
per sistemi con pi` RAM. Pu` inoltre risultare difficile la configurazione di
u o
una scheda audio, soprattutto con OSS/Free se ` PnP.e
• Le specifiche PCI 2.1 consentono un clock sul bus fino a 66 MHz, con un
throughput teorico di 264 MB/s, mentre in pratica ci si aggira intorno ai
108 MB/s; con un clock sul bus di 33 MHz questi valori si dimezzano. Gli
interrupt sono condivisibili, per cui con la tecnica dell’interrupt binding, se
si verificano pi` interrupt contemporaneamente, questi vengono raggrup-
u
pati e serviti in base alla priorit` (e Linux distingue fra fast interrupt —
a
quelli che richiedono un salvataggio del contesto parziale, come la richiesta
19

25. 1.7. FILE SYSTEM E DEVICE FILE CAPITOLO 1. LA SCHEDA AUDIO E OSS
di un servizio DMA — e gli interrupt normali, con salvataggio completo del
contesto — riducendo in tal modo l’overhead). Il PCI consente il busmas-
tering multiplo (con due busmaster), ovvero due arbitri nella gestione del
bus, il che si traduce nell’accesso contemporaneo di CPU e DMA al bus se
le aree di memoria interessate non coincidono; l’indirizzamento ` a 32 bit,
e
per cui sono applicabili le tecniche di allocazione del buffer DMA nel buffer
`
del processo. E inoltre pi` semplice la configurazione delle periferiche PCI,
u
in quanto dopo il boot queste negoziano fra loro, in pratica autoallocandosi.
Queste ed altre considerazioni, come la tendenza delle nuove schede audio
ad incrementare la frequenza di campionamento, spingono a concludere che una
scheda audio PCI pu` risultare fino a dieci volte pi` efficiente di una scheda ISA.
o u
1.7 File system e device file
Come si ` avuto occasione di affermare precedentemente, OSS ` un driver che
e e
fornisce al programmatore la possibilit` di gestire audio e MIDI tramite opportuni
a
device file inseriti nella struttura dell’albero monolitico del file system di Linux.
Ogni device file ` caratterizzato da un major number e da un minor number : il
e
primo ` utilizzato come indice in una tabella del kernel per identificare il tipo
e
di driver che deve gestire un dispositivo hardware, il secondo ` passato al driver
e
stesso per identificare l’unit` su cui agire (classe del device).
a
In Linux il major number per OSS ` 14, ma per altri sistemi operativi potrebbe
e
essere diverso. Il minor number pu` essere codificato tramite un solo byte: in
o
tal caso, come da figura 1.6, i quattro bit meno significativi identificano la classe
del dispositivo, mentre i quattro bit pi` significativi identificano un dispositivo
u
all’interno di una stessa classe; ne consegue che ci possono essere fino a sedici
dispositivi dello stesso tipo per ogni classe.
Tipo device Classe
mixer 0
sequencer 1
midi 2
7 4 3 0
dsp 3
num. device classe audio 4
dspW 5
1 byte
sndstat 6
riservato 7
music 8
sndproc 9
Figura 1.6: Codifica del minor number di un device file di OSS
20

26. CAPITOLO 1. LA SCHEDA AUDIO E OSS 1.8. LE VERSIONI DI OSS
Ad esempio, /dev/midi00 identifica il primo dispositivo di classe 2 (MIDI),
per cui ` il numero del device ` 0: ci` implica che il minor number per il device file
e e o
relativo ` 0x02 (2 in decimale). Analogamente per /dev/midi01 il minor number
e
per il device file relativo sar` 0x12 (18 in decimale), per /dev/midi02 sar` 0x22
a a
(34 in decimale) e per /dev/midi03 sar` 0x32 (50 in decimale).
a
Anche se nelle odierne distribuzioni di Linux non ci dovrebbero essere problemi
del genere, se un device file dovesse mancare ` possibile crearlo effettuando il login
e
come root e dando il seguente comando:
mknod -m <permessi> <nome device file> c 14 <classe del device>
ad esempio, il nome del device file potrebbe essere /dev/music e la classe sarebbe 8;
<permessi> ` un numero ottale che predispone i permessi di accesso al file, che
e
pu` essere posto pari a 666 per accesso in lettura/scrittura da parte di tutti gli
o
utenti (vedere man chmod).
1.8 Le versioni di OSS
Il riconoscimento della versione di OSS in uso varia secondo che si stia utilizzando
una versione precedente o successiva alla 3.6. Ad esempio, la versione 3.5.4 di
soundcard.h definisce le seguenti macro:
#define SOUND_VERSION 350
#define UNIX_SOUND_SYSTEM
mentre nella versione 3.8.2 sono definite le seguenti altre macro:
#define SOUND_VERSION 0x030802
#define OPEN_SOUND_SYSTEM
SOUND_VERSION contiene il numero di versione, con formato che varia secondo che
sia definito UNIX_SOUND_SYSTEM o OPEN_SOUND_SYSTEM.
Dalla versione 3.6 in poi ` possibile usare il seguente frammento di codice, che
e
interroga direttamente il driver per ricavare il numero di versione (` pi` affidabile
e u
che ricavarlo da SOUND_VERSION):
int versione;
if (ioctl(dspfd, OSS_GETVERSION, &versione) == -1) {
/* Versione precedente alla 3.6: errno==EINVAL */
}
Il seguente frammento di codice ricava i numeri di versione e release indipen-
dentemente dalla versione di OSS utilizzata:
int versione, release1, release2, tmpver;
#ifdef UNIX_SOUND_SYSTEM
21

27. 1.8. LE VERSIONI DI OSS CAPITOLO 1. LA SCHEDA AUDIO E OSS
versione = SOUND_VERSION / 100;
release1 = (SOUND_VERSION - versione*100) / 10;
release2 = SOUND_VERSION - versione*100 - release1*10;
#else /* e’ definito OPEN_SOUND_SYSTEM */
if (ioctl(dspfd, OSS_GETVERSION, &tmpver) == -1)
errore("OSS_GETVERSION");
versione = (tmpver & 0x00ff0000) >> 16;
release1 = (tmpver & 0x0000ff00) >> 8;
release2 = tmpver & 0x000000ff;
#endif
22

28. Capitolo 2
IL MIXER E LA GESTIONE
DEI CANALI
2.1 Descrizione di /dev/mixer
Non tutte le schede audio possiedono un mixer: nella fattispecie possono non
averlo le schede pi` vecchie, quelle non ancora pienamente supportate, quelle
u
professionali e le completamente digitali. Anche se il mixer ` mancante si pu`
e o
sempre aprire /dev/mixer, ma un’eventuale ioctl() ritorna errno==ENXIO.
Nella Sezione 1.3 si ` fornito uno scheletro di codice C per l’apertura e la
e
chiusura di un device file; si ` scritto che fra la open() e la close() di questo
e
ci possono essere delle read(), write() o ioctl(). /dev/mixer ` un device file
e
atipico, in quanto non accetta operazioni di read() o write() e l’unica primitiva
utilizzabile ` ioctl(): infatti il mixer svolge solo un lavoro di gestione dei canali
e
cambiando la configurazione della scheda audio, praticamente non impiegando
risorse di calcolo per operare.
A differenza di /dev/dsp e /dev/audio, pi` di un processo alla volta pu`
u o
aprire /dev/mixer; generalmente si usa O_RDONLY come argomento di open().
Le modifiche effettuate alla configurazione del mixer permangono anche dopo
la chiusura dell’ultimo processo modificante, fino a quando un eventuale altro
processo non effettuer` nuovi cambiamenti o fino al reboot del computer. All’atto
a
del boot ` il kernel che si occupa di configurare la scheda audio con dei valori
e
di default ragionevoli, ma che non dovrebbero comunque essere dati per scontati
per non creare programmi inaffidabili.
Solo per il primo mixer, l’uso delle ioctl() per /dev/mixer su questo o su un
altro device di OSS sono equivalenti: ad esempio, se si ` aperto /dev/sequencer `
e e
inutile aprire anche /dev/mixer per variare la configurazione della scheda audio,
basta usare gli ioctl() che si sarebbero utilizzati col secondo direttamente col
primo.
`
E importante verificare le capacit` del mixer prima di usarne i canali, in mo-
a
do da creare programmi che siano portabili per quasi tutte le schede audio. Le
23

29. 2.2. I CANALI DEL MIXER CAPITOLO 2. IL MIXER E LA GESTIONE DEI CANALI
differenze di comportamento riscontrate dovrebbero essere indicate nella docu-
mentazione, evitando descrizioni troppo specifiche nei confronti dei canali, che
possono avere caratteristiche diverse con schede diverse.
2.2 I canali del mixer
Per i canali del mixer ci si pu` rifare alla metafora delle figure 1.1 e 1.2, per cui
o
un canale identifica la classe del dispositivo (CD, microfono, . . . ) che a questo
` connesso; il programmatore pu` effettuarne la selezione per la riproduzione o
e o
il campionamento, regolandone il livello di volume (se il dispositivo ` stereo ci
e
sono due livelli di volume indipendentemente controllabili, il che consente di real-
izzare il balance). Il volume principale pu` essere mancante (Gravis UltraSound,
o
Microsoft Sound System).
Sono definiti SOUND_MIXER_NRDEVICES canali, a cui ` associato un numero da
e
0 a SOUND_MIXER_NRDEVICES-1; un programma non dovrebbe cercare di accedere
a numeri di canale superiori a quest’ultimo.
OSS mette a disposizione del programmatore dei nomi simbolici per ogni
canale; quelli definiti in soundcard.h versione 3.5.4 si trovano nella tabella della
prossima pagina.
Ad ogni canale ` associato un int, nella cui rappresentazione in binario (bit-
e
mask ) ` posto a 1 il bit di posizione corrispondente al numero del canale; le
e
bitmask sono utili con i comandi di gestione della configurazione del mixer.
Sempre in soundcard.h sono definiti dei nomi simbolici da dare ai canali
tramite le macro:
#define SOUND_DEVICE_LABELS {"Vol ", "Bass ", "Trebl", "Synth",
"Pcm ", "Spkr ", "Line ",
"Mic ", "CD ", "Mix ", "Pcm2 ",
"Rec ", "IGain", "OGain",
"Line1", "Line2", "Line3"}
#define SOUND_DEVICE_NAMES {"vol", "bass", "treble", "synth",
"pcm", "speaker", "line", "mic",
"cd", "mix", "pcm2", "rec", "igain",
"ogain", "line1", "line2", "line3"}
la differenza fra i due ` che il primo formato ` adatto per la stampa dei nomi a
e e
video quali etichette dei canali, mentre del secondo formato ` pi` adatto l’utilizzo
e u
quando i nomi dei device audio sono forniti sulla riga di comando di una shell.
24

30. CAPITOLO 2. IL MIXER E LA GESTIONE DEI CANALI 2.2. I CANALI DEL MIXER
Nomi dei canali Bitmask associate Descrizione
SOUND_MIXER_VOLUME SOUND_MASK_VOLUME Livello volume principale
SOUND_MIXER_BASS SOUND_MASK_BASS Regolazione toni bassi principale
SOUND_MIXER_TREBLE SOUND_MASK_TREBLE Regolazione toni acuti principale
SOUND_MIXER_SYNTH SOUND_MASK_SYNTH Livello di uscita sintetizzatore
interno (FM, wavetable); per alcune
schede ne controlla anche il livello
di campionamento
SOUND_MIXER_PCM SOUND_MASK_PCM Livello di uscita di /dev/dsp
e /dev/audio
SOUND_MIXER_SPEAKER SOUND_MASK_SPEAKER Livello di uscita del segnale
all’altoparlantino nel PC (se
connesso alla scheda audio);
su altre schede pu` essere un
o
generico ingresso mono con
qualche altra funzione
SOUND_MIXER_LINE SOUND_MASK_LINE Livello di ingresso per Line–In
SOUND_MIXER_MIC SOUND_MASK_MIC Livello del segnale microfonico in
campionamento o inviato a cuffie e
Line–Out; qualche volta il microfono
non ` connesso a questo canale, ma
e
a un line level input della scheda
SOUND_MIXER_CD SOUND_MASK_CD Livello del CD Audio–In
SOUND_MIXER_IMIX SOUND_MASK_IMIX Recording monitor campionamento;
durante tale fase, su alcune schede
controlla il volume delle cuffie
SOUND_MIXER_ALTPCM SOUND_MASK_ALTPCM Livello di un DSP secondario; nella
Pro Audio Spectrum 16 ` il canale
e
dell’emulazione della Sound Blaster
SOUND_MIXER_RECLEV SOUND_MASK_RECLEV Livello di campionamento per tutti
i canali (nella Sound Blaster 16 si
hanno solo quattro livelli possibili)
SOUND_MIXER_IGAIN SOUND_MASK_IGAIN Livello di guadagno di ingresso
SOUND_MIXER_OGAIN SOUND_MASK_OGAIN Livello di guadagno di uscita
SOUND_MIXER_LINE1 SOUND_MASK_LINE1 Canale generico 1 (aux1); i codec
AD1848 e compatibili hanno tre
line level input a cui diversi
costruttori assegnano funzioni
diverse, per cui tali nomi si
usano quando il significato preciso
di un canale fisico ` sconosciuto
e
SOUND_MIXER_LINE2 SOUND_MASK_LINE2 Canale generico 2 (aux2)
SOUND_MIXER_LINE3 SOUND_MASK_LINE3 Canale generico 3 (line)
25

31. 2.2. I CANALI DEL MIXER CAPITOLO 2. IL MIXER E LA GESTIONE DEI CANALI
Se in un programma si effettuano le assegnazioni:
const char *nome_canale[] = SOUND_DEVICE_LABELS;
const char *nome_cmline[] = SOUND_DEVICE_NAMES;
allora, ad esempio, nome_canale[SOUND_MIXER_CD] corrisponde a “CD ”, men-
tre nome_cmline[SOUND_MIXER_CD] corrisponde a “cd”.
Il mixer consente la selezione dei canali da cui effettuare il campionamento,
che per buona parte delle schede avviene in mutua esclusione.
Il canale di default dopo il boot ` quello del microfono, ma non dovrebbe
e
essere dato per scontato, poich´ il driver non altera le predisposizioni del mixer
e
a meno di un comando da programma; un qualche altro processo dopo il boot
potrebbe averle modificate, con tali modifiche che permangono anche dopo la sua
terminazione.
L’insieme di canali disponibili non ` fisso, ma dipende dalla scheda audio; si
e
pu` verificare che ai canali dello stesso chip mixer costruttori diversi assegnino
o
funzioni diverse, per cui bisogner` verificarne caso per caso il reale significato.
a
Sarebbe meglio non includere funzionalit` di mixer nei programmi se si vuole
a
la massima portabilit` del proprio codice, demandandole a programmi specializ-
a
zati per le varie schede audio. Nel caso si volesse realizzare un tale programma
mixer bisogna ben documentare le sue capacit` se ` sviluppato per una precisa
a e
scheda, altrimenti ` meglio evitare di essere troppo specifici nella documentazione
e
per non trarre in inganno gli utenti: potrebbero credere che la propria scheda
audio sia diversa da come ` realmente, basandosi su ci` che il programma fa
e o
vedere.
2.2.1 Lettura della configurazione
Come ` stato visto sopra, converrebbe effettuare il controllo sia delle capacit`
e a
della scheda audio che dell’esistenza o meno dei canali di interesse prima di in-
traprendere qualsiasi altra azione; un’operazione di ioctl() fallita (ad esempio,
perch´ il canale non esiste) ritorna -1 e errno==EINVAL.
e
Per effettuare la lettura della configurazione dei canali del mixer il codice `
e
simile per tutti i comandi a disposizione:
int bitmask;
if (ioctl(mixfd, SOUND_MIXER_READ_****, &bitmask) == -1) {
/* Il mixer e’ mancante - errno==ENXIO */
}
ove SOUND_MIXER_READ_**** ` l’identificatore del comando di lettura che ritorna
e
in bitmask una maschera di bit; questa pu` essere esaminata per determinare le
o
capacit` di un canale o del mixer in base al comando dato.
a
26

32. CAPITOLO 2. IL MIXER E LA GESTIONE DEI CANALI 2.2. I CANALI DEL MIXER
Per i canali il controllo si pu` effettuare con:
o
if (bitmask & (1 << numero_canale)) {
/* Il canale possiede la capacita’ in esame */
}
ove numero_canale ` un intero tra 0 e SOUND_MIXER_NRDEVICES-1 o il nome
e
mnemonico del canale; al posto di (1 << numero_canale) si pu` utilizzare di-
o
rettamente la bitmask ad esso associata.
I comandi a disposizione per la lettura della configurazione sono:
Comandi Richiesta a OSS
SOUND_MIXER_READ_DEVMASK Quali canali sono presenti?
SOUND_MIXER_READ_STEREODEVS Quali canali sono stereo?
SOUND_MIXER_READ_RECMASK Quali sono i canali campionabili?
SOUND_MIXER_READ_RECSRC Qual ` il canale campionabile attivo?
e
SOUND_MIXER_READ_CAPS Si pu` campionare solo un canale per volta?
o
Con l’ultimo comando si testa se si possono campionare i canali solo in mutua
esclusione; il controllo si effettua con:
if (bitmask & SOUND_CAP_EXCL_INPUT) {
/* Campionamento solo in mutua esclusione */
}
La differenza fra SOUND_MIXER_READ_RECMASK e SOUND_MIXER_READ_RECSRC
` che il primo comando ritorna una bitmask con un bit a 1 per ogni canale per
e
cui la scheda audio possiede la capacit` di campionamento, mentre il secondo
a
ritorna una bitmask con un bit a 1 per ogni canale attualmente selezionato per
il campionamento (se questo ` possibile in mutua esclusione solo un bit in tutta
e
la bitmask pu` essere a 1).
o
2.2.2 Selezione del canale da campionare
Per selezionare il canale da cui campionare basta il seguente frammento di codice:
int bitmask = SOUND_MASK_****;
if (ioctl(mixfd, SOUND_MIXER_WRITE_RECSRC, &bitmask) == -1) {
/* Non c’e’ il mixer o il canale */
/* errno==ENXIO oppure EINVAL */
}
ove SOUND_MASK_**** ` la bitmask associata al canale desiderato.
e
Nel caso fosse possibile campionare da pi` canali contemporaneamente, li si
u
seleziona ponendo in bitmask un OR aritmetico delle bitmask associate ai canali;
ad esempio, per selezionare il campionamento simultaneo da CD e da microfono:
27

33. 2.3. LIVELLI DI VOLUME DEI CANALI CAPITOLO 2. IL MIXER E LA GESTIONE DEI CANALI
bitmask = SOUND_MASK_CD | SOUND_MASK_MIC;
Se nessun bit ` posto a 1 (bitmask==0x00000000), il driver seleziona il canale
e
del microfono.
2.3 Livelli di volume dei canali
Le schede audio rappresentano il livello di un canale con un numero di bit vari-
abile: 3, 8 e anche 16 bit. L’architettura di OSS svincola il programmatore dalla
conoscenza dei livelli assoluti di volume introducendo una rappresentazione in
percentuale: il volume di un canale pu` variare fra 0 (spento) e 100 (massimo);
o
se il canale ` stereo si hanno due di queste percentuali, che possono essere uguali
e
o meno per realizzare il balance.
Per leggere il livello attuale di volume per un canale si sfrutta il seguente
frammento di codice:
int volume;
if ((ioctl(mixfd, MIXER_READ(numero_canale), &volume) == -1) {
/* Non c’e’ il mixer o il canale */
/* errno==ENXIO oppure EINVAL */
}
ove numero_canale ` un numero compreso tra 0 e SOUND_MIXER_NRDEVICES-1,
e
oppure il nome mnemonico del canale. Al posto di MIXER_READ(numero_canale)
si pu` utilizzare anche SOUND_MIXER_READ_****, con **** nome del canale; ad
o
esempio, per il microfono ` SOUND_MIXER_READ_MIC.
e
Il volume ` codificato come in figura 2.1: se il dispositivo ` stereo la codifica dei
e e
canali destro e sinistro si trova nella parola meno significativa di volume (intero
a 32 bit); i 16 bit della parola pi` significativa sono indefiniti e dovrebbero essere
u
ignorati. Nel byte pi` significativo della LSW c’` il volume del canale destro, nel
u e
byte meno significativo il volume del canale sinistro; per i canali mono ` valido
e
solo il byte meno significativo, essendo l’MSB posto uguale all’LSB dal driver.
31 16 15 8 7 0
XXXXXXXX Destro Sinistro
MSW MSB LSB
(da ignorare)
LSW
Figura 2.1: Rappresentazione del volume di un canale stereo
28

34. CAPITOLO 2. IL MIXER E LA GESTIONE DEI CANALI 2.4. DIPENDENZA DALL’HARDWARE
Per estrarre il volume dei canali destro e sinistro si possono sfruttare le
seguenti linee di codice:
int volume, vol_sinistro, vol_destro;
vol_sinistro = volume & 0x000000ff;
vol_destro = (volume & 0x0000ff00) >> 8;
Inversamente, per costituire una parola di volume:
int volume;
volume = (vol_destro << 8) | vol_sinistro;
Per cambiare il volume si utilizza il seguente frammento di codice:
int volume = <valore>;
if ((ioctl(fd, MIXER_WRITE(numero_canale), &volume) == -1) {
/* Non c’e’ il mixer o il canale */
/* errno==ENXIO oppure EINVAL */
}
ove numero_canale ` un numero compreso tra 0 e SOUND_MIXER_NRDEVICES-1,
e
oppure il nome mnemonico del canale. Al posto di MIXER_WRITE(numero_canale)
si pu` utilizzare anche SOUND_MIXER_WRITE_****, con **** nome del canale; ad
o
esempio, per il CD ` SOUND_MIXER_WRITE_CD.
e
Dopo il cambiamento bisognerebbe verificare se il livello ritornato in volume
risulta di proprio gradimento, dal momento che ` di solito pi` piccolo di quanto
e u
richiesto; sequenze di scrittura/lettura ripetute (senza cambiare tale variabile)
`
possono portare al suo azzeramento. E conveniente effettuare la predisposizione
del volume durante l’inizializzazione del programma, ignorando poi il volume
ritornato in seguito.
2.4 Dipendenza dall’hardware
Per ottenere dal mixer il nome della scheda audio si pu` utilizzare il seguente
o
frammento di codice:
mixer_info info;
if ((ioctl(fd, SOUND_MIXER_INFO, &info) == -1) {
/* Non c’e’ il mixer - errno==ENXIO */
}
ove mixer_info ` una struct cos` composta:
e ı
char id[16 ] identificatore della scheda audio (in genere un paio di caratteri)
char name[32 ] nome per esteso della scheda
Ecco un output di esempio per SOUND_MIXER_INFO con una scheda Sound
Blaster 16:
SB
Sound Blaster
29

35. 2.5. NUOVE CARATTERISTICHE CAPITOLO 2. IL MIXER E LA GESTIONE DEI CANALI
2.5 Nuove caratteristiche
In questa Sezione ci si occuper` di descrivere le nuove caratteristiche di OSS
a
riguardanti il mixer introdotte dalla versione 3.6 in poi.
• ` stata implementata la possibilit` di gestire dei canali in pi` :
e a u
Nomi dei canali Bitmask associate Descrizione
SOUND_MIXER_DIGITAL1 SOUND_MASK_DIGITAL1 Ingresso digitale 1
SOUND_MIXER_DIGITAL2 SOUND_MASK_DIGITAL2 Ingresso digitale 2
SOUND_MIXER_DIGITAL3 SOUND_MASK_DIGITAL3 Ingresso digitale 3
SOUND_MIXER_PHONEIN SOUND_MASK_PHONEIN Ingresso livello fono
SOUND_MIXER_PHONEOUT SOUND_MASK_PHONEOUT Uscita livello fono
SOUND_MIXER_VIDEO SOUND_MASK_VIDEO Ingresso audio per video/TV
SOUND_MIXER_RADIO SOUND_MASK_RADIO Ingresso radio
SOUND_MIXER_MONITOR SOUND_MASK_MONITOR Volume monitor (di solito
il microfono)
• le macro SOUND_DEVICE_LABELS e SOUND_DEVICE_NAMES risultano di con-
seguenza arricchite rispettivamente delle etichette e dei nomi da linea di
comando dei nuovi canali:
#define SOUND_DEVICE_LABELS {"Vol ", "Bass ", "Trebl", "Synth",
"Pcm ", "Spkr ", "Line ", "Mic ",
"CD ", "Mix ", "Pcm2 ", "Rec ",
"IGain", "OGain", "Line1", "Line2",
"Line3", "Digital1", "Digital2",
"Digital3", "PhoneIn", "PhoneOut",
"Video", "Radio", "Monitor"}
#define SOUND_DEVICE_NAMES {"vol", "bass", "treble", "synth",
"pcm", "speaker", "line", "mic",
"cd", "mix", "pcm2", "rec", "igain",
"ogain", "line1", "line2", "line3",
"dig1", "dig2", "dig3", "phin",
"phout", "video", "radio", "monitor"}
• ` stata modificata mixer_info; la sua nuova struttura ` la seguente:
e e
char id[16 ] identificatore della scheda audio (in genere un paio di caratteri)
char name[32 ] nome per esteso della scheda
int modify counter numero di modifiche
int fillers[10 ] “riempitivi” per evoluzioni future
30