parce que le monde entier utilise .doc(x) (aussi regrettable cela soit-il), et que OOo n'est pas capable d'ouvrir et imprimer correctement un tel document, et surtout de le modifier/enregistrer sans péter la mise en page et/ou la structure du document (sommaire, etc.), ce qui le rend impropre au travail collaboratif ? (N.B. accessoirement il ne sait pas ouvrir les document attachés en OLE, ce qui est très gênant dans mon quotidien)
parce qu'il bugge/plante toutes les 5 minutes, et qu'il est bien plus lent/lourd que la concurrence (y compris MSO) ?
parce que les thèmes par défaut sont moches ? (argument mineur pour moi mais majeur pour nombre de mes collègues)
…
A part le thème moche, je n'ai aucun de ces problèmes depuis très longtemps.
Quant à la lourdeur, LO tourne vraiment partout. Il est peut-être un peu lent (enfin c'est surtout des problèmes de boutons qui mettent 30 ans à se redessiner, du moins sous GNU/Linux), mais il ne plante jamais (depuis la série 4.X de LO j'ai pas vu un seul plantage).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Linux charge un pilote parce que le pilote lui dit "je supporte ce chip" en gros, si le pilote se loupe, boom.
Merci, mais c'est pareil sous Windows.
Si le pilote n'est pas une pilote HW mais un pilote qui se charge d'autre chose (filtre reseau, etc…), Linux le chargera, point barre et si ce pilote ne sait pas gerer une config differente, boom.
C'est pareil sous Windows.
Ton "Linux marche 9/10" c'est super, quand t'as 1 milliard de systemes comme nous ca veut dire qu'il y en a 100 millions qui vont peter. Autant dire que c'est inacceptable.
Le problème est que je n'ai jamais vu Windows fonctionner dans ce cas de changement de machine du disque dur principal.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Detecter un changement de config n'est absolument pas le probleme, Windows sait le faire depuis longtemps. Le probleme est de detecter que le driver qui est configure pour l'instant va peter sur ta nouvelle machine car c'est presque le meme chipset mais pas exactement, et le driver courant ne le supporte pas. C'est aussi detecter que le driver kernel qui vient avec ton soft X, sur lequel tu n'as aucun controle, va exploser en vol parce que la config du nouveau systeme est differente de celle de l'ancien et qu'il n'est pas capable de gerer le changement, etc.
Pour préciser, Linux charge un pilote différent si le matériel est différent.
Tous les pilotes (ou presque) sont fournis avec le kernel (kernel monolithique, tout ça).
Après Xorg c'est pareil à moins d'avoir forcé un pilote dans la configuration dans /etc/xorg.d/ (pour la carte graphique par exemple).
Windows, je lui change d'ordinateur (au sens je prends le disque dur et je le mets dans une autre machine), il plante quoi que je fasse (BSOD, même en mode sans échec).
Quand c'est pas Windows qui a décidé que la licence n'était pas respectée : http://support.microsoft.com/kb/305356
GNU/Linux, ça marche 9 fois sur 10. Et quand ça marche pas, on peut au moins accéder à la ligne de commande pour changer la config.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Et tu penses que dd ou rsync vont gerer tes drivers de l'ancienne machine qui vont faire planter la nouvelle par exemple ? (dans le cas d'un chipset legerement different par ex. ou un driver mal foutu qui ne fait pas de detection, etc…) Ils vont s'occuper de t'installer les drivers qui vont bien ? etc…
Linux (le kernel) sait très bien s'adapter à un changement de configuration.
Et Xorg aussi d'ailleurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
J'ai acquis Aquaria et Organ Trail il y a quelques mois sur Steam sous Archlinux, et je les recommande tous les deux chaudement !
Aquaria pour le côté poétiquement sublime, et l'histoire centrée sur une sirène découvrant sa civilisation disparue.
C'est un jeu qui se fera une place dans votre p'tit cœur !
Organ Trail pour le côté rétro, décalé, horrifique (un peu quand même, on parle de zombies), tout en restant très proche du gameplay de Oregon Trail qui est toujours aussi bon et aussi dur.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
C'est le cas pour n'importe quel codec ou presque (bon après ça dépend de la résolution et du FPS). 56 kbit/s, c'est de l'underflow (pas assez de débit pour encoder) ou vraiment pas loin.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Le VP8 est bien plus gourmand à décoder pour les décodeurs matériels (voir le lien)
One more thing to note is the data partitioning scheme used by VP8. This scheme is much like VP3/Theora’s and involves putting each syntax element in its own component of the bitstream. The unfortunate problem with this is that it’s a nightmare for hardware implementations, greatly increasing memory bandwidth requirements. I have already received a complaint from a hardware developer about this specific feature with regard to VP8.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Le H.264 est généraliste. Le x264 offre même des preset pour les sources qui ne sont pas des films.
Le VP8 d'ailleurs c'était au départ présenté comme un concurrent sérieux au H.264, il suffit de regarder le bullshit de On2 : http://blog.lib.umn.edu/mcfa0086/discretecosine/142728.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Je ne crois pas, regarde les sources que j'ai donné, où les standards VP8 et H.264 ont été vérifiés. Et tu peux vérifier les performances des encodeurs toi-même.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Autant écrire un traducteur unité systemd → script init, c'est plus simple et ça a le même avantage. Ça couvre beaucoup de cas, et pour les autres, on écrit le script init à la main.
Et on se foire dans le script, et on revient à une unité systemd bien plus simple et sécurisée.
Been there, done that !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Un ersatz H.264 Baseline, qui ne peut pas en bouger parce que c'est ainsi qu'il a été standardisé, je le vois mal faire mieux que le vrai H.264 Baseline (et ce n'est pas le cas). Encore moins avec tout le preprocessing que permet le x264.
Quant au H.264 Main Profile ou High Profile, c'est sans espoir pour le VP8 à moins de casser le standard.
Et de toutes façons : stop talking and show us the benchmark !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Posté par xcomcmdr .
En réponse à la dépêche Sortie de PulseAudio 4.0.
Évalué à 1.
Dernière modification le 19 juin 2013 à 17:34.
Je ne sais pas quel environnement de bureau tu utilises, mais si tu étais sous KDE, je te proposerais de faire un tour dans Configuration système -> Raccourcis et gestes -> Raccourcis globaux de clavier -> Kmix et là tu affectes une combinaison de touches pour Augmenter le volume (genre Méta + +), Diminuer le volume (genre Méta + -) et Muet (genre Méta + /), et à toi les fonctionnalités qui te manquent d'un clavier multimédia ou d'un potentiomètre ! :)
J'ai déjà xfce4-volumed (mixer gstreamer, qui appelle celui de ALSA), remplacé par xfce4-volumed-pulse (qui provient de Xubuntu) pour gérer le mute/unmute globale et le volume globale vite fait avec les touches [Fn]-[F10]/[F11]/F[12]. ;-)
Mais ça ne fait que utiliser ALSA ou PA, et non pas rajouter un contrôle de volume "analogique" (dans le même genre je n'ai pas de quoi éteindre mes hauts parleurs, c'est un ordi portable : donc pas de mute à moins de passer par un mixer logiciel ou d'éteindre l'ordi, ou de blacklister le module snd_hda_intel. C'est un peu trop permanent, tout ça…)
Par exemple, je viens de vérifier, si je touche à la jauge de volume de Kaffeine, aucune des jauges de kmix et encore moins celle du volume global (Master dans mon cas) n'est affectée. C'est uniquement le volume sonore de Kaffeine qui est changé. De même pour Clémentine, que je viens de vérifier, ainsi que Youtube (là rien d'étonnant). Pareil pour Amarok. Idem pour VLC.
Intéressant. Quelle est ta distribution ?
Arch est connue pour être proche de l'upstream (on évite au maximum les patchs maison).
Ton problème ne serait-il pas lié à une histoire d'option de mixer matériel/mixer logiciel que certaines applications proposent dans leurs préférences ? (genre surtout les applications Gnome, tel Gnome-Mplayer par exemple) L'un des choix reposant – je pense – sur le volume global, et l'autre gérant le volume de manière interne à l'application (pure hypothèse de ma part).
J'en sais rien. J'ai bien pourtant un mixing logiciel ou matériel quelque part, vu que sans rien faire, et avec ALSA seul, j'ai le son de plusieurs applications en même temps sans problème.
En tout cas c'était bel et bien toutes les applications : SMPlayer, Audacious, Flash, Parole, DOSBox, …
Seul Audacious (un clone de XMMS) me permet d'utiliser un mixing logciel propre à Audacious. Cette option est déconseillée (et je crois comprendre pourquoi, vu qu'elle introduit de la latence : le nouveau volume met quelque temps à être effectif, et le contrôle du volume d'Audacious répond moins vite).
Avec ALSA seul, ça évite de modifier le volume globale quand je modifie le volume d'Audacious. C'est cool, mais c'est pour une seule application.
Avec PA, ça sert juste à ce que la modification du volume d'Audacious ne modifie pas le volume de l'application dans PA (le volume d'Audacious est bien modifié, c'est juste qu'Audacious n"utilise plus PA pour son volume sonore).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Posté par xcomcmdr .
En réponse à la dépêche Sortie de PulseAudio 4.0.
Évalué à 4.
Dernière modification le 19 juin 2013 à 16:42.
Je ne comprends pas trop, tu as une telle différence de niveau sonore entre tes applications, et ce de manière aussi aléatoire, que tu as davantage besoin de pulseaudio que des jauge de volume de chacune des applications en question ?
PulseAudio m'évite d'avoir cet aspect aléatoire, justement.
Avec ALSA seul, tout le monde modifie constamment le volume globale, et tout le monde se réfère au volume globale.
A moins de bloquer le volume globale (ça semble possible avec alsamixer - ce qui n'est pas une solution très pratique non plus), je me fais régulièrement zigouiller les esgourdes.
Avec PA, c'est l'utilisateur qui maitrise le volume globale, et au besoin celui de chaque application, constamment et automatiquement.
Toujours est-il que toutes mes applis ont le volume calé à 100%, j'ai réglé le micro pile poil pour que mon correspondant ait un son parfait, mon casque pour ne pas qu'il me pète les oreilles, et le reste, ben j'ai le master à 75%, et le bouton du volume (physique) à portée de main, et 3 touches de réglage (volume down, volume up, mute) sur mon clavier. Les rares fois où cela est nécessaire, en moins de deux le son est au niveau qui me convient.
Je n'ai pas de bidule pour gérer le volume sur mes écouteurs, ni sur mes hauts-parleurs. Et avoir le volume calé à 100% n'est pas une solution, du coup (comme par exemple certains musiques dans Audacious qui ont un volume plus fort que d'autres)
Bref, à part une surcouche inutile et coûteuse en ressources, en plus d'être particulièrement inefficace, je ne vois pas ce qu'apporte Pulseaudio, clairement.
Pour moi c'est une surcouche légère, très pratique. Je maîtrise enfin le volume sonore globalement, et par applications, sans y revenir toutes les 5 minutes. Et j'ai enfin fini d'avoir un mixing audio des années 1990, cassé par dessus le marché.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Et dans la majorité des cas, aujourd'hui, cela ne sert à rien puisqu'ALSA fait du mixage logciel
Effectivement, en général, ce n'est pas pour ça qu'on utilise PulseAudio. Sans aller jusqu'aux cas d'utilisation impliquant la diffusion du son par le réseau, voici quelques intérêts sur une utilisation de type desktop "grand public" :
- Éviter d'avoir le volume sonore globale qui change constamment. Je tiens à mes tympans, surtout quand j'ai des écouteurs dans les oreilles. Alors quand j'ai de la musique qui tourne avec le volume sonore à 35%, et que l'application X s'initialise et en profite pour mettre le volume à 100% et me péter les tympans, ça fait toujours plaisir (ou pas).
Et dans l'interface graphique pavucontrol plus spécifiquement :
- Pouvoir mettre une application en particulier à 100% (voire jusqu'à 150 % quand la piste sonore est basse) sans que tout le monde se retrouve à ce même niveau.
- Que ces états/niveaux sonores soient sauvegardés et restaurés automatiquement pour chaque application.
- Avoir un volume sonore différent pour les haut-parleurs, les écouteurs, le micro, …
- Configurer le volume en entrée pour les applications enregistrant du son (et là aussi c'est sauvegardé automatiquement).
Bref, tout ce que permet le mixer logiciel de Windows depuis Windows Vista (il y a pas que des mauvaises idées chez la concurrence).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Posté par xcomcmdr .
En réponse au journal Ma vie et debian....
Évalué à 2.
Dernière modification le 19 juin 2013 à 11:59.
Comme ça par exemple tu aurais pu lancer la bonne commande pour GRUB.
C'est ce que je fais avec Arch (pas moyen de faire autrement par contre), et je vois là que ça a ses avantages : les seules fautes d'installation ont bien plus de chance de provenir uniquement de l'interface chaise/clavier.
C'est sûrement possible avec Debian. Un p'tit partitionnement avec parted, un p'tit grub-install /dev/sdX, et ensuite un équivalent à "pacstrap" (pour installer les paquets de base), et un p'tit coup de chroot pour finir tout ça, et ça roule.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ça a quand même tendance à marcher depuis quelques années sur les distribs qui font l'effort de l'intégrer.
Avec des logiciels et patchs qui restent downstream (Xubuntu : xfce4-volumed-pulse, fork de xfce4-volumed, indicator-sound-gtk2, *buntu : support de Timidity++ avec PulseAudio quel que soit la manière dont on l'a lancé alors que j'ai dû trouver LA commande qui le fait fonctionner avec PA sous Arch, etc…), malheureusement.
Reprocher à Arch de ne pas intégrer le logiciel X, c'est un peu ne pas comprendre Arch.
Et sinon, chez moi PulseAudio ça fonctionne très bien. Mais pour ça, j'ai dû :
- bien comprendre l'article sur PulseAudio sur le wiki Arch. Car comme d'habitude, l'intégration, c'est du DIY, c'est le revers de la médaille de sa philosophie KISS. Si t'en veux pas, tu prends une autre distrib' (je te conseillerais Xubuntu d'ailleurs : ça juste marche. Mais y'a pas pacman. :/ )
- compiler xfce4-volumed-pulse (je l'ai mis sur l'AUR depuis), plutôt que d'utiliser xfce4-volumed
- compiler psmixer-xfce4 depuis l'AUR pour avoir un vrai support de PulseAudio dans le tableau de bord Xfce (à la place de xfce4-mixer qui utilise le mixer de gstreamer0.10, tout comme xfce4-volumed, qui est abandonné)
- ne pas lancer pulseaudio ni xfce4-volumed-pulse grâce à leurs fichier .desktop dans /etc/xdg/autostart ! Il faut que PA soit lancé en premier pour avoir du son. Du coup je lance dans l'ordre PA, xfce4-volumed-pulse, et timidity++ dans un script situé dans ~/bin, lancé depuis un fichier .desktop présent dans ~/.config/autostart
- dire aux quelques logiciels (Audacious, SMPlayer, …) que j'utilise PA. Rien de compliqué.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Même Linux Mint, une distribution majeure par sa popularité,
DistroWatch n'indique pas du tout la popularité (au sens "part de marché") des distributions. C'est marqué sur la page donnée en lien !
The DistroWatch Page Hit Ranking statistics are a light-hearted way of measuring the popularity of Linux distributions and other free operating systems among the visitors of this website. They correlate neither to usage nor to quality and should not be used to measure the market share of distributions. They simply show the number of times a distribution page on DistroWatch.com was accessed each day, nothing more.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re:Préférée?
Posté par xcomcmdr . En réponse au sondage Quelle est votre suite bureautique principale ou préférée ?. Évalué à 2. Dernière modification le 26 juin 2013 à 09:00.
Ces formats MS Office sont-ils documentés ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Préférée?
Posté par xcomcmdr . En réponse au sondage Quelle est votre suite bureautique principale ou préférée ?. Évalué à 1.
A part le thème moche, je n'ai aucun de ces problèmes depuis très longtemps.
Quant à la lourdeur, LO tourne vraiment partout. Il est peut-être un peu lent (enfin c'est surtout des problèmes de boutons qui mettent 30 ans à se redessiner, du moins sous GNU/Linux), mais il ne plante jamais (depuis la série 4.X de LO j'ai pas vu un seul plantage).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: les racketiciels pour les nuls
Posté par xcomcmdr . En réponse à la dépêche Enfin un article de loi limitant les racketiciels ?. Évalué à 2.
T'as pas une explication plus technique ?
Snif :(
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: les racketiciels pour les nuls
Posté par xcomcmdr . En réponse à la dépêche Enfin un article de loi limitant les racketiciels ?. Évalué à 3.
Merci, mais c'est pareil sous Windows.
C'est pareil sous Windows.
Le problème est que je n'ai jamais vu Windows fonctionner dans ce cas de changement de machine du disque dur principal.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: les racketiciels pour les nuls
Posté par xcomcmdr . En réponse à la dépêche Enfin un article de loi limitant les racketiciels ?. Évalué à 2.
Pour préciser, Linux charge un pilote différent si le matériel est différent.
Tous les pilotes (ou presque) sont fournis avec le kernel (kernel monolithique, tout ça).
Après Xorg c'est pareil à moins d'avoir forcé un pilote dans la configuration dans /etc/xorg.d/ (pour la carte graphique par exemple).
Windows, je lui change d'ordinateur (au sens je prends le disque dur et je le mets dans une autre machine), il plante quoi que je fasse (BSOD, même en mode sans échec).
Quand c'est pas Windows qui a décidé que la licence n'était pas respectée :
http://support.microsoft.com/kb/305356
GNU/Linux, ça marche 9 fois sur 10. Et quand ça marche pas, on peut au moins accéder à la ligne de commande pour changer la config.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: les racketiciels pour les nuls
Posté par xcomcmdr . En réponse à la dépêche Enfin un article de loi limitant les racketiciels ?. Évalué à 5.
Linux (le kernel) sait très bien s'adapter à un changement de configuration.
Et Xorg aussi d'ailleurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Expérience de jeu
Posté par xcomcmdr . En réponse à la dépêche Humble Bundle with Android 6. Évalué à 1.
J'ai acquis Aquaria et Organ Trail il y a quelques mois sur Steam sous Archlinux, et je les recommande tous les deux chaudement !
Aquaria pour le côté poétiquement sublime, et l'histoire centrée sur une sirène découvrant sa civilisation disparue.
C'est un jeu qui se fera une place dans votre p'tit cœur !
Organ Trail pour le côté rétro, décalé, horrifique (un peu quand même, on parle de zombies), tout en restant très proche du gameplay de Oregon Trail qui est toujours aussi bon et aussi dur.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1.
C'est le cas pour n'importe quel codec ou presque (bon après ça dépend de la résolution et du FPS). 56 kbit/s, c'est de l'underflow (pas assez de débit pour encoder) ou vraiment pas loin.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: prise en charge du protocole RDP
Posté par xcomcmdr . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 2.
Le VP8 est bien plus gourmand à décoder pour les décodeurs matériels (voir le lien)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1. Dernière modification le 20 juin 2013 à 10:57.
Le H.264 est généraliste. Le x264 offre même des preset pour les sources qui ne sont pas des films.
Le VP8 d'ailleurs c'était au départ présenté comme un concurrent sérieux au H.264, il suffit de regarder le bullshit de On2 :
http://blog.lib.umn.edu/mcfa0086/discretecosine/142728.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 0.
Je ne crois pas, regarde les sources que j'ai donné, où les standards VP8 et H.264 ont été vérifiés. Et tu peux vérifier les performances des encodeurs toi-même.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par xcomcmdr . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 2.
Et on se foire dans le script, et on revient à une unité systemd bien plus simple et sécurisée.
Been there, done that !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Il y aurait bien Starship Troopers, mais...
Posté par xcomcmdr . En réponse au sondage Votre univers SF / Space opéra préféré. Évalué à 1.
Ils sont effectivment à éviter. Tout comme les étrons écrits par le fiston de Herbert et KJ Anderson
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 0.
Un ersatz H.264 Baseline, qui ne peut pas en bouger parce que c'est ainsi qu'il a été standardisé, je le vois mal faire mieux que le vrai H.264 Baseline (et ce n'est pas le cas). Encore moins avec tout le preprocessing que permet le x264.
Quant au H.264 Main Profile ou High Profile, c'est sans espoir pour le VP8 à moins de casser le standard.
Et de toutes façons : stop talking and show us the benchmark !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ouais, ben…
Posté par xcomcmdr . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 1. Dernière modification le 19 juin 2013 à 17:34.
J'ai déjà xfce4-volumed (mixer gstreamer, qui appelle celui de ALSA), remplacé par xfce4-volumed-pulse (qui provient de Xubuntu) pour gérer le mute/unmute globale et le volume globale vite fait avec les touches [Fn]-[F10]/[F11]/F[12]. ;-)
Mais ça ne fait que utiliser ALSA ou PA, et non pas rajouter un contrôle de volume "analogique" (dans le même genre je n'ai pas de quoi éteindre mes hauts parleurs, c'est un ordi portable : donc pas de mute à moins de passer par un mixer logiciel ou d'éteindre l'ordi, ou de blacklister le module snd_hda_intel. C'est un peu trop permanent, tout ça…)
Intéressant. Quelle est ta distribution ?
Arch est connue pour être proche de l'upstream (on évite au maximum les patchs maison).
J'en sais rien. J'ai bien pourtant un mixing logiciel ou matériel quelque part, vu que sans rien faire, et avec ALSA seul, j'ai le son de plusieurs applications en même temps sans problème.
En tout cas c'était bel et bien toutes les applications : SMPlayer, Audacious, Flash, Parole, DOSBox, …
Seul Audacious (un clone de XMMS) me permet d'utiliser un mixing logciel propre à Audacious. Cette option est déconseillée (et je crois comprendre pourquoi, vu qu'elle introduit de la latence : le nouveau volume met quelque temps à être effectif, et le contrôle du volume d'Audacious répond moins vite).
Avec ALSA seul, ça évite de modifier le volume globale quand je modifie le volume d'Audacious. C'est cool, mais c'est pour une seule application.
Avec PA, ça sert juste à ce que la modification du volume d'Audacious ne modifie pas le volume de l'application dans PA (le volume d'Audacious est bien modifié, c'est juste qu'Audacious n"utilise plus PA pour son volume sonore).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ouais, ben…
Posté par xcomcmdr . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 4. Dernière modification le 19 juin 2013 à 16:42.
PulseAudio m'évite d'avoir cet aspect aléatoire, justement.
Avec ALSA seul, tout le monde modifie constamment le volume globale, et tout le monde se réfère au volume globale.
A moins de bloquer le volume globale (ça semble possible avec alsamixer - ce qui n'est pas une solution très pratique non plus), je me fais régulièrement zigouiller les esgourdes.
Avec PA, c'est l'utilisateur qui maitrise le volume globale, et au besoin celui de chaque application, constamment et automatiquement.
Je n'ai pas de bidule pour gérer le volume sur mes écouteurs, ni sur mes hauts-parleurs. Et avoir le volume calé à 100% n'est pas une solution, du coup (comme par exemple certains musiques dans Audacious qui ont un volume plus fort que d'autres)
Pour moi c'est une surcouche légère, très pratique. Je maîtrise enfin le volume sonore globalement, et par applications, sans y revenir toutes les 5 minutes. Et j'ai enfin fini d'avoir un mixing audio des années 1990, cassé par dessus le marché.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ouais, ben…
Posté par xcomcmdr . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 3.
Effectivement, en général, ce n'est pas pour ça qu'on utilise PulseAudio. Sans aller jusqu'aux cas d'utilisation impliquant la diffusion du son par le réseau, voici quelques intérêts sur une utilisation de type desktop "grand public" :
- Éviter d'avoir le volume sonore globale qui change constamment. Je tiens à mes tympans, surtout quand j'ai des écouteurs dans les oreilles. Alors quand j'ai de la musique qui tourne avec le volume sonore à 35%, et que l'application X s'initialise et en profite pour mettre le volume à 100% et me péter les tympans, ça fait toujours plaisir (ou pas).
Et dans l'interface graphique pavucontrol plus spécifiquement :
- Pouvoir mettre une application en particulier à 100% (voire jusqu'à 150 % quand la piste sonore est basse) sans que tout le monde se retrouve à ce même niveau.
- Que ces états/niveaux sonores soient sauvegardés et restaurés automatiquement pour chaque application.
- Avoir un volume sonore différent pour les haut-parleurs, les écouteurs, le micro, …
- Configurer le volume en entrée pour les applications enregistrant du son (et là aussi c'est sauvegardé automatiquement).
Bref, tout ce que permet le mixer logiciel de Windows depuis Windows Vista (il y a pas que des mauvaises idées chez la concurrence).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1. Dernière modification le 19 juin 2013 à 14:02.
Alors le H.264 sera meilleur, vu que le VP8/WebM est un mauvais copié/collé même pas libre du H.264 Baseline.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Finalement t'aurais gagné du temps en faisant tout "à la main"
Posté par xcomcmdr . En réponse au journal Ma vie et debian.... Évalué à 2. Dernière modification le 19 juin 2013 à 11:59.
Comme ça par exemple tu aurais pu lancer la bonne commande pour GRUB.
C'est ce que je fais avec Arch (pas moyen de faire autrement par contre), et je vois là que ça a ses avantages : les seules fautes d'installation ont bien plus de chance de provenir uniquement de l'interface chaise/clavier.
C'est sûrement possible avec Debian. Un p'tit partitionnement avec parted, un p'tit grub-install /dev/sdX, et ensuite un équivalent à "pacstrap" (pour installer les paquets de base), et un p'tit coup de chroot pour finir tout ça, et ça roule.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par xcomcmdr . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1.
Le H.264 peut aussi compresser sans perte, mais dans ce cas c'est beaucoup trop lourd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Sans pulseaudio
Posté par xcomcmdr . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 3.
Avec des logiciels et patchs qui restent downstream (Xubuntu : xfce4-volumed-pulse, fork de xfce4-volumed, indicator-sound-gtk2, *buntu : support de Timidity++ avec PulseAudio quel que soit la manière dont on l'a lancé alors que j'ai dû trouver LA commande qui le fait fonctionner avec PA sous Arch, etc…), malheureusement.
Reprocher à Arch de ne pas intégrer le logiciel X, c'est un peu ne pas comprendre Arch.
Et sinon, chez moi PulseAudio ça fonctionne très bien. Mais pour ça, j'ai dû :
- bien comprendre l'article sur PulseAudio sur le wiki Arch. Car comme d'habitude, l'intégration, c'est du DIY, c'est le revers de la médaille de sa philosophie KISS. Si t'en veux pas, tu prends une autre distrib' (je te conseillerais Xubuntu d'ailleurs : ça juste marche. Mais y'a pas pacman. :/ )
- compiler xfce4-volumed-pulse (je l'ai mis sur l'AUR depuis), plutôt que d'utiliser xfce4-volumed
- compiler psmixer-xfce4 depuis l'AUR pour avoir un vrai support de PulseAudio dans le tableau de bord Xfce (à la place de xfce4-mixer qui utilise le mixer de gstreamer0.10, tout comme xfce4-volumed, qui est abandonné)
- ne pas lancer pulseaudio ni xfce4-volumed-pulse grâce à leurs fichier .desktop dans /etc/xdg/autostart ! Il faut que PA soit lancé en premier pour avoir du son. Du coup je lance dans l'ordre PA, xfce4-volumed-pulse, et timidity++ dans un script situé dans ~/bin, lancé depuis un fichier .desktop présent dans ~/.config/autostart
- dire aux quelques logiciels (Audacious, SMPlayer, …) que j'utilise PA. Rien de compliqué.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par xcomcmdr . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 5.
Si tu cherches un remplaçant à XMMS, je ne peux que te conseiller Audacious.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Hum...
Posté par xcomcmdr . En réponse à la dépêche Debian 7.1 est sortie, mise à jour de securité pour Debian 7 (Wheezy). Évalué à 5. Dernière modification le 17 juin 2013 à 22:19.
DistroWatch n'indique pas du tout la popularité (au sens "part de marché") des distributions. C'est marqué sur la page donnée en lien !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Petite correction
Posté par xcomcmdr . En réponse à la dépêche Blagues d'informaticiens. Évalué à 1.
Compare la conjugaison en anglais, et celle en français, et on en reparle, m'kay ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: prise en charge du protocole RDP
Posté par xcomcmdr . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 2.
A peine une qualité d'image comparable au H.264 Baseline en fait (et bien plus gourmand)
http://x264dev.multimedia.cx/archives/377
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)