Questo è il Linux Sound HOWTO. Serve da piccola guida di riferimento su tutto quello che dovete sapere per installare e configurare il supporto per il suono sotto Linux. Vi sono risposte alle domande più frequenti sul sonoro sotto Linux e riferimenti ad altri posti dove ottenere informazioni su diversi argomenti collegati al suono generato dal computer e alla musica.
La trattazione è limitata agli aspetti delle schede sonore pertinenti a Linux. Per informazioni di carattere più generale sulle schede audio, sull'aspetto del sonoro dei computer e sulla sintesi della musica si vedano gli altri documenti elencati nella sezione Riferimenti.
Molte delle informazioni qui presenti vengono dalla documentazione fornita con il codice sorgente del driver sonoro scritto da Hannu Savolainen ( hannu@opensound.com). Un grazie dunque ad Hannu, Alan Cox ed a tutte le altre persone che hanno sviluppato i driver sonori ed i loro programmi di utilità per Linux.
Grazie al pacchetto SGML Tools, questo HOWTO è disponibile in molteplici formati, tutti generati da un unico file sorgente.
Le nuove versioni di questo documento saranno postate periodicamente sul newsgroup comp.os.linux.answers. Ne sarà anche fatto l'upload su vari siti di ftp anonimo che archiviano questo tipo di informazioni incluso ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/.
Le versioni in ipertesto di questo e di altri Linux HOWTO sono disponibili su molti siti del World-Wide-Web, incluso http://metalab.unc.edu/LDP/. Molte distribuzioni di Linux su CD-ROM includono gli HOWTO, spesso nella directory /usr/doc, e se ne possono comperare copie stampate da diversi rivenditori. A volte gli HOWTO presenti nei CD-ROM dei rivenditori, nei siti ftp ed in forma stampata non sono aggiornati. Se la data di questo HOWTO è anteriore di più di sei mesi è probabile che vi sia una nuova versione su Internet.
Si noti anche che, per la natura dinamica di Internet, tutti i link siti web e ftp in questo documento sono soggetti a cambiamenti.
Traduzioni di questo documento sono disponibili nelle lingue seguenti:
Cinese: http://www.linux.org.tw/CLDP/Sound-HOWTO.html
Francese: http://www.freenix.org/unix/linux/HOWTO/
Giapponese: http://yebisu.ics.es.osaka-u.ac.jp/linux/
Coreana: http://kldp.linux-kr.org/HOWTO/html/Sound/Sound-HOWTO.html
Russa: http://www.phtd.tpu.edu.ru/~ott/russian/linux/howto- rus/Sound-HOWTO.html
Spagnola: ftp://ftp.insflug.org/es
Molte traduzioni di questo e di altri HOWTO sono anche su http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/ e ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/.
Se traducete questo documento in un'altra lingua vi prego di farmelo sapere e metterò qui un riferimento.
Confido nei lettori per rendere questo HOWTO utile. Se avete qualche suggerimento, correzione o commento vi prego di inviarmelo su tranter@pobox.com, e cercherò di inglobarlo nella versione successiva.
Vorrei anche rispondere a delle domande di carattere generale sulle schede audio sotto Linux, fin dove posso. Prima di porle vi prego di leggere tutte le informazioni contenute in questo HOWTO e di mandarmi informazioni dettagliate sul problema. Vi prego di non rivolgervi a me per questioni che riguardano l'uso di schede audio sotto sistemi operativi differenti da Linux.
Se pubblicate questo documento in un CD-ROM o in altra forma stampata, una copia di cortesia sarebbe da me apprezzata. Scrivetemi per il mio indirizzo di posta. Tenete anche in considerazione l'opportunità di fare una donazione al Linux Documentation Project per aiutare il progetto di una documentazione gratuita per Linux. Contattate il coordinatore dei Linux HOWTO, Tim Bynum, linux-howto@metalab.unc.edu, per maggiori informazioni.
Copyright (c) 1995-1999 di Jeff Tranter. Questo documento può essere distribuito nei termini descritti nella licenza LDP su http://metalab.unc.edu/LDP/COPYRIGHT.html.
Copyright (c) 1995-1999 by Jeff Tranter. This document may be distributed under the terms set forth in the LDP license at http://metalab.unc.edu/LDP/COPYRIGHT.html.
Questa sezione è intesa come panoramica molto generale sulla tecnologia audio utilizzata nei computer, in modo da rendere più agevole la comprensione dei concetti che verranno poi esposti in questo documento. Per saperne di più si consulti un libro sull'audio digitale o sull'elaborazione digitale dei segnali.
Il suono è analogico; può assumere qualsiasi valore in un intervallo continuo. I computer sono digitali; a loro piace lavorare con valori discreti. Le schede audio usano un dispositivo conosciuto come Convertitore Analogico/Digitale (A/D o ADC) per convertire le tensioni corrispondenti alle onde sonore analogiche in valori digitali o numerici che possono essere quindi memorizzati. Analogamente, un Convertitore Digitale/Analogico (D/A o DAC) converte valori numerici in tensioni analogiche che possono a loro volta pilotare un altoparlante, producendo il suono.
Il processo di conversione dall'analogico al digitale, conosciuto come ``campionamento'', introduce degli errori. Vi sono due fattori chiave che servono a determinare quanto un segnale campionato si avvicini all'originale. La frequenza di campionamento è il numero di campioni presi per unità di tempo (usualmente espressa in campioni per secondo o Hertz). Una bassa frequenza di campionamento fornirà una resa poco accurata del segnale analogico. L'ampiezza di campionamento è l'intervallo di valori usati per rappresentare ogni campione, usualmente espressa in bit. Più è grande l'ampiezza di campionamento, più accurata sarà la resa del segnale campionato.
Le schede audio usano normalmente campioni di 8 o 16 bit a frequenze di campionamento da circa 4000 a 44000 campioni al secondo. I campioni possono contenere uno (mono) o due (stereo) canali.
La sintesi FM è una vecchia tecnica usata per produrre il suono. È basata sulla combinazione di forme d'onda differenti (ad es. seno, triangolo, quadrato). La sintesi FM è più semplice da implementare a livello hardware della conversione D/A, ma è più difficile da programmare e meno flessibile. Molte schede audio utilizzano la sintesi FM per rimanere compatibili con le vecchie schede audio e il vecchio software. Vengono normalmente resi disponibili diversi generatori di suono indipendenti (voci).
La sintesi tramite wavetable combina la flessibilità della conversione D/A con la capacità di gestire canali multipli propria della sintesi FM. In questa maniera delle voci digitalizzate possono essere caricate in una area di memoria dedicata e quindi riprodotte, combinate e modificate con solo un piccolo impiego di CPU. Tutte le attuali schede audio supportano la sintetizzazione tramite wavetable.
Molte schede audio sono in grado di agire da mixer, combinando i segnali provenienti da entrate diverse e controllando i livelli di guadagno.
MIDI sta per ``Musical Instrument Digital Interface'' (interfaccia digitale per strumenti musicali) ed è un protocollo hardware e software standard che permette agli strumenti musicali di comunicare l'uno con l'altro. Gli ``eventi'' che vengono inviati tramite il bus MIDI possono anche essere memorizzati in file MIDI per consentirne successive modifiche e riascolti. Molte schede audio hanno un'interfaccia MIDI. Quelle che non la possiedono possono comunque riprodurre i file MIDI usando altre caratteristiche della scheda audio.
I file MOD sono un formato comunemente usato per la musica generata da computer. Assieme alle informazioni sulle note musicali che devono essere riprodotte, questi file contengono dei campioni digitalizzati per gli strumenti (o le voci). I file MOD sono stati usati per la prima volta sui computer Amiga ma possono essere ascoltati su altri sistemi, Linux incluso, con del software adatto.
Questa sezione elenca le schede audio e le interfacce che sono attualmente supportate sotto Linux. Le informazioni qui presenti sono basate sull'ultimo kernel che, al momento della stesura, risulta essere il 2.2.4. Questo documento riguarda solo i driver sonori inclusi nella distribuzione del sorgente del kernel di Linux (si veda la sezione intitolata Driver sonori alternativi).
Per le ultime informazioni sulle schede audio supportate e sulle funzioni dei driver si consultino i file acclusi alla distribuzione del kernel di Linux, normalmente installati nella directory /usr/src/linux/Documentation/sound.
Le informazioni contenute in questo HOWTO sono valide per la implementazione di Linux su processori di tipo Intel.
Il driver sonoro dovrebbe funzionare anche con molte schede audio nella implementazione per processori Alpha. Comunque qualche scheda potrebbe far nascere conflitti delle porte I/O con altri dispositivi installati nei sistemi Alpha anche se funziona perfettamente sulle macchine i386, quindi non si può dire, in generale, se una data scheda funzionerà oppure no senza averla provata.
Al momento della stesura di questo documento il driver sonoro non è ancora funzionante nell'implementazione per PowerPC di Linux, ma dovrebbe esserlo in futuro.
Le schede audio possono essere configurate nel kernel nell'implementazione di Linux per MIPs, e qualche macchina MIPs ha degli slot EISA e/o dell'hardware sonoro interno. Mi è stato detto che il gruppo Linux-MIPs è interessato a una futura aggiunta del supporto sonoro.
Il kernel di Linux include un driver separato nelle sue versioni per Atari e Amiga, driver che implementa un sottoinsieme compatibile del driver sonoro usato per la piattaforma Intel utilizzando l'hardware per il suono interno a queste macchine.
La versione di Linux per SPARC attualmente supporta l'audio solo in alcuni modelli di workstation Sun. Mi è stato detto che l'hardware audio on-board funziona ma il dispositivo DSP esterno non è supportato poiché Sun non ha reso pubbliche le sue specifiche.
Le seguenti schede audio sono supportate dal driver sonoro del kernel di Linux. Qualche elemento di questa lista è un chip audio più che una scheda audio. La lista è incompleta poiché vi sono altre schede audio compatibili con queste che funzionano sotto Linux. Come se la confusione fosse poca, dei produttori cambiano periodicamente il design delle loro schede audio causando incompatibilità e continuano a venderle come modello originario.
Anche se molte schede audio sono dette ``SoundBlaster compatibili'', molto poche, attualmente, sono abbastanza compatibili da funzionare con il driver di Linux per la SoundBlaster. Queste schede normalmente funzionano meglio usando il driver MAD16 o MSS/WSS. Solo le vere schede SoundBlaster fatte dalla Creative Labs, che usano i chip custom della Creative (per esempio, la SoundBlaster16 Vibra) e le schede basate su MV Jazz16 e ESS688/1688 generalmente funzionano con il driver per SoundBlaster. Provare a usare una ``scheda audio a 16 bit compatibile con SoundBlaster Pro'' con il driver SoundBlaster si rivela, normalmente, una perdita di tempo.
Il kernel di Linux supporta la porta SCSI di cui sono fornite alcune schede audio (per esempio ProAudioSpectrum 16) e l'interfaccia proprietaria di qualche drive CD-ROM (per esempio SoundBlaster Pro). Date un'occhiata ai Linux SCSI HOWTO e CDROM HOWTO per maggiori informazioni.
Assieme ai kernel 2.2 è anche distribuito un driver per le porte joystick presenti su alcune schede audio.
Si noti che i driver sonoro, SCSI, CD-ROM e joystick sono completamente indipendenti l'uno dall'altro.
Il supporto per l'audio del kernel di Linux è stato originariamente scritto da Hannu Savolainen. Hannu ha poi sviluppato Open Sound System, una suite commerciale di driver audio venduta da 4Front Technologies, che è disponibile su diversi sistemi Unix. La Red Hat Software ha quindi sponsorizzato Alan Cox con l'obiettivo di potenziare i driver audio rendendoli completamente modulari. Diverse altre persone hanno poi dato il loro contributo con correzioni di errori e hanno sviluppato driver aggiuntivi per le nuove schede audio. Questi driver modificati sono stati inclusi nella distribuzione Red Hat dalla versione 5.0 alla 5.2. Le modifiche sono quindi state integrate nella distribuzione standard del kernel dalla versione 2.0. Alan Cox è il curatore di driver audio della distribuzione standard del kernel, mentre Hannu continua periodicamente a fornire codice preso dal driver commerciale.
Open Sound System, il driver commerciale della 4Front Technologies tende ad essere più facile da configurare e offre supporto per un maggior numero di schede audio, particolarmente per quelle nuove. È anche compatibile con le applicazioni scritte per il driver audio incluso nella distribuzione standard del kernel. Lo svantaggio è che dovrete pagare per averlo e comunque non avrete il codice sorgente. Potete scaricare una copia di prova del prodotto prima di decidere se comprarlo o no. Per maggiori informazioni si guardi sulla pagina web della 4Front Technologies: http://www.opensound.com.
Jaroslav Kysela e altri hanno cominciato a scrivere un driver audio alternativo per la scheda audio Gravi UltraSound. Il progetto è stato rinominato in Advanced Linux Sound Architecture (ALSA) ed è risultato in un sistema di driver audio che gli autori credono essere una buona alternativa per i driver audio del kernel. I driver ALSA offrono supporto per molte schede audio diffuse, sono full duplex, completamente modulari e compatibili con l'architettura audio del kernel. Il sito principale del progetto ALSA è http://www.alsa-project.org. È anche disponibile un "Alsa-sound-mini-HOWTO" che tratta della compilazione e dell'installazione di questi driver.
Markus Mummert ( mum@mmk.e-technik.tu-muenchen.de) ha scritto un pacchetto driver per le schede audio Turtle Beach MultiSound (classic), Tahiti e Monterey. La documentazione asserisce:
``È progettato per la registrazione/riproduzione su hard disk di alta qualità, senza perdita di sincronizzazione nemmeno su un sistema occupato. Altre funzioni, come Wave synthesis, MIDI ed elaborazione digitale dei segnali (DSP), non possono essere usate. Altresì la registrazione e la riproduzione contemporanee non sono possibili. In questo momento sostituisce VoxWare ed è stato testato in diverse versioni del kernel dalla 1.0.9 alla 1.2.1. Oltretutto è installabile sui sistemi UN*X SysV386R3.2.''
Lo si può trovare su http://www.cs.colorado.edu/~mccreary/tbeach.
Kim Burgaard ( burgaard@daimi.aau.dk) ha scritto un driver e dei programmi di utilità per l'interfaccia MIDI Roland MPU-401. La voce che lo riguarda sulla Linux Software Map ne dà questa descrizione:
``Un driver per le interfacce MIDI compatibili con Roland MPU-401 (incluse Roland SCC-1 e RAP-10/ATW-10). Include una serie di utilità tra le quali un player di file Standard MIDI ed un registratore.
Molte migliorie sono state apportate dalla versione 0.11a. Tra le altre cose il driver adesso si avvale di regole per la condivisione degli IRQ e si attiene alla nuova interfaccia del kernel per i moduli. La funzione di metronomo, la possibilità di sincronizzare ad es. la grafica su una struttura di battute senza perdere in precisione, una interfaccia avanzata per replay/registrazione/overdub e molto, molto ancora.''
Lo si può trovare su ftp://metalab.unc.edu/pub/Linux/kernel/sound/mpu401-0.2.tar.gz.
Altro utilizzo di una scheda audio per Linux è quello del modem per radioamatori in packet radio. I recenti kernel 2.1.x includono un driver che funziona con schede audio compatibili SoundBlaster e Windows Sound System per implementare i protocolli packet 1200 bps AFSK e 9600 bps FSK. Date un'occhiata al Linux AX25 HOWTO per altri dettagli (fra parentesi sono radioamatore anche io -- il mio callsign è VE3ICH).
È disponibile un altro driver sonoro che non richiede hardware aggiuntivo; infatti usa lo speaker del PC. È sicuramente più compatibile a livello software con il driver della scheda audio ma, come è normale aspettarsi, fornisce un output di qualità molto minore e occupa la CPU per un tempo molto maggiore. I risultati sono di vario tipo, poiché dipendono dalle caratteristiche di ogni singolo speaker. Per maggiori informazioni date un'occhiata alla documentazione fornita assieme alla distribuzione.
La versione attuale è la 1.1 e la si trova su ftp://ftp.informatik.hu-berlin.de/pub/os/linux/hu-sound/
Altra opzione è quella di costruire un convertitore digitale-analogico utilizzando la porta parallela della stampante e qualche componente aggiuntivo. Ciò porta a un output di qualità superiore rispetto allo speaker del PC, ma genera ancora un pesante utilizzo di CPU. Il pacchetto del driver per il PC speaker prevede questa opzione e include le istruzioni per costruire l'hardware necessario.
Configurare Linux per supportare il suono prevede i seguenti passaggi:
Se avete Red Hat Linux avete anche una utility chiamata sndconfig
che in molti casi rileverà la vostra scheda audio e imposterà tutti i
necessari file di configurazione per caricare i giusti driver audio per
la vostra scheda. Se avete una Red Hat vi suggerisco di provarla. Se
vi funziona allora potete saltare il resto delle istruzioni in questa
sezione.
Se sndconfig non riesce nel suo intento, state usando un'altra
distribuzione o volete seguire il metodo manuale per poter meglio
comprendere quello che state facendo, le prossime sezioni descriveranno
dettagliatamente tutti i passi da compiere.
Seguite le istruzioni del produttore per l'installazione dell'hardware o, meglio, richiedete al vostro rivenditore l'installazione della scheda al momento dell'acquisto.
Le vecchie schede sonore usano switch o jumper per l'impostazione di IRQ, canali DMA, ecc; trascrivete su un foglio i valori assegnati. Se non siete sicuri, usate i parametri predefiniti. Nel limite del possibile cercate di evitare conflitti con altro hardware installato sul sistema (come schede Ethernet, SCSI, porte seriali e parallele) .
Usualmente si dovrebbero usare la stessa porta di I/O, IRQ e impostazioni di DMA che si usano sotto DOS. In qualche caso (particolarmente con schede PnP) si devono usare impostazioni diverse per far funzionare le cose sotto Linux. Serve qualche prova.
Attualmente diverse schede audio utilizzano il protocollo Plug and Play per configurare le impostazioni degli indirizzi di I/O, irq e canali DMA. Se avete una vecchia scheda che ha delle impostazioni fisse o dei jumper (ponticelli) potete saltare alla prossima sezione.
Alla versione 2.2 del kernel non vi è ancora un completo supporto per il Plug and Play. La soluzione preferita è quella che prevede l'utilizzo dei tool isapnp che sono presenti in molte distribuzioni di Linux (o che potete scaricare dal sito web della Red Hat http://www.redhat.com/).
Date per prima cosa un'occhiata alla documentazione della vostra distribuzione di Linux. Il supporto Plug and Play potrebbe essere già configurato o potrebbe funzionare in maniera differente da come viene qui descritto. Se dovete configurarvelo da soli potete trovare altri dettagli nelle pagine di manuale del tool isapnp. In breve, la procedura che dovrete seguire è la seguente:
pnpdump per scoprire tutte le possibili
impostazioni dei vostri dispositivi Plug and Play, salvando il risultato
nel file /etc/isapnp.conf.
(ACT Y) che si trova verso la fine.
isapnp venga eseguito all'avvio del sistema,
cosa normalmente fatta da uno script di avvio. Fate il reboot del vostro
sistema o eseguite manualmente isapnp.
Se per qualche motivo non potete o non volete usare il tool isapnp, vi sono altre soluzioni. Se utilizzate la scheda audio sotto Microsoft Windows 95 o 98, potete usare il device manager per configurare la scheda audio e quindi effettuare un soft boot di Linux usando il programma LOADLIN. Assicuratevi che Windows e Linux utilizzino le stesse impostazioni di configurazione della scheda.
Se utilizzate la scheda dal DOS potete usare l'utilità icu
che viene distribuita assieme alla SoundBlaster16 PnP per configurarla da
DOS, quindi effettuare un soft boot di Linux utilizzando LOADLIN. Ancora una
volta assicuratevi che sia DOS che Linux utilizzino le stesse impostazioni
della scheda.
Qualche driver per schede audio include il software necessario ad inizializzare il Plug and Play per la scheda. Date un'occhiata alla documentazione del driver per maggiori informazioni.
Al momento della prima installazione normalmente si usa un kernel precompilato. Questo kernel normalmente non supporta il suono. La cosa migliore è, senza dubbio, la ricompilazione del kernel con l'aggiunta dei driver che vi servono. Dovreste comunque ricompilare il kernel perlomeno per aggiornare la versione e minimizzare la grandezza del file stesso (vmlinuz) onde evitare di occupare troppo spazio in memoria.
Il Linux Kernel HOWTO dovrebbe essere consultato per i dettagli su come compilare un nuovo kernel. Qui procederò solamente a riportare alcuni passaggi riguardanti il supporto sonoro.
Se, prima d'ora, non avete mai configurato il kernel per il supporto sonoro sarebbe una buona idea leggere tutti i Readme file inclusi con il kernel sound driver ed in particolar modo le informazioni specifiche riguardanti la vostra scheda sonora. La seguente documentazione si trova normalmente nella directory del kernel sound driver, che viene installata di default in /usr/src/linux/drivers/sound. Se questa directory non è presente è molto probabile che abbiate una versione molto vecchia o non abbiate installato il codice sorgente.
Seguite la normale procedura per compilare il kernel. Attualmente vi sono
tre interfacce per il processo di configurazione. Un'interfaccia utente grafica
che gira sotto X11 e può essere lanciata con make xconfig. Una basata
su menu che richiede sono un display testuale è disponibile con make
menuconfig. Il metodo originale, usando make config, offre una
semplice interfaccia di testo.
Durante la configurazione del kernel vi saranno molte scelte da effettuare per configurare correttamente il driver per la scheda che possedete. L'help in linea di cui il programma di configurazione dispone dovrebbe fornire un adeguato supporto a questa fase della procedura. Scegliete meglio che potete.
Dopo aver configurato il kernel dovrete compilarlo ed installare il nuovo kernel come descritto nel Kernel HOWTO.
Per un corretto funzionamento devono essere creati dei file dispositivo per i dispositivi audio. Essi vengono creati di norma durante l'installazione del vostro sistema Linux. Può essere fatto un controllo veloce utilizzando il comando di cui si parla qui di seguito. Se l'output è quello mostrato (la data può variare) allora i file dispositivi sono quasi sicuramente a posto.
% ls -l /dev/sndstat
crw-rw-rw- 1 root root 14, 6 Apr 25 1995 /dev/sndstat
Si noti che il fatto che i file dispositivo siano a posto di per sé non garantisce nulla. Anche il driver del kernel deve essere stato caricato o compilato prima che le periferiche funzionino (se ne parlerà più avanti).
In qualche raro caso, se si crede che i dispositivi siano errati, essi
possono essere ricreati. Diverse distribuzioni di Linux hanno
lo script /dev/MAKEDEV che può essere utilizzato a tale scopo.
Dovreste essere pronti per eseguire il boot e testare il sound driver. Seguite le normali procedure per installare e fare il boot del nuovo kernel (non cancellate il vecchio kernel, può servire nel caso in cui si incontrino problemi).
Durante il boot, controllate l'esistenza di un messaggio tipo questo alla
partenza (se passano troppo velocemente, li potete rileggere con il
comando dmesg):
Sound initialization started
<Sound Blaster 16 (4.13)> at 0x220 irq 5 dma 1,5
<Sound Blaster 16> at 0x330 irq 5 dma 0
<Yamaha OPL3 FM> at 0x388
Sound initialization complete
Deve corrispondere al tipo di scheda installata e al settaggio di IRQ e jumper (se ci sono).
Si noti che i messaggi di cui sopra non vengono mostrati se si è
preferito utilizzare il driver come modulo caricabile del kernel (a meno
che non venga abilitato, ad esempio con insmod sound trace_init=1).
Quando il driver sonoro viene compilato nel kernel i messaggi
Sound initialization started e Sound initialization complete
devono apparire. Se ciò non accadesse significa che non è presente un
driver sonoro nel kernel. In questo caso si avrà cura di controllare che
il kernel installato sia quello che è stato compilato con l'abilitazione
del driver sonoro.
Se non viene visualizzato nulla tra le righe Sound initialization
started e Sound initialization complete significa che non sono
stati rilevati dispositivi audio. Molto probabilmente significa che non è stato
abilitato il driver giusto, la scheda non è supportata, la porta
di I/O è sbagliata o che si ha una scheda PnP che non è stata
configurata.
Il driver può anche mostrare dei messaggi di errore e altre avvertenze durante il boot. Si stia attenti a tali messaggi la prima volta che viene effettuato il boot dopo aver configurato il driver sonoro.
Si dovrà successivamente controllare il file dispositivo /dev/sndstat. Leggendo il file sullo stato del driver sonoro (/dev/sndstat) vengono presentate informazioni aggiuntive sulla eventuale corretta inizializzazione del driver sonoro. Ecco un esempio di output:
% cat /dev/sndstat
Sound Driver:3.5.4-960630 (Sat Jan 4 23:56:57 EST 1997 root,
Linux fizzbin 2.0.27 #48 Thu Dec 5 18:24:45 EST 1996 i586)
Kernel: Linux fizzbin 2.0.27 #48 Thu Dec 5 18:24:45 EST 1996 i586
Config options: 0
Installed drivers:
Type 1: OPL-2/OPL-3 FM
Type 2: Sound Blaster
Type 7: SB MPU-401
Card config:
Sound Blaster at 0x220 irq 5 drq 1,5
SB MPU-401 at 0x330 irq 5 drq 0
OPL-2/OPL-3 FM at 0x388 drq 0
Audio devices:
0: Sound Blaster 16 (4.13)
Synth devices:
0: Yamaha OPL-3
Midi devices:
0: Sound Blaster 16
Timers:
0: System clock
Mixers:
0: Sound Blaster
Il comando precedente può restituire alcuni messaggi di errore. ``No such file or directory'' indica che si devono creare i file dispositivo (vedi sezione 4.3). ``No such device'' significa che il driver sonoro non è stato caricato o linkato nel kernel. Si ritorni alla sezione 4.2 per rimediare a questo errore.
Se le linee della sezione ``Card config:'' di /dev/sndstat sono
visualizzate tra parentesi (tipo ``(SoundBlaster at 0x220 irq5 drq 1,5)''),
significa che quel dispositivo è stato configurato ma non rilevato.
Adesso siete pronti per eseguire un semplice file sonoro. Prendete un qualsiasi file sonoro e reindirizzatelo sul dispositivo sonoro per testarne il risultato, ad esempio:
% cat endoftheworld >/dev/dsp
% cat crash.au >/dev/audio
(State attenti a non dimenticare il ``>'' nel comando di cui sopra).
Si noti che, in generale, l'uso di cat non è la maniera più
adatta per riprodurre file audio, serve solo come piccolo controllo.
Avrete bisogno di un vero e proprio programma di riproduzione
(se ne parla più avanti) che farà un lavoro migliore.
Questo comando funzionerà se vi è almeno un dispositivo nella sezione ``audio devices'' di /dev/sndstat. Se la sezione ``audio devices'' è vuota ci si dovrà accertare del perché il dispositivo non è stato rilevato.
Se il comando precedente restituisce un ``I/O error'', dovreste dare un'occhiata alla parte finale dei messaggi del kernel usando il comando ``dmesg''. È probabile che vi si trovi un messaggio di errore. Molto spesso il messaggio è ``Sound: DMA (output) timed out - IRQ/DRQ config error?''. Questo messaggio significa che il driver non ha utilizzato con successo l'interrupt impostato per comunicare con la scheda audio. In molti casi significa che l'IRQ o il canale DMA configurato nel driver non sono corretti. La maniera migliore di farlo funzionare è quella di tentare con tutte le possibili combinazione di DMA e IRQ supportati dal dispositivo audio.
Un'altra possibile ragione è costituita dall'incompatibilità del dispositivo rilevato con il driver che si è scelto di installare. È questo il caso delle schede che si dicono ``SoundBlaster (Pro/16) compatibili'' ma che non funzionano con il driver per SoundBlaster. In questo caso si dovrà scoprire con quale scheda audio è compatibilie la propria (per esempio scrivendo un messaggio sul newsgroup comp.os.linux.hardware).
Alcuni esempi di file sonori sono reperibili presso : ftp://tsx-11.mit.edu/pub/linux/packages/sound/snd-data-0.1.tar.Z
Adesso verificate la registrazione. Se avete la possibilità di usare un dispositivo di input potete fare un test veloce in questo modo:
# registra 4 secondi di audio dal microfono
EDT% dd bs=8k count=4 </dev/audio >sample.au
4+0 records in
4+0 records out
# esegue il suono registrato
% cat sample.au >/dev/audio
Ovviamente per far funzionare tutto ciò si dovrà aver connesso un microfono alla scheda audio e vi si dovrà parlare. Forse avrete anche bisogno di installare un programma mixer per impostare il microfono come dispositivo di input e regolare il guadagno.
Se il test non dà problemi, potete ragionevolmente confidare nel fatto che la scheda D/A -- A/D e il software funzionano. Al contrario se avete riscontrato problemi controllate la sezione successiva di questo documento.
Se comunque, dopo avere seguito le istruzioni dell'HOWTO, incontrate problemi qui propongo alcune cose da controllare. I controlli sono proposti in ordine progressivo di difficoltà. Se un controllo non funzionasse, risolvete il problema prima di passare al controllo successivo.
Potete controllare la data del kernel per vedere se state usando quello
compilato con il supporto per il suono. Si può farlo usando il comando
uname :
% uname -a
Linux fizzbin 2.2.4 #1 Tue Mar 23 11:23:21 EST 1999 i586 unknown
o visualizzando il file /proc/version:
% cat /proc/version
Linux version 2.2.4 (root@fizzbin) (gcc version 2.7.2.3) #1 Tue
Mar 23 11:23:21 EST 1999
Se la data non corrisponde al giorno in cui avete compilato il kernel, allora state usando un vecchio kernel. Avete eseguito il reboot? Se usate LILO, lo avete reinstallato (normalmente eseguendo lilo)? Se eseguite il boot da un floppy, ne avete creato uno nuovo di boot e lo avete utilizzato per il boot?
Il modo più facile per fare questo controllo è quello di dare un'occhiata
all'output di dev/sndstat come detto precedentemente. Se l'output non è quello
che ci si attendeva allora qualche cosa è andata storta durante la
configurazione o la compilazione del kernel. Fate ripartire il processo
di installazione, ricominciando dalla configurazione e compilazione del
kernel.
Assicuratevi che il kernel abbia rilevato la scheda al momento del boot.
Dovreste avere visto un messaggio in fase di boot. Se il messaggio è passato
troppo velocemente potete richiamarlo con il comando dmesg :
% dmesg
oppure
% tail /var/log/messages
Se la scheda non è stata trovata qualcosa è andato storto. Assicuratevi che sia realmente installata. Se funziona sotto DOS potete ragionevolmente sperare che l'hardware funzioni, probabilmente è solo un problema di configurazione del kernel. Forse avete configurato la scheda del tipo sbagliato o assegnato parametri inesatti, o la scheda non è compatibile con nessuno dei driver sonori del kernel di Linux.
Una possibilità è quella che la scheda sia una delle compatibili
che richiedono l'inizializzazione dal driver del DOS. Provate a fare il boot da
DOS e ad installare il driver fornito dal produttore della scheda. Poi eseguite
un boot a caldo di Linux usando Control-Alt-Canc. Assicuratevi che gli indirizzi di I/O,
DMA e le impostazioni degli IRQ della scheda siano gli stessi sia per Linux che per DOS.
Consultate il file Readme.cards nei sorgenti della distribuzione del
sound driver per eventuali consigli sulla configurazione della scheda.
Se la scheda non compare nel documento, è possibile che il Linux sound driver non la supporti. Controllate i riferimenti alla fine di questo documento.
Provate a leggere dal dispositivo /dev/audio usando il comando
dd visto prima all'interno di questo documento. Il comando deve
funzionare senza errori.
Se non funziona probabilmente dipende da un conflitto di IRQ o DMA o da qualche tipo di incompatibilità hardware (il dispositivo non è supportato da Linux o il driver è stato configurato per un dispositivo errato).
Una remota possibilità potrebbe essere un hardware non funzionante. Provate a eseguire un test da DOS, se possibile, per vedere se è questa la causa.
Se ci sono ancora problemi, quelli che seguono sono gli ultimi consigli su tentativi eventuali:
comp.os.linux o su
altri gruppi Usenet (comp.os.linux.hardware è una buona scelta; a causa
dell'altro livello di traffico su questi gruppi aiuta mettere la parola ``sound''
nel subject del messaggio, in modo tale che i giusti esperti lo notino);Esc-x doctor :-)Qui propongo un esempio di applicativi che dovreste usare se avete una scheda sonora. Potete cercare anche nella Linux Software Map, negli archivi di Internet (siti ftp), o sul vostro CD-ROM di Linux per informazioni più aggiornate.
Come minimo, dovreste avere questi applicativi:
sox)aumix o xmix)play o
wavplay)tracker)playmidi)Esistono versioni con interfaccia testuale e versioni con interfaccia grafica della maggior parte di questi applicativi. Vi sono anche altre applicazioni esoteriche (come quelle che parlano o riconoscono il parlato) che forse vorrete provare.
Questa sezione risponde a qualcuna delle domande che vengono comunemente poste nei newsgroup Usenet e nelle mailing list.
Risposte ad altre domande possono essere trovate alla pagina web del driver sonoro OSS.
Gran parte dei nomi dei dispositivi audio sono standard, ma in qualche distribuzione di Linux potrebbero avere nomi leggermente differenti.
Normalmente un link a /dev/audio0
Dispositivo audio compatibile con le workstation Sun (è solo un implementazione parziale, non supporta l'interfaccia ioctl di Sun, solo la codifica u-law)
Secondo dispositivo audio (se supportato dalla scheda audio o se vi è più di una scheda audio installata)
Normalmente un link /dev/dsp0
Primo dispositivo di campionamento digitale
Secondo dispositivo di campionamento digitale
Normalmente un link a /dev/mixer0
Primo mixer audio
Secondo mixer audio
Interfaccia ad alto livello del sequencer
Accesso a basso livello di MIDI, FM e GUS
Normalmente un link a /dev/music
Prima porta raw MIDI
Seconda porta raw MIDI
Terza porta raw MIDI
Quarta porta raw MIDI
Se letto riporta lo stato del driver sonoro (anche come /proc/sound)
Il driver per l'altoparlante del PC fornisce i seguenti dispositivi:
Equivalente a /dev/audio
Equivalente a /dev/dsp
Equivalente a /dev/mixer
I file (.au) delle workstation Sun possono essere riprodotti reindirizzandoli
a /dev/audio . I file ``raw'' possono essere riprodotti
reindirizzandoli su /dev/dsp. È preferibile usare comunque un
programma tipo play, visto che riconosce la maggior parte di file e
imposta la scheda sonora sulla giusta frequenza di campionamento, ecc.
I programmi come wavplay o vplay (contenuti nel pacchetto snd-util) daranno i migliori risultati con i file WAV. Comunque sia essi non riconosceranno i file compressi Microsoft WAV ADPCM. Inoltre le vecchie versioni di play (contenute nel pacchetto Lsox) non funzioneranno perfettamente con i file WAV a 16 bit.
Il comando splay contenuto nel pacchetto snd-util può essere usato per riprodurre la maggior parte dei file audio, se si impostano manualmente i giusti parametri nella riga di comando.
La lettura di /dev/audio o /dev/dsp produrrà dei
dati campionati che possono essere rediretti su un file. Un programma come
vrec renderà più agevole il controllo della frequenza di
campionamento, della durata, ecc. Probabilmente si avrà anche bisogno
di un programma mixer per selezionare il dispositivo di input appropriato.
Con l'attuale driver sonoro è possibile avere diverse schede SoundBlaster, SoundBlaster/Pro, SoundBlaster16, MPU-401 o MSS contemporaneamente nello stesso sistema. L'installazione di due SoundBlaster è possibile ma richiede la definizione delle macro SB2_BASE, SB2_IRQ, SB2_DMA e (in qualche caso) SB2_DMA2 tramite la modifica manuale di local.h. È anche possibile avere una SoundBlaster e una PAS16 allo stesso tempo.
Con i nuovi kernel 2.0, che configurano il supporto per il suono usando make config, al posto di local.h, si avrà bisogno di modificare il file /usr/include/linux/autoconf.h. Dopo la parte contenente le linee:
#define SBC_BASE 0x220
#define SBC_IRQ (5)
#define SBC_DMA (1)
#define SB_DMA2 (5)
#define SB_MPU_BASE 0x0
#define SB_MPU_IRQ (-1)
si aggiungano queste linee (con i valori giusti per il proprio sistema):
#define SB2_BASE 0x330
#define SB2_IRQ (7)
#define SB2_DMA (2)
#define SB2_DMA2 (2)
I seguenti driver non permettono installazioni multiple:
Si devono creare i file dispositivo per il driver sonoro. Controllate la sezione sulla ``Creazione dei file dispositivo'' . Se ci sono, assicuratevi che abbiano il corretto ``minor'' e ``major number'' (alcune vecchie distribuzioni di Linux sui CD-ROM non creano i file dispositivo corretti al momento dell'installazione).
Non avete eseguito il boot di un kernel compilato con il supporto per il suono o la configurazione dell'indirizzo di I/O non corrisponde al vostro hardware. Controllate se avete usato il kernel giusto e verificate che l'impostazione dei parametri della vostra scheda, assegnati in fase di configurazione del driver sonoro, corrisponda esattamente all'impostazione della scheda stessa.
Può succedere se provate a registrare dati attraverso /dev/audio o /dev/dsp senza aver creato i necessari file dispositivo. Il dispositivo sonoro ora è un file normale, e ha riempito la vostra partizione. Dovete eseguire lo script documentato nella sezione ``Creazione dei file dispositivo'' in questo documento.
Si può incorrere in questo errore anche con Linux 2.0 e successivi se non vi è abbastanza RAM di sistema libera per aprire il dispositivo. Il driver audio richiede almeno due pagine (8k) di RAM fisica contigua per ogni canale DMA. Questo accade a volte nelle macchine con meno di 16M di RAM o in quelle che sono rimaste accese per molto tempo. Potrebbe essere possibile liberare della memoria RAM compilando ed eseguendo il seguente programma C prima di provare a utilizzare il dispositivo audio di nuovo:
main() {
int i;
char mem[500000];
for (i = 0; i < 500000; i++)
mem[i] = 0;
exit(0);
}
Il dispositivo audio può essere aperto da un solo processo per volta.
Molto probabilmente qualche altro processo sta usando il dispositivo
in questione. Una maniera per esserne sicuri è quella di utilizzare il
comando fuser:
% fuser -v /dev/dsp
/dev/dsp: USER PID ACCESS COMMAND
tranter 265 f.... tracker
In questo esempio, il comando fuser ci mostra come il processo numero
265 abbia aperto il dispositivo. Per accedere nuovamente al dispositivo audio
si deve aspettare che il processo termini o si procede a un ``kill'' del processo
stesso. Per vedere accessi al dispositivo fatti da altri utenti il comando
fuser deve essere eseguito come utente root.
In qualche sistema si dovrà essere root per vedere con il comando
fuser i processi degli altri utenti.
In accordo con quello che dice Brian Gough, per le schede SoundBlaster che usano il canale DMA 1 vi è un potenziale conflitto con il driver dello streamer QIC-02, che usa il canale DMA 1, causando errori del tipo ``device busy''. Se si sta usando FTAPE probabilmente si è abilitato questo driver. Come dice il FTAPE-HOWTO il driver QIC-02 non è essenziale per l'uso di FTAPE; è richiesto solo il driver QI-117. La riconfigurazione del kernel con l'inclusione del driver QI-117 e l'esclusione del driver QI-02 consente a FTAPE ed al driver sonoro di coesistere.
Il sintomo è normalmente che il file audio suona per circa un secondo e poi si blocca completamente oppure riporta un errore tipo: ``missing IRQ'' o ``DMA timeout''. Probabilmente avete delle impostazioni degli IRQ o DMA sbagliate. Verificate che la configurazione del kernel corrisponda alle impostazioni dei jumper della vostra scheda e che gli stessi non siano in conflitto con qualche altra scheda installata nel sistema.
Un altro sintomo è il file audio che provoca un loop. Questo è normalmente causato da un conflitto di IRQ.
L'esecuzione dei file MOD richiede un grande impiego di CPU. O avete troppi processi attivi o il vostro computer è troppo lento per l'esecuzione in ``real time''. Avete alcune possibilità:
Se avete una scheda Gravis UltraSound, dovete usare uno dei programmi per
eseguire i file mod scritti specificatamente per la GUS (ad es. gmod).
La versione 1.0c e precedenti del driver sonoro usavano uno schema diverso
e incompatibile dell'ioctl() . Si ottenga il nuovo codice o
si effettuino i necessari cambiamenti per adattarlo al nuovo driver sonoro.
Controllate il file Readme del driver sonoro per i dettagli.
Controllate comunque di usare l'ultima versione di soundcard.h e di ultrasound.h quando compilate l'applicazione. Guardate le istruzioni per l'installazione all'inizio di questo testo.
Questo è probabilmente lo stesso problema affrontato nella domanda precedente.
Si controllino i file inclusi con i sorgenti del driver sonoro del kernel.
Attualmente la migliore documentazione che non sia il codice sorgente è disponibile sul sito web della 4Front Technologies, http://www.opensound.com. Un'altra fonte di informazioni è la Linux Multimedia Guide, di cui si parla nella sezione ``Riferimenti''.
Non vi è una facile risposta a questa domanda, poiché dipende da:
In generale ogni 386 dovrebbe essere in grado di riprodurre con facilità campioni o musica sintetizzata tramite FM con una scheda audio a 8 bit.
La riproduzione dei file MOD, però, richiede un considerevole impiego di CPU. Test sperimentali hanno mostrato che riprodurre a 44KHz richiede più del 40% della potenza di un 486/50 e che un 386/25 difficilmente può andare più in là dei 22KHz (il tutto con una scheda audio a 8 bit come la SoundBlaster). Una scheda come la Gravis Ultrasound dispone di maggiori funzioni nel suo hardware ed impiegherà meno tempo di CPU.
Queste affermazioni sottointendono che il computer non stia eseguendo nessun altro programma che richieda un forte uso della CPU.
La conversione di file audio o l'aggiunta di effetti usando un
programma di utilità come sox è molto più veloce
se si dispone di un coprocessore matematico
(o di una CPU con FPU on board). Comunque il driver del
kernel non esegue nessun calcolo in virgola mobile.
(La spiegazione seguente è stata fornita da
seeker@indirect.com)
Linux riconosce il 1542 all'indirizzo 330 (predefinito) o 334, e la PAS permette l'emulazione MPU-401 solo a 330. Anche se si disabilita MPU-401 via software, c'è ancora qualcosa che entra in conflitto con il 1542 se esso usa il suo indirizzo preferenziale. Spostare il 1542 su 334 rende tutti felici.
In aggiunta, sia la 1542 che la PAS-16 usano un DMA a 16-bit, cosicché se campionate a 16-bit 44KHz stereo e salvate il file su un drive SCSI attaccato alla 1542, preparatevi a incontrare problemi. I DMA si sovrappongono e non c'è il tempo sufficiente per un ``refresh'' della RAM, e vi trovate un bel messaggio ``PARITY ERROR - SYSTEM HALTED'', senza rendervi conto di quale sia stata la causa. Ancora peggio alcuni rivenditori di terze parti raccomandano, con i tape drives QIC-117, di impostare i tempi on/off del bus come il 1542 anche se sono più lunghi del normale. Procuratevi il programma SCSISEL.EXE dalla BBS della Adaptec o da qualche altro sito di Internet, abbassate il ``time'' BUS ON o incrementate il BUS OFF finché il problema scompare, poi muovetelo di una tacca o più in avanti. Lo SCSISEL cambia le impostazioni della EEPROM, così la modifica diventa permanente e non avete bisogno di aggiungere una riga nel CONFIG.SYS del DOS, e potete avviare direttamente Linux ignorando i driver del DOS. Prossimo problema: risolto!
Ultimo problema - i vecchi chipset Symphony riducevano drasticamente i cicli di I/O per velocizzare i tempi di accesso al bus. Nessuna delle varie schede che ho usato hanno dato problemi con il timing ridotto a eccezione della PAS16. La BBS della Media Vision propone il programma SYMPFIX.EXE che, si suppone, risolva il problema attivando il bit di diagnostica nel controller del bus della Symphony, ma non è garantito totalmente. Avete bisogno di:
Young Microsystem propone un aggiornamento della scheda che importa per circa $30 (USA); altri produttori dovrebbero comportarsi allo stesso modo se riuscite a dimostrare chi altro importa la motherboard (buona fortuna!). Il problema è nel chip dell'interfaccia per il bus ProAudio, però molto più lontano di quanta non sia la mia ansia; nessuno compra una scheda sonora da $120 e la piazza su un bus AT a 6MHz. La maggior parte si avvale di un computer a 25/40Mhz tipo 386/486, e dovrebbe riuscire ad ottenere perlomeno 12MHz di velocità del bus se i chip sono progettati correttamente. Uscita dal pulpito (scala sinistra).
Il primo problema dipende dal chipset usato sulla vostra scheda madre, dalla velocità del bus e da altre impostazioni del BIOS, e dalle fasi della luna. Il secondo problema dipende dalle opzioni di ``refresh'' (nascoste o sincronizzate), dalla velocità del canale DMA del 1542 e (forse) dalla velocità di accesso I/O al bus. Il terzo lo si determina chiamando la Media Vision e chiedendo quale tipo di chip Symphony è incompatibile con il suo design lento. Fate attenzione: 3 su 4 dei tecnici con cui mi hanno fatto parlare erano degli idioti. Dovevo diffidare di qualsiasi cosa mi dicessero su altro hardware, visto che non conoscevano molto bene neanche il loro.
I driver di qualche scheda audio supportano la modalità full duplex. Si faccia riferimento alla documentazione della 4Front Technologies per informazioni su come utilizzare questa particolarità.
Sui 286 e successivi l'IRQ 2 è collegato in cascata al secondo controller di interrupt. È equivalente all'IRQ 9.
Nel passato la Creative Labs non voleva rendere pubbliche le informazioni di programmazione di queste schede. Adesso hanno cambiato opinione e un driver per AWE è oggi incluso nei kernel Linux 2.1.x.
Questo può succedere dopo un ``soft-reboot'' al DOS. Alle volte il messaggio di errore fa riferimento, erroneamente, a un errore nel file CONFIG.SYS.
La maggior parte delle attuali schede sonore hanno la possibilità di impostare IRQ e DMA via software. Se usate impostazioni differenti per Linux e per MS-DOS/Windows, potreste avere problemi. Alcune schede non accettano nuovi parametri senza un reset completo (ovvero, spegnere il computer o usare il pulsantino di reset).
La soluzione più semplice a questo problema consiste nell'effettuare un reboot completo tramite il pulsantino di reset o lo spegnimento della macchina anziché un ``soft reboot'' (ovvero Ctrl-Alt-Canc).
La soluzione corretta consiste nell'impostare gli stessi IRQ e DMA sia con MS-DOS che con Linux (o non usare DOS :-)).
Gli utilizzatori del porting del gioco della ID Software DOOM per Linux potrebbero essere interessati a queste notizie.
Per un corretto risultato sonoro usate la versione 2.90 o successive del
driver sonoro; ha il supporto per la nuova modalità in real-time DOOM
Mode.
I campioni sonori sono a 16-bit. Se avete una scheda audio a 8 bit potete comunque far funzionare il sonoro usando uno dei programmi disponibili su ftp://metalab.unc.edu/pub/Linux/games/doom.
Se DOOM risultasse lento sul vostro sistema, disabilitando il sonoro (basta
rinominare il file sndserver) dovrebbero aumentare le prestazioni.
La musica in DOOM non è attivata per predefinizione (come nella
versione DOS). Il programma musserver aggiunge il supporto
per la musica a DOOM per Linux. È reperibile a questo indirizzo:
ftp://pandora.st.hmc.edu/pub/linux/musserver.tgz.
L'uso di cavi schermati di buona qualità e provare la scheda audio su slot differenti può aiutare a ridurre il rumore. Se la scheda audio ha una regolazione per il volume si possono provare le differenti posizioni consentite (il massimo è probabilmente la scelta migliore). Si usi un programma mixer per assicurarsi che le entrate non volute (ad es. il microfono) siano poste a guadagno zero.
Philipp Braunbeck dice di aver trovato sulla sua scheda audio ESS-1868 un jumper che permetteva di escludere l'amplificatore della scheda stessa, che altrimenti produceva rumore.
Su un sistema 386 ho scoperto che l'opzione di avvio del kernel no-hlt
riduce il livello di rumore. Serve a dire al kernel di non usare
l'istruzione halt mentre esegue il loop del processo idle. Potete
provarla anche voi manualmente al boot o attraverso LILO
usando il comando append="no-hlt" nel vostro file
di configurazione di LILO.
Qualche scheda audio semplicemente non è progettata con una buona schermatura e messa terra ed è quindi esposta a questo tipo di problemi.
Se potete riprodurre suoni, ma non registrarli, provate a seguire questi passi:
A volte i canali DMA usati per registrare e per riprodurre sono differenti. In questo caso la causa più probabile del malfunzionamento è che i canali DMA siano stati impostati in maniera errata.
In molti casi una scheda ``SoundBlaster compatibile'' funzionerà meglio sotto Linux se configurata con un driver diverso da quello SoundBlaster. Molte schede audio dicono di essere compatibili (ad es. ``compatibile SB Pro 16 bit'' o ``compatibile SB 16 bit'') ma normalmente la modalità SoundBlaster è solo un trucco per mantenere la compatibilità con i giochi di DOS. Molte schede hanno una modalità nativa a 16 bit che probabilmente sarà supportata dalle recenti versioni di Linux (2.0.1 e successive).
Solo con qualche scheda audio (normalmente abbastanza vecchia) è necessario provare a farla funzionare in modalità SoundBlaster. Le sole schede audio recenti che fanno eccezione a questa regola sono quelle basate su Mwave.
Le schede audio a 16 bit definite SoundBlaster compatibili sono in effetti compatibili con la SoundBlaster Pro 8 bit. Normalmente hanno una modalità a 16 bit che non è compatibile con la SoundBlaster 16 e non è compatibile con il driver sonoro di Linux.
Potreste riuscire a farle funzionare in modalità 16 bit usando il driver MAD16 o MSS/WSS.
Ecco qua qualche buon archivio su cui andare a cercare applicazioni sonore specifiche per Linux:
Si veda anche la sezione ``Riferimenti'' di questo documento.
Con i kernel più recenti il driver sonoro può anche essere compilato e utilizzato nella forma di diversi moduli caricabili.
Si dia un'occhiata al file /usr/src/linux/Documentation/sound, e specialmente al file Introduction e README.modules.
Provate il programma oplbeep, che si trova su
ftp://metalab.unc.edu/pub/Linux/apps/sound/oplbeep-alpha.tar.gz
Altra variante è il programma beep su
ftp://metalab.unc.edu/pub/Linux/kernel/patches/misc/modreq_beep.tgz
Il pacchetto modutils contiene un programma di esempio e una patch
per il kernel che consente di chiamare un programma esterno per generare suoni
su richiesta del kernel.
In alternativa con qualche scheda audio è possibile connettere l'output dello speaker del PC alla scheda audio in modo tale che tutti i suoni vengano dagli speaker della scheda audio.
La versione commerciale dei driver sonori commercializzati da 4Front Technologies era stata chiamata, in precedenza VoxWare, USS (Unix Sound System), e anche TASD (Temporarily Anonymous Sound Driver). È adesso venduta come OSS (Open Sound System). Alla versione presente nel kernel si fa spesso riferimento con il nome OSS/Free.
Per maggiori informazioni si veda il sito web della 4Front Technologies http://www.opensound.com/. Ho scritto un articolo su OSS/Linux nel numero di Giugno 1997 del Linux Journal.
Una modifica del driver sonoro effettuata nella versione 1.3.67 ha reso inutilizzabili alcuni programmi di riproduzione che (non correttamente) controllano che la chiamata al ioctl SNDCTL_DSP_GETBLKSIZE sia più grande di 4096. Gli ultimi driver sonori sono stati corretti in modo da evitare allocazioni di frammenti più piccoli di 4096 byte, per risolvere il problema con i programmi di utilità più vecchi.
Il driver sonoro può essere compilato come modulo caricabile e si
può utilizzare kerneld per caricarlo e scaricarlo automaticamente.
Ciò può far sorgere un problema: ogni volta che si ricarica il modulo
le impostazioni del mixer ritornano ai loro valori predefiniti.
Per qualche scheda audio questi possono essere troppo alti (ad es.
SoundBlaster16) o troppo bassi. Una soluzione è stata trovata da
Markus Gutschke (gutschk@uni-muenster.de): si inserisce
una linea come la seguente nel proprio file /etc/conf.modules:
options sound dma_buffsize=65536 && /usr/bin/setmixer igain 0 ogain 0 vol 75
Questo fa in modo che il vostro programma mixer (in questo caso
viene utilizzato setmixer) venga eseguito immediatamente
dopo che il driver sonoro è stato caricato. Il parametro
dma_buffersize è finto, serve solo perché il comando
"options" richiede che venga impostata un'opzione. Si modifichi
la linea come si desidera per utilizzare i propri programmi mixer
e livelli di guadagno.
Se il driver sonoro è stato compilato nel kernel e si vogliono impostare i guadagni dal mixer al momento dell'avvio del sistema, potete inserire una chiamata al programma mixer in un file di avvio del sistema, come è /etc/rc.d/rc.local.
Per predefinizione lo script in Readme.linux che crea i file
dispositivo sonori imposta i permessi di accesso a tali file
in maniera tale da consentirne la lettura dall'utente root.
Questo per tappare un buco nella sicurezza del sistema.
In un sistema di computer in rete gli utenti esterni possono
effettuare un login su un PC Linux con scheda audio e microfono
e ascoltare ciò che viene detto. Se ciò non vi preoccupa potete
tranquillamente cambiare i permessi di accesso ai file usati
nello script.
Con le impostazioni predefinite gli utenti possono comunque riprodurre file audio. Questo non costituisce un rischio per la sicurezza del sistema ma sono una fonte di potenziale disturbo.
Le informazioni su come utilizzare la scheda audio mwave che si trova sui computer laptop ThinkPad di IBM sotto Linux possono essere trovate nel file /usr/src/linux/Documentation/sound/mwave, che fa parte della distribuzione del sorgente del kernel.
Alcune vecchie schede SoundBlaster a 8 bit non avevano un circuito mixer. Vi
sono delle applicazioni che insistono nel voler accedere al mixer, e non
possono funzionare con questo tipo di schede. Jens Werner (
werner@bert.emv.ing.tu-bs.de)
ci suggerisce un rimedio: basta creare un link da /dev/mixer a
/dev/null e tutto dovrebbe funzionare a puntino.
Da: Scott Manley ( spm@star.arm.ac.uk):
Sembra che un nuovo tipo di SoundBlaster sia in commercio -- e ci venga venduta come una SB16 -- il numero di modello indicato sulla scheda è il CT4170. Queste schede hanno un solo canale DMA e quindi, dopo che le avrete configurate, il kernel avrà grossi problemi nell'accedere al canale DMA 16 bit. La soluzione è impostare il secondo DMA a 1 in modo tale che la scheda si comporti come le altre.
Da: Kim G. S. OEyhus ( kim@pvv.ntnu.no):
Ho cercato su Internet e nella documentazione che riguarda il supporto sonoro come fare una cosa semplice come connettere l'output MIDI di una tastiera all'input MIDI di una scheda audio. Non ho trovato nulla. Il problema è che entrambe usano lo stesso dispositivo, /dev/midi, almeno se utilizzate il driver OSS. Ho trovato un modo di farlo, che vorrei condividere con voi. Quello che dico si applica a un sintetizzatore molto semplice, con completo supporto del MIDI:
Collegare una master keyboard MIDI a una scheda audio via MIDI
Una master keyboard MIDI è una tastiera senza alcun sintetizzatore e con solo un connettore MIDI out. Questo può essere collegato a una porta 15-pin D-SUB presente in molte schede audio con un opportuno cavo.
Una simile tastiera può essere utilizzata per controllare il sintetizzatore MIDI presente nella scheda audio, facendolo diventare un semplice sintetizzatore controllato da tastiera.
Si compili il programma seguente, ad esempio con 'gcc -o prog prog.c' e lo si mandi in esecuzione:
#include <fcntl.h>
main()
{
int fil, a;
char b[256];
fil=open("/dev/midi", O_RDWR);
for(;;)
{
a=read(fil, b, 256);
write(fil, b, a);
}
}
Da: Matthew Inger ( mattinger@mindless.com):
Come far funzionare una scheda Ensoniq PCI 128
Il problema che si presentava era che la scheda cercava di utilizzare l'interrupt 15 come impostazione predefinita (a causa del Plug and Play). Questo interrupt è utilizzato dal controller ide secondario e non può essere condiviso da altri dispositivi. Si deve quindi forzare in qualche maniera il es1370 a usare un altro interrupt (ad esempio l'interrupt 11 come avviene da Windows).
Che ci crediate o no mi sono inventato da solo una soluzione.
Ecco ciò che dovete fare:
a) nel BIOS dovrete dire al vostro computer che non avete un sistema operativo Plug and Play. Mi sembra che nel mio BIOS sia fra le opzioni avanzate.
b) nelle impostazioni del bus PCI del BIOS, impostate il computer in maniera tale che riservi l'interrupt 15 per i vecchi dispositivi ISA. Nel mio bios, fra le opzioni avanzate, vi è una sezione dedicata alle impostazioni PCI. In questa sezione vi è una parte chiamata Resource Exclusion, è qui che dovete agire.
Quando farete il reboot di Linux potrete utilizzare la scheda sonora (non mi ricordo se appare nei messaggi di boot come accadeva prima oppure no). Per essere del tutto sicuri, ho rieseguito sndconfig per far uscire il messaggio di test, che in effetti non si sentiva granché, ma comunque si sentiva. Invece l'output di un CD audio si sente perfettamente.
Non preoccupatevi di Windows, ho provato le mie due schede: modem ISA e scheda audio e funzionavano senza problemi.
Il problema potrebbe essere che il vostro BIOS sarà differente dal mio ma dovete solo immaginarvi dove poter trovare le due impostazioni di cui ho parlato prima. Buona fortuna.
Soft OSS è un sintetizzatore wavetable via software incluso nel driver sonoro del kernel, compatibile con la scheda Gravis Ultrasound. Per far funzionare il driver vi serviranno dei file patch MIDI compatibili con la GUS. La documentazione le chiama ``public domain MIDIA patchset available from several ftp sites''.
Come spiegato sul sito web della 4Front Technologies http://www.opensound.com/softoss.html possono essere scaricate da ftp://archive.cs.umbc.edu/pub/midia/instruments.tar.gz.
Se avete una scheda audio che supporta un'interfaccia CDROM o SCSI, il Linux SCSI HOWTO e il Linux CD-ROM HOWTO contengono altre informazioni che potrebbero esservi utili.
Il Sound Playing HOWTO descrive come eseguire differenti tipi di file audio e musicali sotto Linux.
Il Linux SoundBlaster AWE32/64 Mini-HOWTO descrive come far funzionare una scheda audio SoundBlaster 32 o 64 sotto Linux.
Informazioni sulla programmazione possono essere trovate sul sito web della 4Front Technologies http://www.opensound.com/pguide.
Le seguenti FAQ sono spedite regolarmente sul newsgroup Usenet news.announce e archiviate su ftp://rtfm.mit.edu/pub/usenet/news.answers:
Le FAQ contengono anche dei riferimenti a mailing list e siti che trattano di prodotti specifici. Nei seguenti newsgroup Usenet si parla dei problemi riguardanti il suono e/o la musica:
Si può trovare un sito Web dedicato alla multimedialità su http://viswiz.gmd.de/MultimediaInfo/. Altro buon sito per il MIDI per Linux e le applicazioni per l'audio è http://sound.condorow.net/. La Creative Labs ha un sito Web all'indirizzo http://www.creaf.com/. MediaTrix ha un sito Web all'indirizzo http://www.mediatrix.com/.
Le mailing list su Linux contengono un certo numero di ``canali'' dedicati a diversi argomenti, incluso l'aspetto sonoro. Per sapere come entrare a farne parte, inviate un messaggio con la parola ``help'' come corpo del messaggio a majordomo@vger.rutgers.edu. Queste mailing list non sono quelle adatte per domande sulla configurazione della scheda audio e così via, sono state create per discussioni legate allo sviluppo.
Come detto più volte, il driver sonoro del kernel contiene vari file Readme con delle utili informazioni sul driver della scheda audio. Normalmente sono nella directory /usr/src/linux/drivers/sound.
Altre informazioni su OSS, il driver sonoro commerciale per Linux e altri sistemi operativi Unix compatibili, le si può trovare sul sito Web di 4Front Technologies, http://www.opensound.com/.
La Linux Software Map (LSM) è un riferimento insostituibile per trovare del software per Linux. La ricerca della LSM per parola chiave sound è una buon metodo per identificare applicazioni relative all'hardware sonoro. La LSM può essere trovata su vari siti anonimi di FTP, incluso ftp://metalab.unc.edu/pub/Linux/docs/LSM/. Vi sono anche diversi siti web che hanno una database delle applicazioni per Linux. Uno di questi è http://www.freshmeat.net.
Il Linux Documentation Project ha prodotto diversi libri su Linux, incluso Linux Installation and Getting Started. Questi sono disponibili liberamente su FTP anonimo nei più grandi archivi di Linux o possono essere comprati già stampati.
Infine, un messaggino senza vergogna: se volete imparare molto di più sulla multimedialità sotto Linux (specialmente su quanto concerne la programmazione e le applicazioni per CD-ROM e scheda audio) date un'occhiata al mio libro Linux Multimedia Guide, ISBN 1-56592-219-0, edito da O'Reilly and Associates. È disponibile la versione inglese e le traduzioni in francese e giapponese sono in fase di stampa. Per avere altri dettagli chiamate 800-998-9938 nel Nord America o date un'occhiata alla pagina Web su http://www.ora.com/catalog/multilinux/noframes.html o alla mia pagina http://www.pobox.com/~tranter.