Ce paragraphe répond à des questions qui sont souvent posées dans les forums de discussion et les listes de diffusion.
Des réponses à d'autres questions peuvent également être trouvées sur la page web des pilotes son OSS.
Ce sont des noms le plus souvent "standard", mais certaines distribtutions Linux peuvent avoir choisi des noms différents.
lien symbolique vers /dev/audio0
périphérique audio compatible avec les stations Sun (dans une implémentation partielle seulement : il n'y a pas de support de l'interface ioctl Sun, uniquement l'encodage u-law)
second périphérique audio (pour certaines cartes son ou si vous en avez deux)
normalement, c'est un lien symbolique vers /dev/dsp0
premier périphérique d'échantillonage
second périphérique d'échantillonage
lien vers /dev/mixer0
premier mixeur son
second mixeur son
interface séquenceur de haut niveau
accés bas niveau pour MIDI, FM et GUS
normalement, lien vers /dev/music
premier port MIDI
second port MIDI
troisième port MIDI
quatrième port MIDI
indique l'état du pilote son
Le pilote pour haut-parleur PC fournit les fichiers de périphériques suivant :
équivalent à /dev/audio
équivalent à /dev/dsp
équivalent à /dev/mixer
Les fichiers son provenant des stations Sun (.au) peuvent être envoyés directement dans /dev/audio. Les fichiers son bruts doivent être envoyés dans /dev/dsp, de préférence en utilisant un utilitaire prévu à cet effet (play). Sinon, le résultat risque d'être de piètre qualité.
Les programmes comme wavplay ou vplay (dans le paquetage snd-util) donneront leurs meilleurs résultats avec des fichiers WAV. Par contre, ils ne reconnaissent pas les fichiers WAV Microsoft compressés avec ADPCM. Les anciennes versions de play (dans le paquetage Lsox) fonctionnent mal avec les fichiers WAV 16 bits.
Le programme splay du paquetage snd-util peut être utilisé pour jouer la plupart des fichiers son si les paramètres corrects sont spécifiés en ligne de commande.
La lecture de /dev/audio ou /dev/dsp fournira des données échantillonées qui peuvent être redirigées vers un fichier. Un programme tel que vrec facilite le réglage de la fréquence d'échantillonage, la durée d'enregistrement, etc. Vous aurez aussi certainement besoin d'un programme de mixage pour sélectionner l'entrée son apropriée.
Avec le piloye son actuel, il est possible d'avoir plusieurs SoundBlaster, SoundBlaster/Pro, SoundBlaster16, MPU-401 ou cartes MSS à la fois sur votre système. L'installation de deux SoundBlaster est possible en définissant les macros SB2_BASE, SB2_IRQ, SB2_DMA et dans certains cas SB2_DMA2 dans le fichier local.h. Il est aussi possible d'avoir en même temps une SoundBlaster et une PAS16.
Avec les nouveaux noyaux 2.0.X qui utilisent make config, vous devez éditer /usr/include/linux/autoconf.h à la place de local.h. Après la section contenant les lignes :
#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)
ajoutez ceci (avec des valeurs correctes pour votre système) :
#define SB2_BASE 0x330
#define SB2_IRQ (7)
#define SB2_DMA (2)
#define SB2_DMA2 (2)
Les pilotes suivants ne permettent pas d'instances multiples :
Vous devez créer les fichiers de périphériques du pilote son. Consultez la section concernée. Si vous avez déjà ces fichiers, assurez-vous qu'ils possèdent bien les nombres majeur et mineur corrects (certaines distributions obsolètes de Linux créent des fichiers de périphériques incorrects durant l'installation).
Vous avez démarré votre machine avec un noyau non configuré pour le son, ou alors, les adresses d'E/S configurées dans votre noyau ne correspondent pas à celles de votre marériel. Vérifiez que vous utilisez bien votre noyau fraichement compilé et qu'il a été correctement configuré avec des paramètres correspondant à votre matériel.
Ceci peut arriver si vous tentez d'envoyer des données vers /dev/audio ou /dev/dsp sans créer le fichier de périphérique adéquat. Ce fichier est alors un fichier normal qui a rempli votre disque-dur !!! Vous devez exécuter le script mentionné dans la section Création des fichiers de périphériques.
Cela peut également arriver avec Linux 2.0.x s'il n'y a pas suffisamment de mémoire vive sur votre machine lorsque le fichier de périphérique est ouvert. Le pilote audio a besoin d'au moins deux pages (de 8 ko) contiguës de mémoire vive physique pour chaque canal DMA. Cela peut arriver avec des machines ayant moins de 16 Mo de RAM ou qui tournent sans discontinuer depuis très longtemps. Il est possible de libérer de la mémoire vive en compilant et en éxécutant ce programme C avant d'ouvrir le fichier de périphérique :
main() {
int i;
char mem[500000];
for (i = 0; i < 500000; i++)
mem[i] = 0;
exit(0);
}
Un périphérique son ne peut être ouvert que
par un seul processus à la fois. Il y a certainement un
processus qui utilise déjà la carte son. Une façon
de le savoir est d'utiliser la commande fuser :
% fuser -v /dev/dsp
/dev/dsp: USER PID ACCESS COMMAND
tranter 265 f.... tracker
Dans cet exemple, la commande fuser montre que le processus
numéro 256 a déjà ouvert le périphérique.
Vous devez alors attendre que ce processus finisse son travail ou alors,
le tuer (avec kill). Pour connaître les processus d'un utilisateur autre que
vous, il faut être root pour utiliser la commande fuser.
Selon Brian Gough, il existe un conflit potentiel entre les SoundBlaster utilisant le canal DMA 1 et les lecteurs de bandes QIC-02 utilisant le même canal. D'où des erreurs de type "device busy". Si vous utilisez FTAPE, il se peut que le pilote concerné soit actif. Selon le FTAPE-HOWTO, le pilote du QIC-02 n'est pas nécessaire pour utiliser FTAPE. Il y a seulement besoin du pilote du QIC-117. Vous devez donc reconfigurer votre noyau pour qu'il utilise le bon pilote.
Habituellement, cela se traduit par l'arrêt de la lecture au bout d'une seconde environ, avec un message d'erreur du type "missing IRQ" ou "DMA timeout". Il s'agit certainement d'une mauvaise configuration de l'IRQ ou du canal DMA. Vérifiez que le noyau est bien configuré et qu'il n'y a pas de conflit d'adresse avec d'autres cartes.
Un autre symptôme est une lecture en boucle. Ceci est souvent lié à un conflit d'IRQ.
La lecture des fichiers MOD nécessite beacoup de ressources CPU. Il se peut que vous ayez trop de processus en cours ou bien que votre ordinateur soit trop lent pour une lecture en temps réel. Vous pouvez alors:
Si vous avez une Gravis UltraSound, vous avez intérêt à
utiliser un des lecteurs mod conçus spécifiquement pour la
GUS (par ex. gmod).
Les version 1.0c et antérieures du pilote son utilisent des
appels ioctl() incompatibles. Récupérez des
sources plus récentes ou effectuez les modifications nécessaires
pour l'adapter au nouveau pilote son. Voyez le fichier Readme
du pilote son pour plus de détails...
Soyez également certain que vous avez utilisé la dernière version de soundcard.h et ultrasound.h en compilant votre application. Voyez comment les installer au début de ce document.
Il s'agit certainement du même problème que précédemment.
Ils sont partiellement répertoriés dans le Hacker's Guide to VoxWare, actuellement disponible sous forme provisoire. La dernière version est la "draft 2" disponible sur ftp://nic.funet.fi/pub/Linux/ALPHA/sound/. Notez que ce répertoire est caché et n'apparaîtra pas à moins d'y accéder directement avec la commande "cd" de FTP.
Lors de la rédaction de ce document, de nouvelles documentations étaient disponibles sur le site web de 4Front Technologies.
Une autre source d'information est le Guide du Multimédia sous Linux (ndt: traduit en Français par Eric Dumas). Voir les références dans ce document.
Il n'existe pas de réponde immédiate à cette question. Cela dépend de:
En général, les machines à base de 386 peuvent jouer des échantillons ou faire de la synthèse FM sur des cartes 8 bits sans problème.
Jouer des fichiers MOD nécessite plus de ressources CPU. Des mesures expérimentales ont montré que la lecture d'un fichier son à 44 khz utilise plus de 40% des ressources processeur d'un 486/50 et qu'un 386/25 peut difficilement jouer plus rapidement que 22 khz (ceci pour des cartes 8 bits de type SondBlaster...). Une carte comme la Gravis UltraSound a plus de fonctions implémentées au niveau physique et nécessitera donc moins de ressources CPU.
(ndt: actuellement, on peut considérer que toute machine moderne, à base de pentium ou supérieur est capable d'enregistrer et de jouer des fichiers son en qualité "CD" : 44 khz/16 bits)
Ces considérations supposent que vous n'éxécutez par simultanément un processus gourmant en ressources CPU !!!
La conversion de fichiers son ou le calcul d'effets sonores par des
utilitaires comme sox est également plus rapide si vous possédez
un coprocesseur arithmétique (intégré ou non dans le processeur).
Le pilote son quant à lui n'effectue pas de calculs en virgule flottante.
(les explications suivantes ont éré fournies par seeker@indirect.com)
Linux reconnaît seulement la 1542 à l'adresse 330 (par défaut) ou 334, et la PAS autorise l'émulation MPU-401 à l'adresse 330 uniquement. Le conflit subsiste même si vous avez désactivé l'utilisation MPU-401 par voie logicielle. Passez la 1542 à l'adresse 334 rendera tout le monde heureux...
De plus, la 1542 et la PAS-16 utilisent toutes les deux un DMA 16 bits. Donc, si vous échantillonez à 44,1 khz en 16 bits stéréo et que vous sauvez le fichier sur un disque SCSI piloté par la 1542, vous aurez certainement des problèmes. Les canaux DMA débordent et la mémoire vive ne se rafraîchit pas assez vite. Vous obtenez alors un message d'erreur : "PARITY ERROR - SYSTEM HALTED", sans explication sur ce qui s'est passé. Encore pire : certains revendeurs de lecteurs de bandes QIC-117 recommendent de régler pour le bus des délais "on/off" tels que la 1542 est active plus longtemps qu'en utilisation normale. Procurez-vous le programme SCSISEL.EXE sur le BBS d'Adaptec ou à d'autres endroits sur Internet et réduisez la durée "on" du bus, ou augmentez sa durée "off" jusqu'à ce que le problème disparaisse. SCSISEL.EXE modifie les réglages de l'EEPROM et les modifications apportées fonctionneront donc au prochain redémarrage sous Linux.
Dernier problème - les vieilles puces Symphony réduisent de manière importante les périodes de cycle I/O pour accélerer les accès au bus. Aucune des cartes essayées ne produit de problèmes avec ces courtes périodes de cycle, sauf pour la PAS-16. Le BBS de Media Vision propose le programme SYMPFIX.EXE qui est supposé résoudre le problème en utilisant un bit de diagnostic dans le controleur de bus Symphony, mais cela ne procure aucune garantie matérielle. Vous devrez peut-être :
Le premier problème dépend de la puce utilisée sur votre carte-mère, de la vitesse du bus et des paramètres du BIOS, et de la phase de la lune. Le second problème dépend de l'option de rafraîchissement (caché ou synchronisé), de la fréquence de rafraîchissement du DMA de la 1542 et éventuellement de celui du bus d'E/S. Le troisième problème peut-être déterminé en appellant Media Vision et en leur demandant quelle catégorie de puce Symphony est incompatible avec leur design...
A cause de certaines limitation matérielles, ceci est impossible sur beaucoup de cartes-son. Certaines cartes récentes offrent cette possibilité. Pour plus d'informations, Consultez la section concernant le "mode bidirectionnel" dans le Hacker's Guide to Voxware.
Sur les machines à base de 286, l'IRQ 2 est équivalente à l'IRQ 9. Spécifiez IRQ 9 dans la configuration.
Dans le passé, Creative Labs ne souhaitait pas divulguer les informations techniques permettant de programmer leurs cartes. Depuis, ils ont changé de politique et un pilote pour AWE est maintenant inclus dans les noyaux 2.1.x.
Cela arrive après un redémarrage à chaud sur DOS. Parfois, le message d'erreur met en cause un mauvais fichier CONFIG.SYS.
Une rapide solution à ce problème est de procéder à un redémarrage complet en utilisant le bouton reset ou en coupant le secteur plutot qu'un redémarrage à chaud (en utilisant Control-Alt-Del). (N.d.t.: dans les nouvelles versions de linux, le redémarrage par Control-Alt-Del provoque normalement une réinitialisation totale de la machine, équivalente au "reset" matériel )
La bonne solution est d'utiliser les mêmes réglages d'IRQ et de DMA sous DOS et Linux (ou de ne pas utiliser DOS :-) ).
Ceux qui utilisent le portage de DOOM pour Linux réalisé par ID Software peuvent être intéressés par ces notes.
Pour une sortie son correcte, vous devez utiliser la version 2.90 ou supérieure du pilote son : il a été conçu pour supporter le mode temps-réel de DOOM.
Les échantillons sonores sont en 16 bits. Si vous avez une carte son 8 bits vous pouvez quand même utiliser le son en récupérant plusieurs programmes disponibles sur ftp://sunsite.unc.edu/pub/Linux/games/doom.
Si DOOM râme sur votre système, désactiver le son (en renommant le fichier sndserver) peut augmenter les performances.
Par défaut, DOOM ne supporte pas la musique sous Linux. Le programme musserver y remédie. On peut le trouver sur
ftp://pandora.st.hmc.edu/pub/linux/musserver.tgz.
Utilisez des câbles de liaison blindés et de bonne qualité, essayez de placer votre carte dans des slots différents. Si la carte a un control de volume, modifiez ce réglage.
Utilisez également un programme "mixeur" pour vous assurer que les entrées inutiles (comme le micro) sont désactivées.
Mais certaines cartes sont mal blindées et mal reliées à la terre et produisent naturellement beaucoup de bruit.
Enfin, sur mon système, j'ai découvert qu'utiliser l'option de
configuration no-hlt réduisait le niveau de bruit. Cette
commande force le noyau à ne pas utiliser l'instruction halt quand
il éxécute le processus "idle" (ndt : c'est à dire, quand le système
n'a rien à faire). Vous pouvez utiliser ceci manuellement au démarrage
ou le spécifier dans le fichier de configuration de LILO avec la
commande : append="no-hlt"
Si vous pouvez jouer des sons mais pas en enregistrer, essayez ceci :
Parfois, deux canaux DMA différents sont utilisés pour l'enregistrement et la lecture. Dans ce cas, il est assez probable que le canal DMA spécifié pour l'enregistrement n'est pas correct.
Dans la plupart des cas, une carte "compatible SoundBlaster" fonctionnera mieux sous Linux si elle est configurée avec un pilote autre que celui destiné à la véritable SoundBlaster. Beaucoup de cartes se disent "compatibles SoundBlaster" mais bien souvent, ce mode SoundBlaster est seulement un bidouillage prévu pour la compatibilité avec les jeux sous DOS. Beaucoup de cartes possèdent un mode 16 bits natif qui est facilement supporté par les version récentes du noyau Linux (2.0.1 et plus).
Pour d'autres cartes plus anciennes, il sera nécessaire d'essayer de les faire fonctionner dans le mode SoundBlaster. Les seules cartes récentes qui font exception à cette règle sont les cartes basées sur Mwave.
Les cartes son 16 bits dites "compatible SoundBlaster" ne sont véritablement qu'avec le mode 8 bits SoundBlaster Pro. Elles possèdent en général un mode 16 bits qui n'est compatible ni avec la SoundBlaster 16, ni avec le noyau Linux.
Vous arriverez peut-être à faire fonctionner votre carte en mode 16 bits en utilisant les pilotes MAD16 ou MSS/WSS.
Voici quelques bons sites d'archive intéressants pour les applications utilisant le son sous Linux :
Ceci est possible pour les versions récentes du noyau.
Consultez les fichiers /usr/src/linux/drivers/sound/Readme.modules et /usr/src/linux/Documentation/modules.txt (ou /usr/src/linux/README) pour plus d'informations.
Essayez le programme oplbeep que l'on peut trouver sur
ftp://sunsite.unc.edu/pub/Linux/kernel/patches/misc/modreq_beep.tgz
Une variante est le programme beep que vous trouverez sur
ftp://sunsite.unc.edu/pub/Linux/kernel/patches/misc/modreq_beep.tgz
Le paquetage modutils contient un exemple de programme et de
patch pour le noyau qui permettent d'appeller un programme externe donné
afin de générer des sons sur requête du noyau.
De plus, il est possible avec certaines cartes son d'y connecter la sortie du haut-parleur PC de telle manière que tous les sons passent par les haut parleurs de la carte.
Les pilotes son du noyau supportent différentes sortes de systèmes Unix/x86 et sont donc disponibles en tant que paquetage indépendant du noyau Linux. Jusqu'à Février 1996, les auteurs ont appellé ce programme "Voxware". Malheureusement, ce nom était déjà déposé par VoxWare Incorporated et ne pouvait donc plus être utilisé. Ces pilotes s'appellent maintenant OSS/Free.
L'Open Sound System (OSS) est un pilote son distribué de manière commerciale pour plusieurs systèmes Unix par 4Front Technologies. La version gratuite, connue sous le nom d'OSS/Free, continuera d'être disponible gratuitement pour Linux.
D'autres noms utilisés par le passé et se réferrant au même pilote son sont : TASD (Temporarily Anonymous Sound Driver) et USS (Unix Sound System).
Pour de plus amples informations, consultez la page web de 4Front Technologies sur http://www.4front-tech.com/. J'ai écris une présentation d'OSS/Linux dans le numéro de juin 1997 de Linux Journal (n.d.t. : en anglais).
La totalité des fonctions Plug & Play devrait être disponible dans les version 2.1 du noyau Linux. En attendant, il existe de nombreux essais de support Plug & Play.
Si vous possédez un système Pentium récent avec un BIOS Plug & Play, il devrait pouvoir pouvoir configurer vos cartes. Prennez garde de configurer le pilote son de Linux avec les mêmes paramètres d'E/S, d'IRQ et de canal DMA que dans le BIOS.
Il existe un paquetage d'outils Plug & Play pouvant être utilisés pour configurer les cartes. On peut le trouver sur le site http://www.redhat.com/ (peut-être se trouve t-il déjà dans votre distribution Linux).
Si vous utilisez votre carte sous Windows95, vous pouvez utiliser le gestionnaire de périphérique pour configurer la carte, puis démarrer Linux après une réinitialisation à chaud en utilisant le programme LOADLIN. Vérifiez que les paramètres de configuration sont identiques sous les deux systèmes.
Si vous utilisez votre carte sous DOS, vous pouvez utiliser l'utilitaire
icu qui est fourni avec les cartes SoundBlaster16 PnP afin de
configurer votre matériel sous DOS. Utilisez le programme LOADLIN pour
relancer Linux. Vérifiez ici encore que les paramètres sont identiques.
(N.d.t. : dans un grand nombre de cas, on pourra se contenter de configurer sa carte PnP sous DOS avec l'utilitaire adéquat pour les paramètres désirés. Ensuite, la carte (même éteinte) gardera en mémoire interne son paramêtrage, et il ne sera pas nécessaire de repasser par DOS ni d'utiliser LOADLIN.EXE pour lancer Linux :-) ).
La version commerciale du pilote son OSS supporte les SoundBlaster 16 PnP. Elle est disponible auprès de 4Front Technologies.
Une modification du pilote dans sa version 1.3.67 a rendu inopérants certains programmes son qui vérifiaient (abusivement) que le résultat de la requête ioctl SNDCTL_DSP_GETBLKSIZE était supérieure à 4096. Les utilitaires présents dans le dernier paquetage snd-util-3.x.tar.gz (sur ftp://ftp.4front-tech.com/ossfree) gèrent maintenant ceci correctement. Les dernières versions du pilote son ont également été modifiées pour éviter des fragments d'allocation plus petits que 4096 octets, ce qui résoud le problème avec les anciens utilitaires.
Le pilote son supporte un grand nombre de paramètres de configuration.
Le programme configure inclus avec le pilote son vérifie les
dépendances entre ces paramètres. Les outils utilisés pour configurer le
noyau ne supportent pas ce niveau de fonctionalités.
Cela dit, les derniers noyaux Linux permettent en partie d'utiliser les outils standard de configuration du noyau pour le pilote son (voyez la partie consacrée à la "configuration du noyau").
Il est possible de compiler le pilote son en tant que module chargeable
par le noyau et utiliser kerneld pour un chargement et déchargement
automatiques. Cela peut engendrer un problème. A chaque fois que le
module est rechargé, les paramètres du mixeur reprennent leur valeurs d'origine. Selon les cartes son, on peut alors obtenir un volume trop faible
ou trop élevé (par ex. SoundBlaster 16). Markus Gutschke
(gutschk@uni-muenster.de) a trouvé une solution qui consiste à
inclure cette ligne dans le fichier /etc/conf.modules :
options sound dma_buffsize=65536 && /usr/bin/setmixer igain 0 ogain 0 vol 75
Cela force votre programme mixeur (dans notre cas, setmixer) à
être exécuté immédiatement après le chargement du pilote son. Le paramètre
dma_buffsize est recquis par la commande option. Modifiez cela
en fonction de votre programme mixeur et de vos réglages de gain.
Si vous avez compilé le pilote son en dur dans le noyau et que vous souhaitez régler les différents gains du mixeur au démarrage de Linux, vous pouvez effectuer l'appel au programme mixeur dans /etc/rc.d/rc.local.
Par défaut, le script se trouvant dans Readme.linux qui crée les
fichiers de périphériques son (/dev/...) autorise seulement
l'accés à la carte son par root. Ceci afin de combler un
trou de sécurité potentiel. Dans un environnement réseau, des
utilisateurs externes pourraient se connecter à votre machine
et vous écouter par l'intermédiaire de la carte son et d'un
micro qui y serait raccordé. Si vous vous en foutez, il suffit
de changer les permissions des fichiers spéciaux /dev/audio et /dev/dsp.
Par contre, ce script autorise par défaut n'importe quel utilisateur à jouer un échantillon sonore dans la carte. Ceci n'a aucune conséquence sur la sécurité mais peut se révéler plutôt désagréable.
Vous trouverez des informations à ce sujet sur : http://www.screamin.demon.co.uk/.