| 01-12-2009 12:01:23 | #1 | |
| Ruskov | "Non parce que là j'arrive plus à écouter CRADLE OF FILTH, et c'est trop bad..." donc petit topic a l'usage de moi pour le moment mais aussi pour ceux qui sont avide du savoir d'autrui (pour le moment Robin) sur le Son sous Linux. rappelle des faits : J'ai plus de son ! conflit entre pulseaudio et HDA intel. Robin me propose une option subversive : "met OSSv4 ou vire carement pulseaudio ! " certe mon ami, mais comment ? dis moi tout. et merci de ton temps. | |
| 01-12-2009 12:15:39 | #2 | |
| okhin | Quel est ton OS? ET dégage pulse audio, il chie dans la colle, te rajoute de la altence et, globalement, ça ne fonctionnes pas. Utilise plutôt alsa (pas la levure) en direct, avec des choses comme dmix ou autre. Normalement, ça fonctionne Out of the box. Pour virer pulseaudio, comme je et supposes sous Ubuntu, un petit sudo aptitude remove --purge pulseaudio Devrait faire l'affaire. Au pire, attrapes moi sous Wave, avec robin on devrait pouvoir réussir à te dépanner et à faire un truc un peu propre. Okhin | |
| 01-12-2009 12:20:50 | #3 | |
| okhin | Et sinon, (vu que je lit les topics par ordre anti chronologique). Pour l'archi, tu as, en général: hardware -> module -> API -> serveur de son Donc, il te faut un module/firmware alsa pour Intel (package -alsa-firmware à priori) d'une part, une API (donc soit OSSv4 non supportée officiellement dans le kernel), soit Alsa (le plus fréquent et documentée à l'heure actuelle). Et puis le serveur de son. ESD (celui de KDE je croit) fonctionen à peu près, pulseaudio ne fonctionnes pas (vire le, t'y gagne dans tous les cas). Pour le mixeur qu'il te manque avec Youtube, il te faut probablement alsa-utils, faire un /etc/init.d/alsa restart, et chercher à configurer ton fichier .asoundrc (keyword: dmix alsa flash). Okhin | |
| 01-12-2009 13:10:38 | #4 | |
| Robin des Ombres | bon, okhin a déjà donné des bonnes pistes ... je vais donc me contenter de compléter. Le son, comme pas mal de choses, fonctionne sur plusieurs couches. 1. le hardware 2. le kernel, qui contient des modules permettant d'accéder au hardware. les programmes causent avec les modules par le biais d'une API fournie par le module 3. éventuellement une couche intermédiaire, le serveur de son 4. les applis audio le truc, c'est que c'est le bordel. Couche 2 : accès au hardware ----------------------------------- il n'y a pas de consensus concernant l'accès au hardware son. à la place, on a au moins 4 manières d'y accéder - OSS, la très vieille version "deprecated" encore présente dans le kernel - ALSA, la technologie qui a remplacé OSS quand le contributeur principal d'OSS s'est cassé pour monter 4Front et vendre OSS *comme programme propriétaire* - OSSv4, la version d'OSS développée par 4Front, qui est repassée sous licence GPL dernièrement. - FAADO, spécifiquement dédié au matos son en FireWire Chaque outil a ses spécificités : - le vieux OSS est totalement dépassé. il n'est encore là que pour la rétro-compatibilité - ALSA est ce qui est utilisé le plus courrament, mais - l'API est extrêmement complexe - c'est un peu une usine à gaz (parait il) - ca tourne uniquement sous linux (pas sous BSD et les autres UNIX) - ca ne respecte pas certains principes fondamentaux d'UNIX - OSSv4 est techniquement très bon, mais souffre des bourdes "politiques" de son développeur principal, qui semble pas mal à l'ouest - FAADO est nickel, mais c'est juste pour le firewire, donc c'est particulier Couche 3 : serveur son --------------------------- Une appli peut envoyer le son en attaquant directement l'API ALSA/OSS whatever. Mais que se passe t'il si plusieurs programmes veulent faire du bruit en même temps ? C'est là que ça se complique, car il faut gérer le mixage des sources sonores. Certaines cartes son gèrent le mixage hardware. D'autres non. Pour celles qui ne gèrent pas ça, il faut faire le mixage au niveau software. Historiquement, ALSA gère mal ce point. Du coup, il a fallu rajouter un serveur son par dessus le kernel. Les applis se connectent à celui-ci plutot qu'à ALSA, il fait le mixage et il balance le son à ALSA. Aujourd'hui ALSA intègre nativement le mix software avec dmix, théoriquement tout bien configuré dès le début, mais j'en suis pas tout à fait convaincu. Donc, c'est dans ce merdier que pleins de serveurs son ont été développés : Arts, ESD, Pulseaudio, Jack ... j'en oublie probablement. Sauf que OSSv4, qui est techniquement très bon, gère le mixage hardware/software de manière totalement transparente, directement dans le kernel, ce qui est un progrès notable sur tout le fatras susmentionné. Couche 4 : les applis audio ------------------------------- Devant tout ce bordel, comment les applis audios peuvent s'en sortir ? Vu qu'il n'y a pas de consensus, les développeurs doivent supporter autant de backends que possible, pour que leur appli puisse tourner dans n'importe quelle situation. Du coup, tu as encore une couche software supplémentaire : des bibliothèques telles que libao, Gstreamer (qui fait bien plus que ça mais c'est hors sujet) permettent au développeur de supporter tout ce bordel de manière à peu près transparente. ----- Et Voilà, maintenant tu sais pourquoi c'est la merde ! Donc, pour ton problème, tu peux effectivement dynamiter pulseaudio pour attaquer directement ALSA (+dmix). Si tu as des problèmes, tu peux tenter de dynamiter ALSA et de remplacer tout ça par OSSv4. | |
| 02-12-2009 00:18:55 | #5 | |
| Ruskov | youuuh ! merci les gars ! j'ai tout compris ! bon je fais faire tenter le yum remove --purge pulseaudio ou en tout cas ce qui va s'appliquer sur ma belle fédora. vu ma carte son, qui est une vrai carte et pas un chip collé sur la CM, je penche pour l'alsa. a toute. | |
| 02-12-2009 00:28:44 | #6 | |
| Ruskov | putain c'est même pas marrant c'est déjà réglé... plus de conflit puisque le yum erase (c'est la commande qui allait bien) a bien dévoré pulse audio. j'ai lancé vlc et deezer en même temps sa marche. pff les vidéos aussi. je me sens tout vide de soucis en ce moment c'est louche... bon beh je dois une bibine a okhin et un autre a Robin... plus une troisieme a pennangol mais il ne le sais pas encore. | |
| 02-12-2009 09:47:48 | #7 | |
| Blade | Oui c'est de plus en plus frustrant Linux : ça marche de plus en plus du premier coup et quand ça marche pas c'est de plus en plus facile de résoudre ça d'une seule ligne de commande qu'on trouve facilement sur internet. ... Y'a plus qu'à passer à BSD. | |
| 02-12-2009 10:18:22 | #8 | |
| okhin | ou à Hurd  Okhin - masochiste | |
| 02-12-2009 10:38:46 | #9 | |
| Robin des Ombres | tiens d'ailleurs, t'as déjà essayé hurd ? | |
| 02-12-2009 10:40:18 | #10 | |
| okhin | Yep, il y a un an ou deux. C'est trés sympa au niveau des concepts mis en place (je suis un grand fan du translator qui permets de faire un cat eth0 pour voir le traffic qui passe sur ta carte réseau par exemple). Cela dit, plus encore que BSD, ça te demande de réapprendre ce que tu sais sur le fonctionnement d'un système. Okhin | |
| 02-12-2009 17:03:40 | #11 | |
| burning-bones | Sur le fonctionnement du kernel juste, non ? Le reste, ca reste un environnement GNU. BSD ca t'oblige aussi à te défaire de tous les trucs pratiques que tu considérais comme acquis sous GNU (genre les options que tu peux placer sur grep, ps et qui sont pas présentes dans les Unix standards). Ton histoire de cat eth0 m'interesse... Ca te donne un format de sortie compatible tcpdump ? Tu peux mettre des filtres ? | |
| 04-12-2009 14:54:32 | #12 | |
| okhin | En fait, c'est le concept de translator. En gros, tu n'as pas de modules pour discuter avec ton matériel, tu as des translators. Ils traduisent donc des instructiosn fonctionnelles en instructions matérielles. Partant de là, il y a des translators type flesystem pour à peu près tout (c'est un des plus simple à écrire ce me semble). Mais rien ne 'tempêche de monter un translator tcpdump sur une carte ethernet (qui marchera sur tout périphérique, même i il n'aura d'intérêt que pour les périphériques tcp). Bref, c'est super fun, c'est juste un peu prise de tête au débt pour monter une carte réseau ou démarrer un serveur X. C'est un micro noyau quoi, ya rien dedans. Cela dit, en deux ans, le projet à du bouger. A essayer donc. Okhin | |
| 04-12-2009 15:14:52 | #13 | |
| Robin des Ombres | Je me suis intéressé un peu à HURD il y a quelques temps. de ce que j'en retiens, il y avait encore des problèmes conceptuels majeurs liés avec l'architecture en micro-kernel, qui génère un overhead et rend très difficile toute application temps réel. et en plus, depuis que HURD a été lancé, la recherche sur les micro-kernel a avancé, ce qui a provoqué au moins un changement de micro-kernel et des remous dans le développement. je me trompe ? | |
| 04-12-2009 15:20:42 | #14 | |
| okhin | Nope, ils ont changé de micro kernel (c'est le MACH je crois). ET puis bon, pour bosser sur HURD? il faut bosser avec RMS aussi hein Okhin | |
| 04-12-2009 15:27:32 | #15 | |
| Robin des Ombres | je viens d'aller voir sur la page officielle - HURD est en train d'être porté pour tourner sur L4. | |
| 07-12-2009 23:20:02 | #16 | |
| burning-bones | Ca a l'air bien classe de chez bien classe ce principe de translator. Pour le coup, tout est vraiment un (genre de) fichier, ca peut etre juste excellent à gérer. Plus qu'a attendre que ce soit "production proof"  | |
| 07-12-2009 23:21:59 | #17 | |
| okhin | Ouais, déjà, "test lab" proof, ça irait. Genre pouvoir avoir un X, un WM basique et un navigateur. Je croit que c'ets le cas cela dit (vu que, de toutes façon, c'est globalement juste une histoire de compilation et de system calls). Okhin | |
| 07-12-2009 23:27:26 | #18 | |
| burning-bones | Je sens que je vais me faire une VM Debian/HURD. Ca a l'air beaucoup trop amusant. | |
| 29-01-2010 11:57:04 | #19 | |
| Ruskov | bon certe c'est plus exactement dans le sujet mais le compte bien investir dans un casque à réduction de bruit actif parceque j'aime mes oreilles et la mizique et que merde 4 projo sa fait du barouf mine de rien (merde pu de mithril) heuu ... a oui est-ce que quelq'un saurait me dire où je peut trouver les spec de rédution sonore pour des casques en bluetooth ? partout ces tanches mettent "réduction de 99% des bruits de fond" mais en fait sa veux rien dire du tout sa... Quelle plage de fréquences ? quelle intensité moyenne/en crête ? Je eux une putain de courbe de réponse avant le lacher 100/200€ dans un casque ! le petit bh-905 de nokia est, non à l'air chouette comme tout, mais il y a le mm450 de schie... shien... schljqdslkjheir ! | |