Salut journal !
devant tant d'enthousiasme de la part des lecteurs de linuxfreu, je n'ai pas pu résister, j'ai installé Ubuntu. Voici le compte rendu de cette installation. (et oui encore un :) La machine est un portable sony vaio FR215E, avec un athlon 1,7GHz.
L'installation proprement dite ne pose pas de problème particulier. Je suis un habitué de debian, j'ai pas peur de l'installateur "non graphique" :). Au redémarrage, première surprise, le son ne marche pas :/ Enfin si, mais de manière assez surprenante : il faut bouger la souris (oui oui le périphérique de pointage) pour que le son soit joué. Sinon, il reste bloqué. J'hallucine totalement, c'est la première fois que je vois ça... Après investigation, c'est esd qui déconne, mais j'ai pas de solution.
Les fonctions de gestion de l'énergie : complètement à la masse le truc. J'ai installé ubuntu en particulier pour le support des portables, dommage... Indication de la fréquence du processeur : 0 MHz, 134 GHz ou 1083 GHz, ça doit chauffer la dedans ! Utilisation de la batterie : selon la jauge j'ai une autonomie de 20 minutes et il ne detecte pas le passage secteur/batterie. Le ventilateur tourne en permanence.
Il y a quand même des points positifs, gnome est bien configuré, le thème par défaut est bien clean (j'ai pas trouvé le monsieur et les madames déshabillés...). Le réseau s'est bien configuré (samba fonctionne nickel). Le démarrage est rapide, par rapport à ma sarge configuré comme un sagoin. Je n'ai pa pu la tester en profondeur, ces quelques problèmes m'empêchent d'aller plus loin.
Bref ça à l'air sympa, mais c'est un peu jeune je pense. Je m'en vais faire une rafale de rapport de bug. Si quelqu'un a une idée pour esd...
Pendant la rédaction de ce journal, j'ai eu une idée : la quenelle installé par défaut est nommée 2.6.8.1-3-386 c'est p't'être pour ça que l'acpi déconne. J'installe le k7 immédiatement et je vous tiens au courant. MaJ : aucune amélioration :/
Journal Compte rendu d'installation Ubuntu
28
oct.
2004
# esd suxor des ours népalais...
Posté par lesensei . Évalué à 4.
Pour le reste, c'est surprenant... CPUFreq et la gestion de l'energie marchent correctement sur ta debian ?
[^] # Re: esd suxor des ours népalais...
Posté par LeMagicien Garcimore . Évalué à 4.
J'ai chargé le module powernow_k7 et ça roule. Sur ma debian ça marchait bien aussi.
Merci pour polypaudio, je vais l'installer :)
[^] # Re: esd suxor des ours népalais...
Posté par jmf . Évalué à 10.
Pourquoi devrait-on avoir besoin d´un serveur de son ? On est en 2004, il serait temps que Linux fasse son boulot de système d´exploitation et virtualise le matériel pour qu´on ait pas à ce soucier de combien d´applications l´utilise en même temps. C´est ridicule qu´un système d´exploitation si moderne ait une gestion de son aussi archaique. Imaginez que deux applications ne puissent pas accéder au disque dur en même temps et qu´on doive passer par un "serveur de disque" !
Oui je sais Alsa fait cela quand le matériel le permet, mais il ne le permet pas toujours. Oui je sais, il y a le plugin dmix qui est censé pouvoir faire cela, mais ca ne semble pas etre souvent installé par défaut et configuré de manière générique.
[^] # Re: esd suxor des ours népalais...
Posté par scand1sk (site web personnel) . Évalué à -4.
[^] # Re: esd suxor des ours népalais...
Posté par Larry Cow . Évalué à 2.
Sur un OS qui, comme Linux, est encore largement utilisé dans l'embarqué et serveurs, ajouter ce genre de fonctionnalité directement dans l'OS est un peu limite. Passer par un outil en userland, parfaitement desactivable et non-intrusif pour le noyau, est tout à fait justifié. Et ca tombe bien, c'est justement ce que fait esd (mal, il est vrai, mais ce truc est complètement passé d'age).
[^] # Re: esd suxor des ours népalais...
Posté par Éric (site web personnel) . Évalué à 10.
Sur le serveur ce qui est en trop ce n'est pas le plugin de mixage du driver son, c'est le driver son tout court.
Pour ne pas voir le mixage au niveau de l'os il faudrait justifier d'une utilisation courante du son où le mixage serait vraiment "en trop". Et malheureusement je n'en vois pas beaucoup.
[^] # Re: esd suxor des ours népalais...
Posté par Nap . Évalué à -1.
[^] # Re: esd suxor des ours népalais...
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: esd suxor des ours népalais...
Posté par TheBreton . Évalué à 7.
Il gere le transport des données en wagon blindé d'un espace non-protege (userspace) a un monde de securite (kernelspace->carte hardware).
Le contenu des donnée qui transite n'est pas de ca responsabilité.
En reclamant (il y a de ca quelque temps en arriere) un serveur web, maintenant un mixer de son, demain une interface graphique dans le kernel on change de principe de fonctionnement et on arrive a un truc style windoxs.
Ou quand un truc annexe (jouer du son, jouer un film, jouer a doom3, ecrire son cv sous OOo...) plante alors tout le systeme est planter, le gestionnaire de disk decide que tout doit etre formater, la carte reseau de repeter a l'infini le dernier packquet envoyer et plein d'autre truc est joyeux.
Assurer la securite du systeme et des données est le role de l'os, l'interface graphique et tout le multimedia sert a occuper l'utilisateur sur la chaise en face de l'ordi deux chose differentes.
Enfin c'est mon avis, et j'abonde entierement dans le sens du thread que pour l'instant la gestion du son et des mixer sous linux n'est pas au top du tout. je ne suis simplement pas d'accord sur le faits de confier ce job au kernel.
[^] # Re: esd suxor des ours népalais...
Posté par jmf . Évalué à 6.
Merci de confirmer ce que je disais
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à 3.
La concurrence d'accès pour le son est gérée. Si la carte ne supporte qu'un son à la foi, il n'y en a qu'un qui peut utiliser la carte. Point barre.
Si t'as une carte TV, tu vas pas demander au noyau de permettre l'accès concurrent à la carte TV pour regarder en même temps TF1 et CANAL+ si t'as carte TV n'as pas deux tuner. Ça n'a pas de sens. C'est la même chose pour les cartes sons. Si au niveau noyau il n'y a qu'une sortie son ... alors il n'y a qu'une sortie son...
[^] # Re: esd suxor des ours népalais...
Posté par Nap . Évalué à 5.
voilà mon analogie à moi : une carte réseau ethernet. On s'en sert pour envoyer plusieurs flux TCP/IP, pour plusieurs applications à la fois, et c'est la pile TCP/IP du noyau qui gère tout ça, les connexions, les sockets et tout le tralala
alors pourquoi on fait pas ça avec les cartes son ?
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à 3.
Ben prends un terminal (sans screen), une carte graphique (sans _serveur_ x11) etc... si tu préfères.
> alors pourquoi on fait pas ça avec les cartes son ?
Rien à voir avec le réseau. Lorsque tu as une connexion réseau elle n'interfère pas avec le reste. T'as déjà mélangé t'as connexion linuxfr avec autre chose ?
Si la carte son a (par exemple) 3 sorties haut-parleur, il est logique (et c'est ce qui est _déjà_ fait) que le noyau mette à disposition des programmes 3 sorties. Si tu veux mélanger les entrées, ce n'est pas au noyau de faire ça.
Beaucoup de cartes sons ont plusieurs sorties (pcm) qui utilisent une seule sortie "physique". C'est le choix de la carte son. Ces cartes sons sont supportées et exploitées par les drivers alsa.
[^] # Re: esd suxor des ours népalais...
Posté par Ramso . Évalué à 2.
Mais quand j'ai dans mon noyau un module de gestion de ma carte son (interface matériel/logiciel, transport de données, tout ça) et que la dite carte gère le mixage elle-même (hardware mixer), la moindre des choses pour un pilote c'est d'exploiter les capacités de mon matériel !
Je suis bien content que le module emu10k1, pas celui d'Alsa mais OSS -- j'ai jeté Alsa depuis des mois --, gère le mixage matériel et de ne pas avoir besoin d'ESD ou de 300 surcouches à la Jack qui ajoutent de la latence.
Maintenant effectivement, la question se pose pour les cartes son qui ne proposent pas de mixer matériel : implémenter un mixer par pilote, un module de mixer générique, un daemon en userspace ? Tant qu'on jette ESD on aura déjà fait un grand pas. :-)
[^] # Re: esd suxor des ours népalais...
Posté par ckyl . Évalué à 3.
Hum et si on met arstd a la place tu dis quoi ? :-p
[^] # Re: esd suxor des ours népalais...
Posté par Nap . Évalué à 3.
Maintenant effectivement, la question se pose pour les cartes son qui ne proposent pas de mixer matériel : implémenter un mixer par pilote, un module de mixer générique, un daemon en userspace ?
en fait on a deux besoins :
- exploiter au mieux le matériel
- sortir le son de plusieurs applis
seul un logiciel en interaction directe avec le module de la carte son peut faire le mixage, pour être sur de ne pas sous-utiliser la carte son
[^] # Re: esd suxor des ours népalais...
Posté par ckyl . Évalué à 4.
Dis moi tu connais les modules noyaux et la recompilation pour adapter l'outil a ses besoins ?
Autrement FreeBSD (au hasard) qui est bien connu pour être un OS uniquement destiné au desktop ne pose aucun probleme de ce cote la depuis.... oula je sais meme plus
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à 2.
... J'ai même pas envis de répondre tellement ça me souâle comme remarque.
> On est en 2004
Merci pour l'info
> il serait temps que Linux fasse son boulot de système d´exploitation et virtualise le matériel pour qu´on ait pas à ce soucier de combien d´applications l´utilise en même temps.
Dans un OS, il y a deux partie. La partie utilisateur (par exemple esd) et la partie "basse", proche du noyau. Pour toucher ajouter des fonctionnalités à la partie "basse" du système il faut de SOLIDES raisons. Si le mixage peut-être fait un userland, il faut le faire un userland. Je n'ai pas envis d'un freeze système car le mixeur de son c'est mélangé les crayons. Ceci est vrai maintenant et sera toujours vrai en 2184.
> C´est ridicule qu´un système d´exploitation si moderne ait une gestion de son aussi archaique.
Tu juges alsa archaïque _uniquement_ car il n'y a pas de mixer par défaut. Bravo.
> Imaginez que deux applications ne puissent pas accéder au disque dur en même temps et qu´on doive passer par un "serveur de disque" !
Ou tu veux en venir ?
> Oui je sais Alsa fait cela quand le matériel le permet, mais il ne le permet pas toujours.
Si la carte ne le permet pas, alsa ne le permet pas. Je ne vois pas le problème.
> Oui je sais, il y a le plugin dmix qui est censé pouvoir faire cela, mais ca ne semble pas etre souvent installé par défaut et configuré de manière générique.
Voilà, on tombe sur un problème de configuration par les distributions et non sur l'OS (par basse). C'est beaucoup mieux.
Pour info, dmix n'est pas fait par le noyau mais pas la librairie alsa. Ça ne demande pas de "virtualisation" niveau noyau. Tant mieux.
PS : dmix sucks avec mplayer. Je ne sais pas pourquoi.
[^] # Re: esd suxor des ours népalais...
Posté par Nap . Évalué à 3.
si esd fait le mixage, il envoie un seul signal à Alsa, qui ne peut pas le démultiplexer pour profiter des capacités hardware.
C'est donc alsa qui doit recevoir tous les signaux et décider du multiplexage en fonction des possibilités offertes par le driver, non ?
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à 0.
Oui. Mais c'est quoi le rapport ?
Si tu dis que esd doit être amélioré pour utiler au mieux les multiples sorties de la carte son (fournis par alsa), je suis d'accord.
Sûr que le mainteneur de esd accèptera des patchs pour avoir cette fonctionnalité.
[^] # Re: esd suxor des ours népalais...
Posté par Nap . Évalué à 2.
Dans ce cas c'est possible de le faire en userspace effectivement
en ce qui concerne esd et tout ça, pour moi le plus gros problème est que je trouve ça complètement absurde qu'il y ait cinquante gestionaires de son.
Si tu veux faire une appli qui fait du son, il faut choisir lequel tu veux utiliser j'imagine.
Donc si tu veux que ton appli marche chez tout le monde, il faut faire plein de plugins, un pour chaque système.
Relou.
Si c'est le noyau qui faisait tout ça, il y aurait moins de problème à mon avis.
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à 1.
Gnome utilise gstreamer (qui utilise esd ou arts ou alsa ou OSS et bientôt mad).
La tendance de fond ("voulue" par freedesktop) est d'avoir gstreamer (qui n'est pas un serveur de son) et mad (qui est un serveur de son en cours de développement).
Donc si tu fais une applis "freedesktop" compliant, tu as le choix entre gstreamer et ... rien d'autre.
Mad permet d'avoir du son pour un post X11 distant. Alsa ne marche qu'en local.
[^] # Re: esd suxor des ours népalais...
Posté par Nap . Évalué à 2.
il a ses propres drivers ?
ou alors il l'utilise mais il fait en mieux une partie de ce que fait alsa ?
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à 0.
[^] # Re: esd suxor des ours népalais...
Posté par Ramso . Évalué à 2.
je préfère utiliser l'API d'Alsa que d'avoir à choisir entre l'API d'ESD, Artsd, Dmix, etc.
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à 1.
... puisque tu le dis...
Renseignes toi un peu avant de dire des conneries. Alsa (alsa-lib en fait) fournit dmix. Si tu mets dmix par défaut, tous les programmes qui utilisent le son en profite.
Exemple de /etc/asound.conf (ou ~/.asoundrc):
pcm.!default {
type plug
slave.pcm {
type dmix
ipc_key 1234
slave {
pcm "hw:0,0"
period_time 0
period_size 8192
rate 44100
}
}
}
Lance plusieurs applis en même temps qui utilise la sortie par défaut.
Ça marche et t'as pas à changer d'API.
alsa permet aussi d'attaquer chaque voie d'une carte son.
Exemple "tout con" ici :
$aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AudioPCI [Ensoniq AudioPCI], device 0: ES1371/1 [ES1371 DAC2/ADC]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AudioPCI [Ensoniq AudioPCI], device 1: ES1371/2 [ES1371 DAC1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: V8233Pre [VIA 8233-Pre], device 0: VIA 8233-Pre [VIA 8233-Pre]
Subdevices: 4/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
card 1: V8233Pre [VIA 8233-Pre], device 1: VIA 8233-Pre [VIA 8233-Pre]
Subdevices: 1/1
Subdevice #0: subdevice #0
J'ai deux cartes avec 2 sorties dont une avec multiplexage (4 voies).
Pour utiliser la seconde voie de la première carte j'utilise (pour aplay) :
aplay --device=hw:0,1 ...
Pour la seconde carte, je peux lancer en parallèle 4 "aplay --device=hw:1,0". Le cinquième attendra qu'une voie soit disponible.
Si ta carte n'a pas de multiplexage, utilise dmix (alsa-lib).
Donc alsa ROX et n'a pas de problème de conception. Par contre il manque peut-être une appli pour configurer asound.conf. Il manque peut-être à esd (ou n'importe quoi d'autre) de tirer profit des toutes les voies disponibles.
[^] # Re: esd suxor des ours népalais...
Posté par Ramso . Évalué à 2.
Ben tu imagines une bibliothèque utilisable par un seul programme à la fois ?
> Renseignes toi un peu avant de dire des conneries. Alsa (alsa-lib en
> fait) fournit dmix. Si tu mets dmix par défaut, tous les programmes
> qui utilisent le son en profite.
Effectivement j'avais perdu de vue que dmix fait partie d'Alsa, donc finalement tout va bien, c'est implémenté comme il faut : mixer matériel pour les chanceux, mixer logiciel pour les autres mais sans sortir d'Alsa.
> Si ta carte n'a pas de multiplexage, utilise dmix (alsa-lib).
Qu'est-ce que j'en sais ! Enfin si je le sais, mais pensons aux utilisateurs de Fedora ou Ubuntu.
> Par contre il manque peut-être une appli pour configurer
> asound.conf
C'est pour ça que j'ai viré Alsa, marre de me battre avec 80 canaux à régler et au moindre écart, plus de son !
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à -1.
Trop fort.
De tout manière, OSS sera viré du noyau Linux (à partir de la branche 2.7).
Et si OSS a été mis en obsolete depuis Linux 2.5, ce n'est pas car les développeurs linux sont des abrutis.
De plus, je ne serais pas étonné que tu utilises OSS via l'émulateur alsa. En gros tu utilises alsa sans le savoir...
Merveilleux la pertinence de tes arguments.
[^] # Re: esd suxor des ours népalais...
Posté par Ramso . Évalué à -1.
Qu'on joue au chat et à la souris sur Debian c'est une autre et je me suis vite lassé.
Mais que tu me reprennes systématiquement pour parler de conneries, d'arguments ou je ne sais quoi, faut arrêter !
J'ai pas à argumenter ou quoi que ce soit. Je fais pas une démonstration, je donne mon point de vue, je vis ma vie sur le site et si mes propos te plaisent pas, ben c'est con mais c'est la vie. Et je fais de même avec toi : les administrateurs pourront te confirmer que je t'ai rarement moinsé.
Je sais très bien ce qu'il en est d'OSS et d'Alsa et oui j'ai choisi de garder OSS et oui je suis un grand garçon et je sais ce que je fais et non je n'utilise pas les modules snd-*. Que ça te plaise ou non je continuerai comme ça jusqu'à ce que je trouve Alsa utilisable et j'ai traité personne d'abruti ; pourtant tu le mériterais.
Maintenant fous-moi la paix et va jouer ailleurs.
[^] # Re: esd suxor des ours népalais...
Posté par 007 . Évalué à -3.
[^] # Re: esd suxor des ours népalais...
Posté par gnumdk (site web personnel) . Évalué à 3.
Ah la bonne blague :)
Si je te dis que sous windows aussi y'a un serveur de son, tu vas trouvé que linux ca pue moins? :)
Tu me crois pas, ben install un windows 2003, Microsoft propose enfin de le désactiver dans le panneau de configuration...
# Des nouvelles du son
Posté par LeMagicien Garcimore . Évalué à 3.
J'ai installé polypaudio, mais il me balance un message d'erreur super clair quand il démarre :
génial...
J'essaye aplay (alsa player), et là surprise, le son est encore "bloqué" et le fait de bouger la souris le relance. Si j'arrête de bouger la souris, ça se bloque. C'est rigolo mais fatiguant pour ecouter de la musique. Le plus étrange est que xmms avec le plugin alsaout fonctionne bien.
C'est la 4ème dimension ce truc.
[^] # Désolé
Posté par Seazor . Évalué à 8.
Faut lester décontlasté.
Oui, c'est facile face a ce nick.
Ok, pousse pas, je sais sortir tout seul... --->[]
[^] # Re: Des nouvelles du son
Posté par Ramso . Évalué à 8.
[^] # Re: Des nouvelles du son
Posté par LeMagicien Garcimore . Évalué à 1.
# Move your hand !
Posté par WH (site web personnel) . Évalué à 1.
Jean Petit qui danssssse, Jean Petit qui dan-anse...
De sa main (sur la souris) il danssse, de sa main il danse !
Sinon, ben je comprends pas pourquoi on peut pas mixer 2 sons, on le faisait bien du temps des cartes sons interfaces sur le port parallèle (Covox rul3z) en soft, alors ?
Et puis c'est bien à Alsa de le faire, car si une appli utilise ESD et une autre OSS, c'est le bordel...
# Sony Vaio + Linux = mauvaise équation !
Posté par Gaeldîr . Évalué à 0.
Le problème, c'est que Sony n'est pas pour Linux, et fait des machines orientées Windows à un tel point que je les soupçonne de "bugger" leurs machines pour rendre une installation de Linux proprement impossible sur leurs portables !
Un ami à moi possède un Vaio également (avec un nom exotique, PGC machin truc muche), avec du matériel standard (P4M 2.4, GeForce Go, etc ...) et malgré çà, çà ne passe pas ...
Seule Suse 9.2 passe dessus, mais sans la 3D ...
Le problème vient de Sony :-) J'ai un portable Acer Aspire 1681 WLMi (basé sur un Pentium-M 715 avec Centrino et Wifi BG, Ati Radeon 9700 Mobile M11, etc ...) et je n'ai eu aucun problème pour installer Ubuntu (c'est de ce portable que j'écris en ce moment) car mon matériel a été détecté à 100%, est 100% fonctionnel ... Donc c'est une avancée considérable ... Même pour la fréquence CPU (j'ai bien les paliers de 600 MHz à 1.5 GHz en passant par 800, 1 G, 1.2 G) ...
Tes bugs ne viennent pas de la distribution proprement dite, mais plutôt de la mauvaise volonté que met Sony pour concevoir des produits compatibles avec tout les systèmes existants ... La mentalité "Sony" c'est "tout le monde fonctionne sous windows, alors on fait pour windows et c'est tout" !
Ne blâme pas Ubuntu, même si tu en crèves d'envie ^^ Et puis si ta Debian marche bien ... Garde-la ! ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.