- Mike89 a écrit:
- Il y a une autre solution finalement ICI
... brancher un microphone !
- Veldrin a écrit:
- Ben, non, parce que j'ai toujours l'ensemble casque et micro branché.
Pas grave, je me suis ruiné avec une super carte son à 19,90 € et ça fonctionne, alors ...
J'insiste...
Je te rappelle l'image de ta config dans le gestionnaire Realtek pour "High définition Audio" (que ce soit un pilote Realtek ou Microsoft...) :
Image dans ton autre sujet... la 2èmeEt aussi : lien direct image
Il n'y avait pas d'onglet relatif à la présence d'un microphone dans le gestionnaire en question !!!
J'ai aussi ce genre de gestionnaire et le microphone intégré apparait dans un onglet séparé. Si je branche un micro sur l'entrée microphone externe, celui-ci apparait, et cela désactive le micro intégré...
Le problème peut (je ne peux pas tester, cause micro intégré, cela marche toujours chez moi... et je ne vais pas le démonter) venir de l'option "Paramètre avancés du periphérique" :
Deux boutons radio avec :
* Lie ensemble les jacks d'entrées du même type... bla bla bla
* Sépare tous les jacks d'entrée comme des périphériques d'entrée indépendants.
J'ai sélectionné l'option "sépare..."
En branchant un microphore externe, j'ai constaté :
1) L'apparition d'un message au niveau de la barre des tâches (venant du haut parleur orangé) : "INFORMATION : une prise jack a été branchée".
2) Cela a activé en surbrillance dans le panneau du gestionnaire l'image de la jack d'entrée analogique rose (microphone)...
3) Un nouvel onglet microphone est apparu (donc j'avais deux onglets microphone : l'interne et l'externe)
Je me suis amusé à débrancher ce microphone et les phénomènes inverses sont apparus (Info : une prise jack a été débranchée, la jack n'était plus en surbrillance, et l'onglet du micro supplémentaire a disparu)
J'ai refais cela plusieurs fois, et... tantôt le microphone était à nouveau détecté, tantôt pas.
J'ai aussi essayé de brancher la jack micro sur la prise casque... et cela a activé la jack d'entrée casque...
... et parfois pas.
Même type de test idiot avec la jack casque sur la prise microphone... et même résultat versatile... (Hem... y a t-il un risque de "détérioration" du matos en faisant çà... je suis pas électronicien, mais je suppose que c'est prévu, les jacks n'ayant pas de détrompeur
)
DIAGNOSTIC : le gestionnaire audio DD ne détecte pas toujours le microphone que vous avez branché. Et on peut avoir des faux négatifs (pas détecté alors qu'il est présent)... en ce qui concerne des faux positifs, je ne peux pas conclure, du fait de la présence de mon microphone intégré qui est toujours présent.
Conclusion : dans le cas "Veldrin" : il n'y avait pas de microphone détecté c'est sûr, puisque aucun onglet microphone est présent. Une seule Jack semble être en surbrillance : la ou les vertes (pas clair sur l'image...)
Comme tu affirmes avoir branché un microphone, et que je pense que tu ne t'es pas trompé de jack... il est possible que le gestionnaire n'ait pas détecté ton microphone, puisque j'ai constaté moi même que c'était possible.
Donc voici la cinématique de fonctionnement (cela repose sur des règles ou protocoles d'erreurs...) :
* le modeur clique pour avoir une new info de dialogue
* cela déclenche le mécanisme d'ouverture :
** renseigne la ligne *empty du tableau info
** collecte les infos avant ouverture de la fenêtre New Response
Ce qui suit est supposé :
* le tescs demande certaines vérif matérielles
* sans micro branché, sur du matériel avec XP et sans doute pas ce mic mac "High Definition Audio" et le gestionnaire qui va avec, il n'y a pas de pépin (à vérifier...)
* Il semble que ce soit lié : soit à vista ou seven, soit aux pilotes High définition, soit au gestionnaire audio dd, soit à un défaut de détection des jack... soit xxx
Il me semble que plus un système de détection veux être "futé", puis il accroit les risques de bug (cas du train qui démarre pas à cause des portes qui ferment pas, mais qui sont fermées quand même)...
Je suppose que, autrefois, pour dire qu'il y avait un micro, on se contentait de vérifier qu'il y avait un pilote pour çà...
Mais que comme chacun sait, ce n'est pas parce que l'on voit un pilote que le matériel correspondant est présent (les pilotes d'avion vont parfois faire leurs courses en uniforme et en voiture... pas en avion
).
Je devine que les règles de détection et les réponses possibles ont été affinées et véhiculées des pilotes vers Directx et Windows (et via l'api vers le programme demandeur)... afin d'être "User friendly". Autrefois si on avait pas de son, les "nuls" devaient apprendre à vérifier s'il avaient coché ce qu'il faut dans la table de mixage, puis qu'un microphone ne se branche pas n'importe où... mais aujourd'hui on aspire à avoir une message clair donnant l'endroit exact de la rupture de la chaine d'information : "Ti La Li : branchez votre microphone dans la prise rose"... "Branchez..." "Ploum ploum ploum : vous vous êtes trompé de prise ; retirez de la bleue et ... dans la rose..."
!. Et forcément, le TESCS se moque que ce soit branché dans la bleue ou la rose... Il veux une liste de périphériques.
Un programme écrit selon les normes plus anciennes ne peuvent pas exploiter toutes les réponses possibles des pilotes et gestionnaires actuels (même s'ils sont bien écrit et que les détecteurs fonctionnent bien, ce qui n'est pas sûr !)... d'où la traduction des nouvautés en "codes" exploitables selon les anciennes règles. Si cette traduction en "mode compatibilité" est mal faite et laisse passer des codes inconnus du programme, il y a de forts risques de plantage...
En fait, le tescs a besoin de savoir s'il y a une ou des possibilités d'entrée son, pour permettre d'activer l'accès au bouton "configure" de la fenêtre "New response". Idem pour modifier une "response" existante.
Lorsque la fenêtre s'ouvre bien (le plantage est juste avant), on a bien le bouton Configure, qui ouvre la fenêtre "Select Audio Capture Device".
Il est possible alors de choisir la source son : microphone, capture via la table de mixage (wav, midi...) etc...
Le bug apparait donc avec des "pilotes et gestionnaires" trop sophistiqués... qui "stressent" le TESCS, à cause d'une mauvaise compatibilité ascendante des messages... le fameux mode compatibilité de Vista (et aussi celui de Seven qui existe sans le dire...).
Je viens de voir passer sur mon portable équipé Vista une mise à jour pour février
facultative du mode compatibilité (KB976264) pour Vista (mais aussi seven...) : une liste impressionnante de logiciels ainsi débloqués : Support Microsoft KB976264 mais je n'ai pas vu le TESCS dans la liste.
A suivre donc : les mises à jour de compatibilité Windows et des pilotes et gestionnaires... du moins pour ceux qui ont encore des problèmes de saisies d'info avec plantage.
Désolé, mon message est un peu long !
Edit : j'ai renommé le sujet pour qu'il soit plus clair (ex Problème TESCS)