Vous n'êtes pas identifié(e).
... J'ai également été faire un petit tour dans Système->Préférences->Son, et là tout fonctionne normalement, sauf quand je branche les enceintes, où dans ce cas plus rien ne fonctionne !
Hors ligne
Dernière modification par Asmodée (08-11-2010 19:50:29)
Hors ligne
il semble que ma sortie master soit uniquement en mono... En général il y a même deux sorties master : master ET master mono....
Oui, vérifié sur trois machines architecture x86 32 bits ici.
PS : si je mute le master, je n'ai plus de son du tout (et si ce n'était pas clair, je n'ai pas deux chanels "master" et "master mono", uniquement "master")
Comme si le système ne connaissait qu'un seul mode donc. Il y a deux haut-parleurs dans cette machine?
Sur cette page le support son est décrit comme assuré à partir du noyau 2.6.13, et la machine n'est pas toute jeune (2005-2006 environ?). Ce qui est curieux AMA c'est de n'avoir qu'un seul canal master. Ça correspondrait à une utilisation mono (une seule voie Droite ou Gauche) du circuit son par le driver?
Sur la même page il est dit de télécharger le dernier driver depuis le site de realtek; je n'ai pas réussi (après validation des conditions de chargement de "AC'97 Audio Codecs" on tombe sur une page avec juste un lien qui renvoie à la page de départ) mais j'ai trouvé la dernière version sur touslesdrivers.com. La version est récente (Septembre 2010) et contient:
$ ll realtek-linux-audiopack-5.15/
total 5488
-rw-r--r-- 1 tux12 tux12 3329991 sep 21 09:07 alsa-driver-1.0.23-5.15rc15.tar.bz2
-rw-r--r-- 1 tux12 tux12 808271 sep 20 09:58 alsa-lib-1.0.23.tar.bz2
-rw-r--r-- 1 tux12 tux12 326504 sep 20 09:58 alsa-plugins-1.0.23.tar.bz2
-rw-r--r-- 1 tux12 tux12 1076937 sep 20 09:58 alsa-utils-1.0.23.tar.bz2
-rwxr-xr-x 1 tux12 tux12 2650 sep 20 09:58 install
-rw-r--r-- 1 tux12 tux12 2057 sep 20 09:58 Readme.txt
-rw-r--r-- 1 tux12 tux12 42936 sep 20 09:58 test.wav.bz2
-rwxr-xr-x 1 tux12 tux12 23 sep 21 08:33 version
Ceci n'est pas immédiatement exploitable sous Debian (alsa-driver et alsa-lib semblent être dans alsa-base sous Debian).
Vu qu'il y a des mises à jour récentes du driver par le fabricant (au moins une autre depuis la sortie de Lenny en Stable), Il me paraît possible à ce point que le problème d'Alicia n'ait été corrigé que tardivement.
Peut-être qu'au final, il va falloir songer à passer en Squeeze.
Pour cela, faire une ré-install, pas une mise à jour. Il faudrait je pense ensuite rapidement vérifier si on dispose bien de "Master" et "Master M" cette fois.
Sinon il reste à se bricoler un adaptateur stéréo male <-> stéréo femelle en câblant les deux points chaud de la prise femelle sur le point chaud terminal de la prise mâle. (je n'ai pas trouvé sur le net)
Pas d'autres idées ...
Bon courage
@+
Peut-être qu'au final, il va falloir songer à passer en Squeeze.
Pour cela, faire une ré-install, pas une mise à jour. Il faudrait je pense ensuite rapidement vérifier si on dispose bien de "Master" et "Master M" cette fois.
Pourquoi donc réinstaller?? On est pas sur Windows ni sur Ubuntu que diable !!!
Un upgrade propre et sécurisé est parfaitement possible en prenant soi d'éviter les bugs de la mort qui tuent. Ce sont les derniers bogues qui posent encore de réels problème et encore ils ne concernent que l'upgrade Lenny >> Squeeze.
Il se trouve que la solution est somme toute assez simple:
1. Ajouter les sources des backports Lenny dans les dépots:
On met à jour les dépots:
2. On commence par installer le noyau le plus réçent ( qui lui seul supporte la nouvelle version de udev ):
où ARCH correspond à l'architecture de la machine et X à un n° de version.
/|\ On ne doit surtout pas faire de dist-upgrade immédiatement, sinon on se re trouve avec un système suɐs snssəp ı̣u snossəp !!!
3. On redémarre sur le nouveau noyau.
4. Maintenant on ajoute les sources Squeeze au fichier /etc/apt/sources.list:
5. On met à jour:
6. Et maintenant on migre:
Et au prochain démarrage on est sur une Squeeze toute propre et parfaitement utilisable.
Testé et approuvé. (merci à cluxter sur debian-fr d'avoir trouvé la solution )
Le seul détail qui puisse me faire préférer la réinstallation c'est le passage au système de fichiers ext4 et c'est un point non négligeable
Dernière modification par Clem (10-11-2010 23:15:39)
Moi, je suis PC (x86_64) et formater windows, c'était MON idée
Le sommeil de la raison ...
Hors ligne
Pourquoi donc réinstaller??
Ben simplement parce que c'est la méthode à utiliser de préférence, d'après cette page du manuel (section .2.3.5. Mise à jour pour l’ensemble du système)
Note
Lors du changement vers une nouvelle version, etc., vous devriez envisager d'effectuer une installation propre d'un nouveau système même si Debian peut être mis à niveau comme décrit ci-dessous. Ceci vous donne une chance de supprimer les résidus amassés et vous présente la meilleure combinaison des derniers paquets.
Glop?
Dernière modification par anonyme (09-11-2010 02:45:41)
Dernière modification par Clem (09-11-2010 02:52:16)
Moi, je suis PC (x86_64) et formater windows, c'était MON idée
Le sommeil de la raison ...
Hors ligne
PS: Par contre la solution donnée plus haut est *indispensable* ( pour le moment ) pour ceux qui doivent upgrader sans pouvoir réinstaller
À retenir donc. Post marque-pagé. (mot accepté par le correcteur orthographique )
Merci
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Une petite question me turlupine l'esprit : quels sont les avantages d'un système de fichiers en ext4 ? (c'est peut-être évident pour vous, mais moi ça m'échappe totalement )
Pour quelqu'un qui utilise un disque flash (SSD), EXT4 est le système de fichier de choix avec certaines modifications :
1) Activation de l'option discard
2) Suppression de la journalisation (en étant toujours plus sûr et plus efficace que EXT2)
3) Suppression de l'autodéfragmentation
Pour quelqu'un faisant usage d'un disque traditionnel (PATA ou SATA), je recommanderais, à l'installation, l'usage de ReiserFS ou XFS (entre autres) à la place de EXT3. EXT4 s'ajoute maintenant à cette liste mais n'est pas obligatoire, ni même mieux, pour la plupart des usages.
Pour répondre vraiment à ta question, pour un disque traditionnel, EXT4 est mieux car plus récent (il y a eu pas mal d'avancées depuis EXT3 et ReiserFS). Mais, selon moi, et pour la quasi totalité des utilisations, cela ne vaut pas le coup de réinstaller pour passer en EXT4 :
ReiserFS et XFS se comportent très très bien et EXT3, bien qu'un peu plus ancien, peut être mis à jour vers une version allégée de EXT4.
D'autre part, j'utilise encore un peu windows pour certaines tâches "professionnelles" (du matlab et autres outils scientifiques...), et donc j'ai besoin d'une totale compatibilité entre les formats windows et linux... Cela marchant pour le moment parfaitement, ça m'embête de tout réinstaller si ça peut risquer de tout planter... quoique l'idée d'un système tout neuf soit très alléchante
Matlab fournit une version GNU/Linux : il me semble même qu'il fournit des DEB en plus des RPM. Si tu as un système avec 4Go de RAM ou plus, utiliser matlab sous GNU/Linux peut largement te faciliter la vie. Le binaire GNU/Linux devrait être gratuit (si tu as payé ta license bien sûr).
Sinon, si tu n'as pas besoin des quelques toolbox de derrière les fagots fournies moyennant finance pour matlab, je te conseillerais de regarder du côté de Octave ou Scilab (présents dans les dépôts Debian). Il me semble que les deux (en plus de reprendre la syntaxe de matlab te permettent une interopérabilité presque parfaite.
Pour ma part, étant pythoniste, je te conseille chaudement le quatuor infernal ipython, scipy, numpy et matplotlib (faire appel aux différentes bibliothèques via pylab. Avec ça, tu peux faire tout ce que matlab fait, et même plus (python ne se limite pas au calcul scientifique).
Bref, après le coup de pub, la mise à jour ne devrait rien casser si tu suis les instructions données plus haut. Tu ne perdras pas en "compatibilité"... Tu devrais même en gagner...
Pour le système neuf : crois-moi, j'ai toujours été déçu les premières fois, quand j'avais encore la mauvaise habitude de tout réinstaller. En plus de perdre mon temps, le résultat est médiocre : que je réinstalle ou pas, j'obtiens le même système, toujours aussi rapide et réactif ; la réinstallation n'a eu aucune vertu, sauf m'obliger à tout reconfigurer.
Clem, pour l'upgrade, je n'ai qu'à faire ce que tu décris dans ton post ? (pas besoin de désactiver grub puis réactiver après l'upgrade par exemple ?)
quand tu dis ajouter les sources squeeze, dans mon sources.lst, je dois remplacer tout ce qu'il y a par tes deux lignes de dépots ou seulement les ajouter à ce qu'il y a déjà dans mon fichier ?
Oui, pour l'upgrade, ça devrait aller. Rien à faire avec Grub.
Tu rajoutes les lignes en question à la fin de ton fichier source.list et tu mets à jour les dépôts via sudo aptitude update et seulement ça (ou alors, dans Synaptic, tu cliques sur "Recharger", c'est TOUT). Puis tu installes le nouveau noyau tel qu'indiqué par Clem, tu redémarres pour utiliser ce nouveau noyau (verifie bien que c'est ok dan GRUB), puis, une fois sous le nouveau système, il ne reste qu'à mettre à jour (cette fois-ci, en cliquant sur "recharger", puis "mettre à jour" puis "appliquer". Tu vérifies que tout semble ok, et tu valides ).
je suppose que ARCH correspond dans mon cas à i386 ??
Soit i386, soit amd64 (à retrouver avec "uname -a")
Juste une réflexion : aujourd'hui, il n'y a presque plus aucune raison de ne pas passer en amd64.
Mais là, pour faire le changement sans réinstaller (ce qui est parfaitement possible), c'est plus compliqué.
Hors ligne
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Moi, je suis PC (x86_64) et formater windows, c'était MON idée
Le sommeil de la raison ...
Hors ligne
Ici : /usr/share/doc/alsa-base/driver/HD-Audio.txt.gz (v 1.0.23-3)
Section :
***Speaker and Headphone Output***
Il existe apparement des solutions à ton problème. Mais hélas, elles demandent une recherche spécifiques propre à ton matériel.
Le problème d'ailleurs n'existe plus sur un noyau 2.6.35 (Rappel : Squeeze = 2.6.32).
Personnelement, je ne garantirais pas qu'un update vers squeeze apporte une solution réelle.:|
@+
Dernière modification par zoroastre74 (10-11-2010 01:01:02)
Hors ligne
Hors ligne
Oui et non !!!
Le rôle d'Alsa est aussi de configurer au mieux les pilotes de la carte son détecté par le bios et le noyau en fonction de leur implémentation totale ou partielle. En géneral, ça se passe assez bien, mais comme dans notre cas présent, ce n'est toujours vrai.***
Personnelement, pour Alicia, j'espère me tromper, et serais heureux que son problème se resolve grace à une mise à jour.
Voici l'extrait du fichier cité dans mon précedent commentaire et qui me laisse à penser que rien n'est joué (Squeeze) :
Speaker and Headphone Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One of the most frequent (and obvious) bugs with HD-audio is the
silent output from either or both of a built-in speaker and a
headphone jack. In general, you should try a headphone output at
first. A speaker output often requires more additional controls like
the external amplifier bits. Thus a headphone output has a slightly
better chance.
Before making a bug report, double-check whether the mixer is set up
correctly. The recent version of snd-hda-intel driver provides mostly
"Master" volume control as well as "Front" volume (where Front
indicates the front-channels). In addition, there can be individual
"Headphone" and "Speaker" controls.
Ditto for the speaker output. There can be "External Amplifier"
switch on some codecs. Turn on this if present.
Another related problem is the automatic mute of speaker output by
headphone plugging. This feature is implemented in most cases, but
not on every preset model or codec-support code.
In anyway, try a different model option if you have such a problem.
Some other models may match better and give you more matching
functionality. If none of the available models works, send a bug
report. See the bug report section for details.
If you are masochistic enough to debug the driver problem, note the
following:
- The speaker (and the headphone, too) output often requires the
external amplifier. This can be set usually via EAPD verb or a
certain GPIO. If the codec pin supports EAPD, you have a better
chance via SET_EAPD_BTL verb (0x70c). On others, GPIO pin (mostly
it's either GPIO0 or GPIO1) may turn on/off EAPD.
- Some Realtek codecs require special vendor-specific coefficients to
turn on the amplifier. See patch_realtek.c.
- IDT codecs may have extra power-enable/disable controls on each
analog pin. See patch_sigmatel.c.
- Very rare but some devices don't accept the pin-detection verb until
triggered. Issuing GET_PIN_SENSE verb (0xf09) may result in the
codec-communication stall. Some examples are found in
patch_realtek.c.
@+
Ps : http://packages.debian.org/search?searc … g&arch=any
Dernière modification par zoroastre74 (11-11-2010 00:53:21)
Hors ligne
Hors ligne