Emile “iMil” Heitor ’s home

Pour ne plus avoir de soucis de monopolisation de carte son par JACK, j’ai ajouté une carte dans ma machine principale et l’ai intégralement dédiée à cette utilisation. Problème, fonction de l’ordre de chargement des modules lors du boot de la machine, cette derniere est tantot associée en Card 0, tantot en Card 1. On trouve la solution à ce problème sur le Wiki d’Alsa, et plus particulièrement dans le topic MultipleCards. En ajoutant ces deux petites directives :

options snd slots=snd_hda_intel
alias snd-card-0 snd_hda_intel

au fichier /etc/modprobe.d/alsa-base d’une Ubuntu, on s’assure que la carte dont le driver est snd_hda_intel sera toujours associée au slot 0. Ainsi, tous les évenements sonores “habituels” utiliseront le slot 0 par defaut, et on affectera le slot 1 à JACK et toutes les applications l’utilisant.

Il suffit alors de recharger les modules alsa via la commande :

$ sudo alsa force-reload

et tout devrait rentrer dans l’ordre.

Après des mois de fixes plus ou moins hasardeux, j’ai enfin trouvé la methode infaillible pour regler définitivement les problèmes liés à cette… bref, la solution :

$ sudo rm -f /etc/asoundrc
$ sudo apt-get remove pulseaudio*

Cette dernière action effacera également la dépendance ubuntu-desktop, mais cela n’a aucun impact.

Virer toutes les références à pulse potentiellement présentes dans vos ~/.asoundrc et .asoundrc.asoundconf, puis dans System->Preferences->Sound, dans la section Devices, tout passer à Alsa.

On reboote histoire de tout remettre d’equerre, et HOPLAAaaa, dégage vieux “framework sonore” foireux.
Tout refonctionne par-fai-te-ment.

Il y a quelques jours j’ai entrepris d’encoder mes centaines de k7 audio (mais si, vous savez, ces trucs là : ) au format numerique. J’ai evidemment pensé à la methode que j’utilisais par le passé pour encoder des mixes live :

sox -r 48000 -c 2 -t ossdsp -w -s /dev/dsp -t wav - | lame - bla.mp3

Mais après quelques essais qui semblaient pourtant bien se passer, je constate que de temps en temps le son “saute”. C’est alors que je trouve quelques pages qui parlent de arecord, un recorder pour alsa, puis que je tombe sur cette page. Ce qui nous donne :

arecord -f dat -t raw -c 2 -D dsnoop | lame -x -s 48 - test.mp3

Et c’est un peu bien.

j’ai enfin upgradé vader. 5 ans de bons et loyaux services tout de même. J’ai pas dépensé une fortune, cette machine ayant pour rôle principal de streamer du son / de la video dans la maison. Pour un budget de 130 euros, me voici donc en possession d’une carte mère K7S41GX sur laquelle trône un AMD Sempron 2400, le tout alimenté par un gros bidule noir. Rien de démesuré, mais amplement suffisant pour les besoins sus-cités.
L’OS de cette machine, une fois n’est pas coutume, est un Linux, la fameuse Debian que je traine depuis 6 ou 7 ans. Le kernel est un 2.4.27.
De manière générale, rien à redire, tout fonctionne impeccablement, la carte mère intègre un chip son, reseau et graphique (je ne me sers pas de ce dernier par contre, c’est un truc moisi de survie). Voici les modules adequats :

. sis900 pour le réseau
. i810_audio

Une petite parenthese sur ce dernier: ne vous emmerdez pas avec alsa. Après 24h de lutte et des resultats pathétiques, j’ai découvert que le chip sonore :


0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0)
Subsystem: Unknown device 1849:7012


Était parfaitement supporté par le module i810_audio.
Rien de passionnant dans ce post mais ça évitera peut-être à certains de reveiller le voisinage à cause du driver alsa snd-intel8×0 qui est infoutu de controler correctement le mixer.

update en echo au commentaire, le driver i810_audio ne semble pas non plus permettre de modifier le volume de cette #@!#@! de carte. J’ai collé une bonne vieille sb live, plus de soucis.