*******************************************************
** Les cartes sons SoundBlaster PCI : réflexions **
**************************************************v1.0*
------------------------------
0) Liminaire et préliminaires.
------------------------------
La mise en place d'une SB64 PCI sous Linux m'a posé quelques problèmes.
Mais quel bonheur lorsque tout fonctionne !
Ceci est le résultat de quelques nuits blanches.
Je pense que ce qui y est décrit s'applique également aux SB PCI 128.
Parfois, les drivers sont carréments communs. Dans le pire des cas, il
suffit de choisir le driver Ensoniq adapté à la puce, mais le principe reste
le même.
Si vous pensez que j'ai oublié quelque chose, ou si j'ai commis une
malheureuse erreur, merci de me le signaler à : jseb@hexanet.fr
Vous pouvez redistribuer ce texte, tant que cela est fait gratuitement.
Si vous désirez le modifier, merci de me prévenir tout d'abord.
Je remercie les personnes qui ont réagi au post du brouillon de ce texte
dans FCOLC, en particulier Sébastien Caille.
-------------------------------
1) Au fait, on m'a vendu quoi ?
-------------------------------
Avez-vous vraiment une SB 64 PCI sur votre système ? Si vous pensez
que votre revendeur fait partie de la DST et qu'il complote contre
vous, vous pouvez vérifier :
"less /proc/pci " et rechercher la chaine "Ensoniq".
On obtient différents renseignements, comme: "Vendor ID=1274 ,
Device ID = 1371."
1371, c'est le numéro du chip Ensoniq. Il parait qu'il y a également
des es1370 sur les 64 PCI (ils doivent être plus ou moins équivalent,
et de toute façon, on sait depuis bien longtemps que la compatibilité
entre les soundblasters dites "originales" est une bien bonne blague).
D'après plusieurs sources, il semblerait que sur les SB128, le chip soit
identique.
-----------------------------------
2) Qu'en est-il des drivers Linux ?
-----------------------------------
Déja, au risque d'énoncer une évidence, je précise qu'il n'y a rien
sur le CD d'installation de la soundblaster.
Pas la peine d'aller sur la page Web de Creative Labs, il n'y a rien non
plus (à part beaucoup d'autosatisfaction).
Heureusement, on trouve d'excellents drivers, même si ils ne sont pas
finalisés (d'après les docs, car dans la réalité, les drivers ALSA sont
excellents et tout à fait exploitables.)
Voici le résultat de mes recherches, que je vais développer ensuite:
* Drivers écrits par Thomas Sailer (version alpha). Non testés.
* Drivers OSS : je ne les ai pas essayés, car ils sont payants.
* Drivers RedHat : faciles à installer, mais très buggés (v2.0.36)
* Drivers ALSA : le meilleur et le plus long pour la fin.
Sinon, il semble que dans les distributions récentes (2.2.x), les drivers
soient intégrés et qu'il suffise de faire un petit "sndconfig" pour que
tout marche.
On m'a écrit que "sndconfig" fonctionnait dès le noyau 2.0.36, qui intègre
dans certains cas les nouveaux drivers, mais mes essais ne m'ont pas permis
de pouvoir choisir autre chose que les soundblaster ISA de base.
Précisions sur l'OSS (merci à Olivier Tharan, que je cite):
"OSS, c'est la version commerciale des drivers sons sous Linux, avec des
possibilités pas mal telles que le full duplex. Au fur et à mesure, une
partie de ces drivers deviennent "free" et sont intégrés dans le noyau,
c'est OSS-Free."
A) Le driver de Thomas Sailer
-----------------------------
Voici ce que l'on trouve comme introduction a l'URL:
http://www.ife.ee.ethz.ch/~sailer/linux/es1371.html
"This is an alpha release of a driver for the Ensoniq AudioPCI PCI
soundcard.It supports the OSS PCM (wave) and mixer interfaces. It is
intended to be used with the 97 version of the AudioPCI (it can be
recognized by the chips used, Ensoniq ES1371 and Ashai Kasei AKM4540,
or by the PCI vendor ID 0x1274 and device ID 0x1371)."
Son driver est un client de soundcore. Là, je vous encourage à aller
voir sa page, car je ne peux pas vraiment en dire plus: je ne sais pas
à quel niveau du traitement soundcore s'intercale entre les
applications et le driver es1371. Soundcore permet-il d'accéder au
matériel ? Cela me parait peu probable (quel serait le rôle de
es1371.o dans ce cas ?). A mon avis, soundcore est une bibliothèque de
fonctions de haut niveau pour le traitement du son (ex: "lire un
sample", l'accès au matériel se faisant avec es1371).
Les "revisions history" s'arrêtent au 6 avril 98, ce qui fait un
bail.
Peut être le développement est-il stoppé.
Sur la page principale du site
(http://www.ife.ee.ethz.ch/~sailer/linux/)
L'auteur dit également ceci:
"As of Linux 2.1.109, my PCI audio drivers are integrated into the
standard Linux kernel. No more fiddling with device files required.
For 2.0.3x, Alan Cox has prepared the 2.0.34-modular-3.patch.gz,
available from http://ftp.uk.linux.org/pub/linux/alan/Sound/, while
intended to be used on 2.0.34, can also be applied to the 2.0.35
release with one reject in a readme file."
Je n'ai pas essayé ce driver. Il est cité ici à titre d'informations.
B) Les drivers RedHat
---------------------
Je les appelle drivers "RedHat", car je les ai trouvé sur la
distribution RedHat 5.2 du CD Dream #60.
Il faut recompiler les sources contenues dans le RPM
"kernel-source-2.0.36-0.7.i386.rpm"
Ces drivers ne sont pas présents dans d'autres sources que j'avais
récupéré sur Internet. Il semble que seul RedHat fournit la
possibilité de compiler ces drivers, du moins sur cette version du
noyau.
J'ai lu ici et là que le noyau 2.2 contenait également les sources des
modules SB PCI, mais je n'ai pas encore mis la main sur ces sources
(et de toute façon, j'ai trop de choses à mettre à niveau sur mon
système pour compiler ces sources pour que cela soit intéressant).
Le seul problème, c'est que vous serez obligé de recompiler un noyau
complet, car "/usr/src/linux/drivers/sound" ne contient pas un fichier
makefile permettant de faire un "make config" + "make sound".
Il doit y avoir possibilité de compiler à la main le module son, mais
je dois avouer que je n'en ai aucune idée.
De plus, il faut obtenir deux drivers: "soundcore.o" et "es1371.o".
Ca sent encore la compilation compliquée. ("es1371" s'appuie sur
"soundcore")
Pour les charger à la main, mettez-vous dans le bon répertoire, et tapez:
[root] /lib/modules/2.0.36/misc # insmod soundcore
[root] /lib/modules/2.0.36/misc # insmod es1371
Bon, comme vous n'êtes pas tout le temps loggé en root, n'oubliez pas de
les démarrer au boot avec modprobe (voir le man modprobe), qui charge et
décharge les modules suivant la demande des programmes. (ça change de la
gestion foireuse des VxD).
J'ai utilisé ces drivers, mais ils posaient quelques problèmes, qui seront
probablement résolus lors des prochaines distributions.
i) "cat /dev/sndstat" donne "Operation not supported by device"
ii) Mikmod ne fonctionne pas (core dumped).
iii) Bien que mpg123 et x11amp donnent d'excellents résultats avec les
paramètres par défaut, les problèmes apparaissent lorqu'on essaie de les
modifier: le son devient très parasité, et entrecoupé de blancs.
(Par exemple, lorsque l'on tente une sortie 8 bits.)
D'après la doc, ce n'est pas la peine de tester la carte avec le
"cat truc.au /dev/dsp" recommandé dans le HowTo "Sound", car ça ne
marche pas (du moins, pas avec les drivers RedHat).
En fait, le format de compression uLaw n'est pas supporté, et il faut
transformer le sample en RAW avant de le jouer.
Si vous tentez la commande, le sample sera joué avec un fort bruit de
fond, ou à la mauvaise fréquence. Ne vous étonnez donc pas.
N'oubliez pas non plus que par défaut, le son est très bas. Vous pouvez
le monter sous console avec l'excellent "aumix", présent sur toutes les
distributions (et peut être même installé par défaut). Sous X, vous
pouvez essayer "xmixer", mais il existe une kyrielle de mixers bien plus
agréables et/ou jolis. (avec xmixer, il faut cliquer comme un forcené
pour monter le son, et l'interface est assez moche. Enfin, c'est standard
et ça dépanne.)
C) ALSA, ce n'est pas du flan !
-------------------------------
http://alsa.jcu.cz
Voici les drivers les plus intéressants.
Alsa se pose en "concurrent" à OSS. Ils ne font pas payer les
drivers, et ils fournissent les sources.
J'ai récupéré sur leur site les sources de la version 3.0. Le support
pour les ES1370/1371 est implémenté depuis un moment déja.
Les sources sont accompagnées d'une généreuse documentation, et même
si je ne capte pas tout (difficile sans les datasheets des cartes, et
sans les connaissances sur la façon dont le son est géré par les
applis), leur lecture est intéressante.
Dans les sources, le bas niveau de l'es1371 utilise es1370.c .J'ai
jeté un coup d'oeil au source, les deux puces sont différenciées à l'
intérieur (par exemple, l'écriture CODEC n'utilise pas les mêmes
adresses, et il y a une routine pour chaque puce).
Pour ce que j'en ai compris, le développement à l'air bien avancé.
Support DSP, Midi, Mixer.. je ne vois pas ce qu'il manque.
La compilation s'est passée sans problème (ce qui est suffisament rare
pour être signalé.).
N'oubliez pas de lire le fichier "INSTALL", car il ne suffit pas de
faire un "./configure" suivi d'un "make install". Il faut également
créer des devices dans "/dev" (un script est fourni), insérer les
modules (bien entendu si le son est activé dans le noyau, ça marchera
mieux). Et éventuellement éditer "conf.modules" pour pouvoir utiliser
modprobe et ne pas oublier d'activer certaines cartes, qui sont en
mode "muted" par défaut.
D'ailleurs pour moi, c'est ce qui se passait: ma carte était "muted"
par défaut. J'ai pu vérifier avec un mixer, tout était à zéro. Le fait
de monter le volume des différents canaux ne changeait rien.
Dans la doc, on conseille de "démuter" (hum, je ne sais pas ce que
l'Académie penserait de ce néologisme) les canaux en utilisant "amixer".
Prudence, car la version "rpm" que j'ai récupérée du site ne marchait
pas. Il faut récupérer le source, et le recompiler (l'archive répond
au nom de "utils" avec un numéro de version).
Attention également, si "TkAlsaMixer" ne fonctionne pas, c'est que
"amixer" ne fonctionne pas. "TkAlsaMixer" est en fait un front-end pour
amixer, écrit en TCL/TK (il faut l'exécuter sous X, donc).
N'oubliez pas non plus de récupérer les libs pour compiler les sources.
En fait, je vous recommande d'aller sur la zone FTP du site, et de
reprendre les archives d'interet général (les libs, les drivers, les docs).
Pour les sources & les RPMs des utilitaires, c'est à vous de voir, mais
je vous recommande au moins l'archive "utils".
(note: "soundconfig.o.0" est bien sûr dans l'archive "libs")
Vous pouvez également vous contenter des drivers, et utiliser un mixer
déja présent sur votre système. Sous console, je vous recommende
"aumix" qui est excellent, et probablement présent dans toutes les
distributions. Il a notamment un front-end très pratique, mais on peut
bien sûr le glisser dans un fichier ".rc" pour le lancer par défaut avec
des paramètres.
Reste le problème des canaux muets par défauts.
Voici comment j'ai résolu ce problème.
Attention, ce n'est pas compliqué, mais si vous ne comprenez pas, ne
faites pas n'importe quoi! N'oubliez pas non plus que cette manipulation
empêchera tout "mutage" ultérieur à l'aide des programmes mixer: vous
pourrez mettre le son à zéro, mais la fonction "mute" de certains
programmes ne coupera plus le son.
Dans le répertoire source, allez dans le sous-répertoire "include", et
éditez le fichier "mixer.h".
Recherchez la ligne suivante, et commentez la.
" #define SND_MIX_MUTE (SND_MIX_MUTE_LEFT | SND_MIX_MUTE_RIGHT) "
A la place, insérez la ligne suivante:
" #define SND_MIX_MUTE 0 "
Vous pouvez ensuite compiler les modules.
Pour tester la carte, le "cat sample.au >/dev/dsp" donne également des
résultats bizarre. Par contre, ici un simple "play sample.au" vous permettra
de convertir le sample, et de vérifier que tout se passe bien.
Si vous obtenez un message du genre "can't open /dev/dsp", vérifiez que
le module "snd-pcm1-oss" est bien présent en mémoire. Théoriquement, si
vous faites le chargement avec modprobe, il devrait y être.
------------------------------------
3) Overclocking: problèmes éventuels
------------------------------------
(Ce pararagraphe a été écrit par Sébatien Caille.)
Un éventuel petit ajout à la doc sur les SB pci ...
Il semble que ce soit valable pour les chipsets 1370 et 1371
Description du problème:
le drivers (module) se charge une premiere fois sans message d'erreur,
mais aucun son ne sort.
En faisant rmmod es1370 ; insmod 1370 on obtient le message "es1370:
write to codec register timeout"
Solution :
Dans le bios, augmenter la valeur de l'option "PCI Latency Delay" (16
chez moi - pas testé avec moins)
Information sur mon hardware:
Ce problème arrive avec des SB pci 64 et 128. Ma carte mere est une asus
P/I-55T2P4 avec un processeur 166MMX overclocké à 187. je n'ai pas
d'informations sur d'autres config ayant eu ce probleme.
* fréquence du bus = 66Mhz, multiplicateur d'horloge = 2.5
=> un cpu à 166 Mhz.
* valeurs de l'option "PCI Latency Delay" : conséquences
16 => tout marche bien.
8 => pas de messages d'erreur 4 fois / 5, mais le son marche rarement.
12 => un peu mieux que 8, mais encore des problèmes.
* J'ai ensuite overclocké le processeur
=> fréquence du bus = 75 Mhz, multiplicateur d'horloge = 2.5
=> un cpu à 187 Mhz
* valeurs de l'option "PCI Latency Delay" : conséquences
16 => tout marche bien
8 => pas de messages d'erreur, mais le son marche rarement
4 => pas de message d'erreur, mais pas de son non plus.
Je n'ai pas pu modifier le multipplicateur d'horloge, car le processeur est
"bloqué".
(on ne peut pas mettre un multiplicateur d'horloge > 3 sur certains Intel 166)
Commentaire:
Le problème a été résolu sur deux machines de cette manière. Si le bios ne
contient pas l'option nécessaire, prier et chercher une autre solution. ;-)
En espérant que cela puisse aider quelqu'un...
-------------
4) Conclusion
-------------
La carte semble assez efficace, et le blindage est excellent (je n'entend
plus l'activité de mon PC comme avec ma vieille compatible SB ISA).
Le fait de passer en PCI permet de gagner un peu de vitesse, du moins sous
Linux. Voici un petit comparatif entre mon ancienne compatible SB ISA, et
la SB PCI 64.
* Sous Windows, pas de différence de monopolisation du CPU lors de la
lecture d'un MP3. Une chose étrange est que la charge machine varie
de 3% à 25%, sans raison apparente (Internet Explorer semble
responsable d'une certaine déstabilisation du système, et une page
HTML un peu chargée provoque des sifflements horribles dans la
musique).
Je précise que j'ai un K6/200 avec 64mo.
* Sous Linux: avec mon ancienne carte et x11Amp 0.7, un coup de "top"
me donnait environ 9% / 11% d'occupation CPU. Avec la SB64, j'ai 1%
maximum d'occupation, et souvent 0.5%. C'est assez étonnant quand
même !!
mpg123 passe à 17% d'occupation, contre .. la même chose auparavant.
Bien sûr, la page Web qui posait problème sous windows ne pose plus
problème, même avec ce monstre qu'est Navigator (je ne la regarde
pas sous Lynx, ça ne serait pas équitable :)).
Pour conclure, je ne résiste pas à l'envie de vous livrer un petit
extrait de la doc de la SB64:
"La nouvelle carte AudioPCI utilise une découverte technologique
capitale, qui tire le maximum de l'architecture du bus PCI (...)"
Ils ne manquent par d'air, quand même.
Avril 99
Jean-Seb Lebarbier (jseb@linux-france.org)