PulseAudio 6.0 et 7.0

Posté par  . Édité par Lucas, BAud, ʭ ☯ , M5oul, patrick_g, jlh, palm123, Benoît Sibaud, Frédéric LIETART, Julien.D, François et Storm. Modéré par bubar🦥. Licence CC By‑SA.
Étiquettes :
57
15
oct.
2015
Son

Pulseaudio est un serveur de sons sous licence libre, multiplateforme (GNU/Linux, BSD, Solaris, Mac OS, ainsi que Windows) et capable de fonctionner à travers le réseau. Il dispose de fonctionnalités avancées : il permet le contrôle du volume par application, peut être scripté, dispose de possibilités de ré-échantillonnage, etc.

La suite de la dépêche évoque les nouveautés introduites dans les versions 6.0 (février 2015) et 7.0 (septembre 2015).

Sommaire

PulseAudio 6.0

Cette version contient un bon nombre d’améliorations mineures, de corrections de bugs et de mises à jour d’i18n

Prise en charge des profils Bluetooth HSP/HFP avec BlueZ 5

PulseAudio prend en charge les profils Bluetooth HPS (casque audio) via le backend natif et HFP (kit mains-libres) via le backend oFono, grâce à BlueZ 5. Seul l’un est actif mais ce n’est pas gênant car la plupart des appareils gèrent à la fois HPS et HFP. Cependant, chaque backend a ses limitations.

Le natif ne gère pas le « rôle casque audio », ce qui signifie que connecter un PC à un téléphone mobile pour que le PC se comporte comme casque n’est pas pris en charge. À l’inverse, le backend oFono ne permet pas d’utiliser le téléphone mobile comme casque audio pour le PC. De plus, le contrôle du volume n’est pas aussi bien géré qu’il pourrait l’être (PulseAudio n’informe pas l’appareil connecté de son volume donc les deux gèrent leur volume indépendamment).

Comme les deux backends ne se chevauchent pas, ils pourraient être activés en même temps. Cependant, il n’y pour l’instant pas de consensus sur le fait que ça soit la voie à suivre ou non. Pour le moment, on ne peut activer cette fonctionnalité qu’en appliquant un patch à PulseAudio.

Prise en charge de l’activation par socket systemd

PulseAudio gère dorénavant l’activation par socket systemd. Cependant cela fonctionne uniquement pour les sockets Unix ; la prise en charge pour TCP arrivera plus tard. PulseAudio est fourni avec un fichier socket tout prêt pour démarrer l’instance utilisateur, mais ce n’est pas conseillé de l’activer car cela empêchera PulseAudio d’accéder au bus de session D-Bus, cassant de nombreuses fonctionnalités qui dépendent de cet accès. C’est prévu que, dans le futur, systemd soit capable de remplacer le bus de session avec un bus utilisateur, et à ce moment-là cette fonctionnalité sera utilisable à grande échelle.

Améliorations de performance

PulseAudio transfère depuis longtemps les données entre clients et serveur par SHM (shared memory, mémoire partagée), tandis que les métadonnées des paquets étaient envoyées par une socket Unix. Depuis la version 3.6, il gère également le transfert des métadonnées par deux ringbuffers SHM, un dans chaque direction. Pour signaler l’arrivée d’un nouveau paquet, PulseAudio utilise des eventfds. (Il y a aussi un couche d’optimisation au-dessous d’eventfd qui essaie d’éviter d’y écrire si personne n’attend). Ce n’est pas tant pour éviter les copies de mémoire que pour éviter les appels systèmes. Ce nouveau mécanisme est appelé srbchannel pour Shared RingBuffer channel (canal de ringbuffer partagé). Quelques bancs d’essais non-scientifiques montrent que cela peut économiser de 10 à 25 % de puissance CPU dans des cas de faible latence, la moitié côté client. Cette fonctionnalité n’est pas activée par défaut dans cette version à cause de bugs non résolus, mais elle est activée par défaut dans la version suivante.

La réaffectation des canaux a été optimisée en remplaçant l’implémentation générique avec du code spécialisé pour certain cas (les implémentations sont faites à la fois en C et en ARM NEON).

Une implémentation ARM NEON a été ajoutée pour le cas spécial où l’on mélange deux flux 16 bits quand ceux-ci ont 1, 2 ou 4 canaux.

module-combine-sink gère maintenant le mode latence dynamique, de telle sorte que les applications nécessitant une faible latence fonctionnent correctement avec un sink combiné.

Meilleure gestion des profils multicanaux et 2.1

Quelques cartes sons multicanaux, incluant des cartes gérées par le nouveau pilote FireWire d’ALSA (ajouté dans le noyau Linux 3.16) et quelques cartes USB peuvent seulement être ouvertes en mode multicanal, par exemple 14 sorties et 10 entrées. Si toutes les tentatives d’ouverture de la carte échouent, PulseAudio fait une dernière tentative où le pilote peut choisir le nombre de canaux librement. Ces voies sont considérées en connexion par défaut.

La gestion de l’audio 7.1 pour l’HDMI a été ajoutée.

ALSA 1.0.28 apporte une meilleure gestion des profils surround 2.1. PulseAudio prend dorénavant cette nouvelle syntaxe (surround21:card) quand elle est disponible.

Outils

L'utilitaire pactl peut dorénavant définir un volume différent pour chaque canal d’un périphérique ou d’un flux.

Instances multiples de connecteurs et sources JACK

Auparavant, il n’était pas possible de charger deux instances de module-jack-sink et module-jack-source. Cette limitation entièrement artificielle n’avait pas de sens, elle a donc été supprimée.

Nouvel argument pour module-switch-on-connect

L’option module-switch-on-connect accepte un nouvel argument booléen : only_from_unavailable. Si la propriété est à faux (valeur par défaut), le comportement est le même qu’avant (utiliser le nouveau périphérique à la place du précédent sans condition), sinon le changement se fait uniquement si le périphérique par défaut était auparavant indisponible.

PulseAudio 7.0

Synthèse de la voie LFE avec filtre passe-bas

Quand les haut-parleurs ont un caisson de basse, il est souvent préférable de créer le son LFE quand le contenu originel n'a pas de voie séparée LFE.
Précédemment PulseAudio le faisait en mélangeant la moyenne de toutes les autres pistes, mais il est souvent mieux de filtrer toutes les fréquences hautes qui partent vers le caisson de basses. C'est maintenant le cas, et activé par défaut.

La valeur par défaut de enable-lfe-remixing dans deamon.conf a été changée de vrai à faux, et une nouvelle option lfe-crossover-freq permet de configurer la fréquence du crossover (mettre à zéro pour désactiver, et enable-lfe-remixing pour utiliser l’ancien algorithme).

Nouveaux ré-échantillonneurs basés sur libsoxr

Trois nouveaux ré-échantillonneurs basés sur libsoxr sont disponibles : soxr-mq, soxr-hq et soxr-vhq. D'un point de vue de qualité, ils devraient tous être parfaits (pas de distorsion audible), mais les versions hq et vhq peuvent être utilisées si une qualité encore plus parfaite est désirée. Les développeurs de libsoxr recommandent la version hq pour des profondeurs allant jusque 16 bits, et la version vhq pour des profondeurs plus hautes (les traitements internes se font avec une plus grande précision dans la version vhq). L’affirmation que même la version mq est parfaite se base sur les mesures effectuées par Alexander E. Patrakov en utilisant un modèle psychoacoustique afin de déterminer si les distorsions produites sont effectivement audibles (et elles ne le sont pas). Le modèle utilisé est décrit dans cet article : http://www.mp3-tech.org/programmer/docs/6_Heusdens.pdf

Les version mq et hq ont de meilleures performances que speex-float-l (le ré-échantillonneur actuellement utilisé par défaut). soxr-mq serait le ré-échantillonneur par défaut s’il n’avait pas un inconvénient majeur : les ré-échantillonneurs introduisent une latence supplémentaire jusqu'à environ 20 ms, voire même plus dans certains rares cas.

Plus de discussions sur les qualités et défauts de ces nouveaux ré-échantillonneurs sur le fil de cette liste : http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/22158

Voici quelques résultats de bancs d'essai : http://lastique.github.io/src_test/

Activation par socket pour TCP

La version précédente a introduit la prise en charge de l’activation par socket systemd pour les sockets unix. Cete prise en charge a été étendue aux sockets TCP dans cette version, ce qui permet à PulseAudio d’être démarré sur les serveurs headless par exemple.

Le mécanisme d’IPC « srbchannel » activé par défaut

Le mécanisme d’IPC « srbchannel » ajouté dans la version précédente était trop défaillant. Cela n’est plus le cas et il est maintenant activé par défaut.

Détection de jack plus flexible lors de l’utilisation d’UCM

Les systèmes qui utilisent l’UCM (use case manager, gestionnaire de cas d’usages) d’ALSA pour décrire le matériel peuvent dorénavant configurer le kcontrol du jack pour un périphérique utilisant la valeur JackControl. Auparavant, PulseAudio essayait de le détecter seul, ce qui ne fonctionnait pas toujours correctement. De plus, la valeur JackHWMute pour les périphériques UCM est maintenant gérée, permettant à PulseAudio de comprendre que la connexion d’un jack sur une sortie rend indisponible une autre sortie.

Quitter dû à SIGTERM n’est plus considéré comme une défaillance

Quand PulseAudio reçoit un signal SIGTERM, le processus se termine en renvoyant 0. Auparavant il renvoyait 1, signalant une défaillance, ce qui n’avait pas de sens. Si vous avez par exemples des scripts ou services systemd qui s’occupent de la valeur de retour, ils nécessitent peut-être quelques modifications.

Meilleure gestion de la Creative SoundBlaster Omni Surround 5.1

La carte son USB « Creative SoundBlaster Omni Surround 5.1 » configure son périphérique ALSA pour le microphone d’une façon que PulseAudio ne sait gérer avec sa configuration par défaut. La carte a dorénavant son propre fichier de configuration pour faire fonctionner le microphone.

Aller plus loin

  • # Aide sur Pulseaudio

    Posté par  . Évalué à 10. Dernière modification le 15 octobre 2015 à 22:26.

    Bon alors, c'est sûr je vais me faire moinser, car c'est hors sujet.

    La question c'est : comment avoir de l'aide sur pulseaudio ? C'est quand même une brique essentielle pour un pauvre end user comme moi, mais zéro, hormis la quelque documentation sur le site et une FAQ, c'est un peu débrouille-toi toi-même.
    J'ai quelques soucis avec mon installation : dés que je branche un adaptateur audio sur usb (un dac, un adaptateur bluetooth), ça ne marche pas : je n'ai plus de son de manière aléatoire, ou alors il est très mauvais. J'ai essayé sur le forum de ma distribution ainsi que sur d'autres forum généralistes sans succès, alors j'ai posté un message sur la mailing list pulseaudio, mais cela n'a intéressé personne, apparemment ce qui les intéresse c'est les patchs pour la version de développement 7.2 ou les nouveaux drivers alpha pour des cartes genres creative 7.1 mégabass dominator, un truc vendu à 5 exemplaires (oui, je suis énervé), par contre faire marcher ce qui existe, non, j'ai vu passer un autre message de demande d'aide comme le mien, eh bien même sanction. Cela fait des mois que je cherche sans succès. Là où il y a le plus d'infos, c'est encore (comme d'hab) le bon wiki des gars d'Archlinux, mais je n'ai pas trouvé la réponse à mon problème.

    Cela pose quand même le problème global du support sur linux : sur des points un peu pointus, si les développeurs ne font pas d'effort pour faire un peu d'assistance, c'est un vrai problème.

    • [^] # Re: Aide sur Pulseaudio

      Posté par  (site web personnel) . Évalué à 4.

      Bah, en février soit dans moins de 4 mois, tu auras la version 8.0 qui corrigera un grande partie des bogues connus ;-)

      • [^] # Re: Aide sur Pulseaudio

        Posté par  . Évalué à 7.

        A ce train là, effectivement. Sauf que "avant, ça marchait bien !", refrain bien connu mais qui s'applique à mon cas. Je n'ai des problèmes que depuis février de cette année, pour quelle raison, je ne le sais.
        Toujours est-il que ma distrib, mageia 5, est encore à la version 5 de pulseaudio !
        Si je pouvais me passer de pulseaudio, je le ferais !

        • [^] # Re: Aide sur Pulseaudio

          Posté par  . Évalué à 6.

          Si je pouvais me passer de pulseaudio, je le ferais !

          Quel logiciel exactement te contrains à l'utiliser? Je sais que je ne suis utilisateur ni de gnome, ni de KDE, mais à l'heure actuelle je n'ai jamais été contraint d'utiliser PA, et avec alsa, ça juste marche. Bon, je suppose qu'il me manque des tas de fonctionnalités, mais honnêtement, j'ignore lesquelles: je peux modifier le son de mon PC, le couper, activer/désactiver le micro… à peu près tout ce que je veux en fait.

          À peu près, parce que, pour une raison qui m'est inconnue, mumble refuse d'utiliser le micro de ma tour, alors que sur une autre machine (sans PA également, bien entendu) il ne pose aucun problème. Je ne me suis jamais vraiment penché sur la question je l'admets (alors que l'écho du micro fonctionne, c'est vraiment les logiciels type mumble qui refusent d'utiliser le micro, donc pas un problème hardware ni, je suppose, de pilotes… 'fin bon…).

          • [^] # Re: Aide sur Pulseaudio

            Posté par  . Évalué à 2.

            je n'ai pas de son en html5 dans firefox si je retire PA :(

            « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

          • [^] # Re: Aide sur Pulseaudio

            Posté par  . Évalué à 10.

            Désactiver PA me parait compliqué.
            Ce que je voulais dire, c'est qu'un outil dont on a pas suffisamment de support ne devrait pas être adopté, même s'il est performant.
            On ne peut pas avoir un système largement utilisé, tout public, et c'est chacun pour soi dés qu'il y a une merde.
            Je comprends, développer c'est fun, ça fait briller les yeux des filles, alors qu'apporter du support et dugger c'est ch…

            • [^] # Re: Aide sur Pulseaudio

              Posté par  . Évalué à 1. Dernière modification le 16 octobre 2015 à 10:11.

              Désactiver PA me parait compliqué.

              Normalement non, il suffit de le désinstaller. Cela peut poser un problème de dépendances sur certaines distributions. Avec Debian, pas de problème de ce genre.

              Un autre problème qui traîne depuis longtemps avec le mélangeur Xfce, est que l'on ne peut pas réactiver le son après l'avoir rendu muet. Au moins sur de nombreux systèmes sinon tous. Il faut alors passer par Alsa. Pénible et impossible pour un novice qui dira que le son ne marche pas sous Linux.

              J'ai cherché l'API de pulseaudio dans la documentation sans aller fouiller dans le code. Rien trouvé.
              Probablement il faut passer par l'usine à gaz Dbus.

              • [^] # Re: Aide sur Pulseaudio

                Posté par  . Évalué à 10.

                Pénible et impossible pour un novice qui dira que le son ne marche pas sous Linux.

                A juste titre, vu que ça ne fait pas ce qu'on lui demande, non?

                Depending on the time of day, the French go either way.

                • [^] # Re: Aide sur Pulseaudio

                  Posté par  . Évalué à 1.

                  A juste titre, vu que ça ne fait pas ce qu'on lui demande, non?

                  Non.
                  Et pourquoi alsamixer ou amixer ne seraient pas utilisés ? En quoi cela ne se fait pas ? Ils sont bien liés à Alsa.
                  Ils ne sont pas évidents à utiliser pour des novices non-informaticiens.
                  Je ne comprends pas ta réponse. Je n'ai peut-être pas été clair.

                  • [^] # Re: Aide sur Pulseaudio

                    Posté par  . Évalué à 3.

                    Ils ne sont pas évidents à utiliser pour des novices non-informaticiens.

                    Euh, alsamixer, le seul truc "difficile" c'est qu'il faut le lancer dans un terminal… et si c'est difficile, alors pourquoi ne pas utiliser alsamixergui? Pas besoin de terminal avec… et niveau difficulté, c'est plutôt intuitif: une jauge par I/O sonore en gros. La même que le mixer windows en fait. À moins que ce dernier n'ait changé depuis windows XP, bien entendu, mais je n'ai jamais entendu personne me dire qu'il ne savait pas l'utiliser.

                    • [^] # Re: Aide sur Pulseaudio

                      Posté par  . Évalué à 10. Dernière modification le 18 octobre 2015 à 09:24.

                      Le mixer avec un volume par source, c'est dans Windows 98.

                      Dans Windows 2000/XP, il n'y a qu'un seul volume global. Pour voir le reste, il faut aller dans le panneau de configuration.

                      Dans Windows Vista et suivants, il y a un volume par application qui produit du son, ce qui est 9 fois sur 10 bien plus utile que d'avoir un volume pour le CD audio, un volume pour l'entrée ligne (késako ??), un volume pour le micro, un volume pour le son 3D, un volume pour le MIDI, un volume pour le pc speaker (on s'en fiche un peu non ?), un volume pour l'internal mic boost (quoi ?), et autres sources plus obscures les unes que les autres.

                      Quand j'utilise alsamixer, oui, je reviens sous Windows 98 : une vue "hardware" du son archaïque et pas user-friendly, où seule le volume global est utile, mais sur lequel on n'a pas de contrôle plus fin du volume (cf. pas de contrôle par application).

                      Quand j'utilise PulseAudio, les mixers associés (pavucontrol par exemple), j'ai une vue "user-centric" du son, où sur la première vue / le premier onglet je peux gérer le volume du son par application et non par source d'entrée/sortie.

                      Ce qui est 9 fois sur 10 ce que je veux faire. Merci PulseAudio.

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Aide sur Pulseaudio

                        Posté par  . Évalué à 3.

                        Dans Windows 2000/XP, il n'y a qu'un seul volume global.

                        Si tu fais un simple clic sur l'icône, je suis d'accord, tu ne te retrouves qu'avec le master. Si tu fais un clic droit en revanche… tu te retrouves avec le truc complet.

                        Quand j'utilise alsamixer, oui, je reviens sous Windows 98 : une vue "hardware" du son archaïque et pas user-friendly, où seule le volume global est utile, mais sur lequel on n'a pas de contrôle plus fin du volume (cf. pas de contrôle par application).

                        C'est peut-être archaïque, mais le fait que ce ne soit pas user-friendly et pas assez fin, ce ne sont que tes opinions.
                        Peut-être partagées par pleins de gens, mais pas nécessairement par ne serait-ce que la moyenne. Tout comme la mienne, d'ailleurs.
                        Je pense personnellement que le contrôle réellement utilisé par 90% des gens, est le Master. Hors, le master est la première jauge dans alsamixer. Pour un truc plus simpliste qui cacherait les autres, les DEs ont en général ce qu'il faut de toute façon. alsamixer me sert principalement pour régler les choses quand je fais une installation, ou quand je veux jouer un peu avec mes raccourcis clavier (c'est un moyen simple d'avoir le nom des contrôles et de tester le fonctionnement).
                        Ceci dit, je te rejoins qu'un certain nombre de contrôles ont des noms obscurs.

                        mais sur lequel on n'a pas de contrôle plus fin du volume (cf. pas de contrôle par application).

                        Effectivement, ça, il n'y a pas.
                        En même temps, c'est peut-être ce dont tu as besoin 9 fois sur 10, mais moi je ne vois pas à quoi ça me servirait. Sur ma machine, je n'ai pas besoin de 150 applications qui me cassent les oreilles en même temps.
                        Il y à mpd pour la musique, mumble pour discuter, mplayer quand je regarde un film, et pour finir le browser pour le streaming. Ah, et quelques jeux aussi.

                        La plupart du temps, je n'ai que ma musique.
                        Quand je regarde un film ou un flux streaming, je ne fais que ça (cerveau mono-tâche), donc je coupe la musique et les éventuels jeux.
                        Quand je joue, je suis concentré sur les images du jeu, aucun film ne joue derrière, et c'est ma musique que je mets.
                        Et quand je veux couper le son du PC pour cause de téléphone, ben c'est le master que je veux couper…

                        Pour cet usage, qui me semble de mon point de vue personnel assez commun, aller dans un menu système pour contrôler le son des applications (en espérant que l'application soit supportée par PA) me paraît moins intuitif que d'aller dans les options du jeu couper la musique (chose que je ne fais que rarement, vu que je réactive rarement le son).

                        • [^] # Re: Aide sur Pulseaudio

                          Posté par  . Évalué à 8.

                          qui me semble de mon point de vue personnel assez commun

                          Non c'est rare que les gens désactivent toutes les notifications, qu'elles soient système ou d'une application (« votre base de signature virale a était mise à jour », ton client IM, ton gestionnaire de téléchargement ou de torrent, etc).

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Aide sur Pulseaudio

                            Posté par  . Évalué à 2.

                            Pour l'AV, c'est pas faux. Pour le reste, la plupart des gens que je côtoie n'en ont pas… ils utilisent des applications web (en fait , même pas sûr qu'ils aient des AV…) ce qui est la même chose que de désactiver les notifications au final, non?

                            • [^] # Re: Aide sur Pulseaudio

                              Posté par  . Évalué à 4.

                              Ils désactivent toutes les notifications système ?

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                              • [^] # Re: Aide sur Pulseaudio

                                Posté par  . Évalué à 4.

                                Moi oui. Une notification, ça ne devrait être qu'une alerte graphique minimale sur l'icône dans la barre de tâche (un petit nombre qui s'incrémente sur l'icône, si tu veux voir les notifications en attente, tu cliques dessus), ça ne devrait jamais être un truc intrusif qui te pop par-dessus ce que tu fais ou te pourri ce que tu écoutes. En tout cas, pas par défaut.

                                Le fait de pouvoir régler précisément la manière dont on est ou non ennuyé par les notifications me semble indispensable, et rend acceptable un réglage par défaut non adapté.

                        • [^] # Re: Aide sur Pulseaudio

                          Posté par  . Évalué à 10.

                          Un usage que j'ai assez souvent, c'est de jouer à un jeu (première source sonore), en écoutant ma propre musique (2ème source) avec des amis sur mumble (3ème source). Du coup la gestion du son par application m'est très pratique.

                          bépo powered

                          • [^] # Re: Aide sur Pulseaudio

                            Posté par  . Évalué à 3.

                            Ça tombe bien, tu pouvais déjà régler le volume individuellement dans chacune des applications qui produisent du son, et donc adapter le son de ton jeu et de ta musique pour pouvoir entendre ce qu'il se dit sur Mumble, c'était ce que je faisais depuis des années. :-)

                            Qu'a apporté Pulseaudio à ce niveau ? La centralisation des volumes individuels par application au même endroit, en doublon de la jauge de l'application elle-même, et moyennant une foultitude de bugs supplémentaires et un son dégueulasse qui crache et qui saute (ne serait-ce que lorsque ton jeu tape fort sur le processeur) ?

                            • [^] # Re: Aide sur Pulseaudio

                              Posté par  . Évalué à 4. Dernière modification le 20 octobre 2015 à 07:29.

                              en doublon de la jauge de l'application elle-même

                              Bah non, puisque l'application n'a pas forcément elle-même de quoi régler le volume. Et je me vois pas fouiller dans chaque application pour régler le volume. C'est bien plus rapide et pratique de passer par un endroit central.

                              et moyennant une foultitude de bugs supplémentaires

                              Rien à signaler de la sorte chez pas mal de mondes depuis des années.

                              et un son dégueulasse qui crache et qui saute

                              idem.

                              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                              • [^] # Re: Aide sur Pulseaudio

                                Posté par  . Évalué à 10.

                                Le réglage du son par application fait des choses bizarres (aucune idée de si c’est dû à pulseaudio ou à l’applet gnome, mais c’est bizarre) :
                                1) baisser le volume d’une application ne modifie pas le volume global
                                2) augmenter le volume d’une application au-delà d’un certain seuil (en fait, le niveau du volume global actuel) augmente le volume global (mais pas le volume des autres applications)
                                3) augmenter le volume global augmente le volume individuel de chaque application
                                4) baisser le volume global diminue le volume des applications

                                Je ne sais pas qui a pondu ce système, s’il est lié à pulseaudio ou spécifique aux paramètres gnome, mais c’est manifestement un tordu. Mention spéciale au points 2 et 3 où un même effet visuel (déplacement du même « slider ») a deux effets différents.

                                Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                                • [^] # Re: Aide sur Pulseaudio

                                  Posté par  . Évalué à 10. Dernière modification le 20 octobre 2015 à 14:40.

                                  Oui, c'est l'une des incroyables merdes ergonomiques, inspirées de Windows, et introduites dans le monde linux par Pulseaudio.

                                  Dans ton fichier /etc/pulse/daemon.conf, configure
                                  flat-volumes = no

                                  Puis redémarre Pulseaudio :
                                  $ pulseaudio -k
                                  $ pulseaudio --start

                                  Cela devrait te rendre à nouveau le fonctionnement des jauges de volume « normal », ergonomiquement parlant.

                                  • [^] # Re: Aide sur Pulseaudio

                                    Posté par  . Évalué à 4.

                                    Je ne connaissais pas, merci beaucoup !

                                    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                                • [^] # Commentaire supprimé

                                  Posté par  . Évalué à -10.

                                  Ce commentaire a été supprimé par l’équipe de modération.

                              • [^] # Re: Aide sur Pulseaudio

                                Posté par  . Évalué à 3.

                                en doublon de la jauge de l'application elle-même

                                Bah non, puisque l'application n'a pas forcément elle-même de quoi régler le volume. Et je me vois pas fouiller dans chaque application pour régler le volume. C'est bien plus rapide et pratique de passer par un endroit central.

                                Rien à signaler de la sorte chez pas mal de mondes depuis des années.

                                Idem. Aucune application à signaler qui utilise le son et ne me permette pas de le régler de façon simple.

                                • [^] # Re: Aide sur Pulseaudio

                                  Posté par  . Évalué à 5.

                                  Que ce soit facile ou non, cela importe peu au fait que cela reste moins pratique (il faut fouiller, même si c'est juste un peu) et rapide (pas besoin de donner le focus à l'application et d'accéder à un menu quelconque) que de faire un seul et unique clic dans la zone de notification pour avoir accès à tous les volumes instantanément.

                                  Et il a des applications où ce n'est pas forcément facile de trouver où régler le volume depuis l'application, je pense notamment à FS-UAE ou DOSBox.

                                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Aide sur Pulseaudio

                    Posté par  . Évalué à 3.

                    Okay, si je décrit la chose comme ça:

                    Comportement attendu:
                    Dans l'interface par défaut d'Xfce, apres avoir desactivé le son, l'action sur le bouton devrait rétablir le son.

                    Comportement obtenu:
                    Pas de retour du son.

                    Donc ça ne fonctionne pas, point.

                    Depending on the time of day, the French go either way.

          • [^] # Re: Aide sur Pulseaudio

            Posté par  . Évalué à 10. Dernière modification le 16 octobre 2015 à 11:06.

            Quel logiciel exactement te contrains à l'utiliser? Je sais que je ne suis utilisateur ni de gnome, ni de KDE, mais à l'heure actuelle je n'ai jamais été contraint d'utiliser PA, et avec alsa, ça juste marche.

            Comment vous faites ?

            J'ai un HDA intel intégré (comme tout le monde je présume) et sans PA pas moyen d'avoir du mixage sans conflits d'accès à la "carte" son, pas moyen d'avoir une gestion du volume cohérente, pas moyen qu'il se souvienne du volume par output (speakers, casque), pas de normalisation du volume, pas de son sur les vidéos HTML5 de Firefox, etc…

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Aide sur Pulseaudio

              Posté par  (Mastodon) . Évalué à 10.

              Je suis bien incapable de te répondre : sur mon portable j'ai aussi une intel HDA intégrée, et pas Pulseaudio. Et je n'ai jamais eu de soucis avec le son : j'en ai, je peux le couper, le régler, le remettre, le sauvegarder, mettre plusieurs sources audio en parallèle etc.

              Pour sauvegarder tes paramètres audio tu peux faire :
              alsactl store

              Mais le son c'est parfois de la magie noire…
              ALSA c'est de la sorcellerie.
              Et Pulseaudio un générateur de rituels occultes.

              Alors bon courage…

              Yth.

            • [^] # Re: Aide sur Pulseaudio

              Posté par  . Évalué à 9.

              Comme Yth, j'ai Alsa sans PulseAudio (PC sous Debian testing). Il y a quelques années, il fallait configurer Dmix, mais ce n'est plus nécessaire : avec la config Alsa par défaut, le mixage fonctionne. Debian fait aussi un alsactl store automatique à l'extinction. Pas besoin de configurer quoi que ce soit pour le fonctionnement de base.

              Par contre, le son en général reste une galère, surtout sous Linux, PulseAudio ou pas. Si je suspend ou hiberne mon PC alors que la carte son est active, le pilote plante : je dois tuer les processus utilisant la carte son, enlever puis remettre les modules noyau. Et quand je branche un DAC USB, je ne peux plus utiliser Chromium : de temps à autre il produit des bruits douloureux dans le casque du DAC, alors qu'il envoie le son normal dans la carte intégrée. Sur une dizaine de cartes son différentes et plusieurs PC, j'ai toujours eu des problèmes plus ou moins critiques.

              Linux n'y est pour rien, mais on peut souvent mesurer l'activité du PC à partir des perturbations du son sur la carte son intégrée.

            • [^] # Re: Aide sur Pulseaudio

              Posté par  . Évalué à 5.

              pas moyen d'avoir du mixage sans conflits d'accès à la "carte" son

              ?

              Alsa a un mixer software depuis… une bonne dizaine d’années ? Si tu as des soucis c’est que tu as une application qui accède à la carte son en direct. Pulseaudio ne corrige pas le souci, j’ai toujours des problèmes de conflit d’accès avec des merdes proprio qui tiennent à passer direct à la carte. Sur ce point j’ai aucune aucune différence entre Alsa et PA.

              pas moyen qu'il se souvienne du volume par output (speakers, casque)

              C’est rigolo moi c’est l’inverse, c’est Pulseaudio qui oublie les volumes à chaque redémarrage.

              Chez alsa c’était géré dans des scripts d’init (un à l’arrêt pour enregistrer les niveaux, un au démarrage pour les restaurer). Si ça marche pas chez toi c’est probablement parce que les distribs modernes ne les fournissent plus (parce qu’ils présupposent que tout le monde utilise PA)

              • [^] # Re: Aide sur Pulseaudio

                Posté par  (site web personnel) . Évalué à 4. Dernière modification le 17 octobre 2015 à 14:43.

                Etant sous Archlinux depuis des années, je me suis passé de Pulseaudio pendant longtemps mais je l'ai finalement installé sur une nouvelle config l'an dernier. J'avais également ce soucis de volume au démarrage que j'ai réglé à coups de

                ponymix unmute
                ponymix set-volume 85
                

                dans le fichier .xinitrc.

                Concernant les vieux programmes propriétaires qui restent muets en se plaignant de ne pas avoir accès à /dev/dsp en démarrant, je lance cette petite commande juste avant de les démarrer:

                echo "PROGRAM.BIN 0 0 direct" > /proc/asound/card0/pcm0p/oss
                

                où PROGRAM.BIN est le nom de l'exécutable.

                Pour le reste, je ne remarque aucune différence à l'usage.

            • [^] # Re: Aide sur Pulseaudio

              Posté par  . Évalué à 6. Dernière modification le 20 octobre 2015 à 15:13.

              J'ai également une HDA Intel intégrée, et sous Alsa (et dmix) elle fonctionnait parfaitement. Le seul truc que j'avais parfois à faire avec certains jeux, comme Enemy Territory, c'était de taper :

              # echo "et.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss
              # echo "et.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss
              

              Depuis Pulseaudio, la gestion du son sur mon bureau est devenu un enfer :
              - Un volume sonore beaucoup moins puissant à niveau identique (et l'amplification 150% qui produit un son dégueulasse déformé ;
              - Un son dégueulasse qui crache et saute dès que la machine est chargée, ou qui crachote tout simplement sans raison même lorsque la charge n'est pas élevée (typique sous Wine) ;
              - Un processus pulseaudio qui bouffe facilement 10 à 20% de CPU là où, dans les mêmes usages, Alsa était auparavant totalement discret (exemple typique, un appel Skype avec seulement une autre personne, c'est 20% de CPU pour Skype + 10% pour Pulseaudio, une conférence Mumble à 10, c'est 10% de CPU pour Mumble et 10 à 20% pour Pulseaudio, la même conférence sur TS, c'est 20% de CPU pour TS, 20% pour Pulseaudio, etc. et sous Alsa c'était pareil pour les applications voire inférieur, sans que je ne vois Alsa au même niveau que Pulseaudio). Je ne sais pas si les concepteurs de Pulseaudio se rendent compte de ce que ça signifie, avoir 20 à 40% d'un CPU Core2Quad Q9300 @ 2.50GHz bouffés pour seulement sortir du son (alors qu'avant sous Alsa, c'était 5 à 10% !) ;
              - Des jauges de volume au comportement anti-ergonomique par défaut (cf. flat-volume), pour ne pas dire totalement erratique ;
              - Un volume qui parfois se met à fluctuer sans raison sur les haut-parleurs (volume sonore qui descend sans qu'aucune jauge ne bouge, puis remonte, puis redescend, etc.)
              - La prise jack des écouteurs systématiquement sur muet à chaque redémarrage ;
              - Du son qui sort quand même sur les haut-parleurs 5.1 même lorsque le volume général est à 0 ;
              - Certaines applications (anciens jeux qui auparavant fonctionnaient avec l'astuce donnée plus haut) qui n'ont tout simplement plus de son ni la possibilité de contourner désormais ;
              - Une gestion du micro bordélique, à ne plus savoir quelle « carte » (ou entrée pulseaudio) choisir pour savoir laquelle correspond à celle où le micro sera reconnu ;
              - La puissance du flux micro bien trop faible ;
              - Une jauge d'amplification du volume micro qui ne dispose plus que de 3 niveaux : inaudible trop faible, dégueulasse robotique, inaudible perçage de tympans, avec à chaque changement de cette dernière la transmission sous forme de flux audio de l'ensemble des données traitées par le processeur sur l'instant (bon, en réalité, ça pète juste les oreilles de tous ceux en conférence avec un gros son immonde qui beugle pendant quelques secondes) ;
              - Un bug totalement rédhibitoire (je l'ai longtemps eu, je ne sais pas où ça en est, j'ai pris mes précautions depuis), où lors d'une discussion Skype/Mumble, le son des applications de mon bureau Linux (lecteur audio) est subitement rédirigé vers le flux du micro, alors que le micro est volontairement placé sur muet ! Exemple concret : je suis en discussion Skype ou sur mumble avec des amis tandis que je veux regarder un film porno, je mets donc le micro sur muet, je lance la lecture, et tous les autres entendent le son de la vidéo porno ! :-p
              - Etc.

              Mais tout va bien, Pulseaudio fonctionnerait chez pas mal de monde, il paraît…

              • [^] # Re: Aide sur Pulseaudio

                Posté par  . Évalué à -2.

                Mais tout va bien, Pulseaudio fonctionnerait chez pas mal de monde, il paraît…

                Ben oui, car je n'ai aucun des problèmes que tu décris (et pourtant j'ai rien fait de particulier), et d'autres personnes ont l'air d'en être tout autant satisfaites.

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Aide sur Pulseaudio

                Posté par  (site web personnel, Mastodon) . Évalué à 7.

                Je possède un processeur Intel i7 4770 (Haswell) avec chipset audio Intel intégré. Pour l'environnement de bureau, j'utilise GNOME 3.18, pour le lecteur audio, audacious 3.6.2. Le tout sous Arch avec kernel 4.2.3 et PulseAudio 7.0. Je suis précis dans les numéros de version, mais la situation était finalement identique avec les versions précédentes ;)

                Maintenant, souci, pas souci ? On ne va pas faire durer le suspense 107 ans, tout comme xcomcmdr, tout fonctionne super bien.

                Niveau consommation CPU, pour écouter de la musique au format FLAC, ça doit être totalement insignifiant, puisque en continuant mes tâches quotidiennes en parallèle, ça oscille entre 0 et 1% d'occupation CPU. Quand je lis un film 1080p (H.264 + AC3), ça grimpe à 8%, mais j'imagine que le gros du travail concerne plutôt le décodage des images.

                Je n'ai jamais eu un son dégueulasse (FLAC, AC3 / DTS, vidéos YouTube…). En cas de charge élevée, il serait sans doute préférable de revoir les priorités des différents processus. Et si ça arrive régulièrement, peut être faire en sorte que PulseAudio soit correctement configuré par défaut.

                Pas souvenir d'avoir déjà entendu le volume fluctuer. Que je branche mon micro-casque en façade ou derrière la machine, la détection n'a jamais posé problème. Pas non plus rencontré de souci concernant le volume du micro-casque, que ce soit avec Firefox Hello ou Google Hangout.

                Les jauges de volume sous GNOME fonctionnent bien, ont le comportement attendu, sont intuitives. Rien à redire.

                Pour le reste des problèmes (micro sur mute, sortie 5.1 même quand le volume à zéro…), je n'ai pas souvenir d'avoir déjà rencontré de tels comportements.

                Franchement, chez moi, ça juste marche. Je serais donc curieux de savoir s'il existe des points communs chez ceux chez qui tout fonctionne bien, puis chez ceux chez qui tout déconne. Mauvaise distribution, mauvaise configuration par défaut, applications dont la prise en charge de PulseAudio n'est pas convenable (pour Skype, on ne peut pas vérifier, mais pour Mumble, t'es pas non plus le premier que j'entends avoir des soucis).

                Non, parce que c'est tout de même étonnant qu'il n'y ai absolument rien à redire chez certains, tandis que chez d'autres, ça semble être l'enfer au quotidien.

                • [^] # Re: Aide sur Pulseaudio

                  Posté par  . Évalué à 5.

                  Non, parce que c'est tout de même étonnant qu'il n'y ai absolument rien à redire chez certains, tandis que chez d'autres, ça semble être l'enfer au quotidien.

                  C'est en fait assez habituel en informatique.
                  Les raisons sont au final assez simples:

                  • configurations matérielles extrêmement diversifiées (il me semble qu'Apple à une époque ne vendait des systèmes que pour des config matos définies, ça me semble malin pour éviter ce type d'emmerdes et ainsi choper aisément une réputation de truc qui juste marche.)
                  • usages tout aussi variés: on peut avoir affaire à un développeur qui code juste pour le taf et après oublie la moitié de ses compétences, à un geek passionné qui à une connaissance pointue de son système du côté matériel ou du côté logiciel, voire même des deux, ou encore à Mme michu dont le chat grimpe souvent sur le clavier, etc etc
                  • des applications utilisées par la personne plus ou moins bien branlées

                  Donc, trouver des points communs, ce serait probablement facile, mais on pourrait aussi trouver une tonne de points communs entre ceux chez qui ça juste marche et les autres.
                  Perso, je préfère avoir un système simple (pas à utiliser, simple au niveau archi logicielle), et éviter les surcouches multiples permets ça. Parfois ça cause des emmerdes à devoir chercher pourquoi un truc déconne et comment le corriger, mais sur Debian il faut admettre que c'est rare, très rare. Mais on me diras que Debian, c'est déjà pas mal de surcouches par rapport à LFS par exemple :)

                  Après… dans quelle circonstances peut-on dire que la faute est à telle ou telle partie d'un sous-système et non aux logiciels qui l'utilisent… pas simple. J'ai longtemps été très agressif envers windows, jusqu'a que ce que je passe à Debian, ou je me suis aperçu qu'en fait, le problème c'était pas forcément l'OS, mais l'usage par l'application (et l'utilisation du logiciel par l'utilisateur, bien sûr).

                  • [^] # Re: Aide sur Pulseaudio

                    Posté par  . Évalué à 0.

                    éveloppeur qui code juste pour le taf et après oublie la moitié de ses compétences

                    Je suis curieux de savoir le lien de cause à effet. S'il perd ses compétences, c'est qu'il fait tout le temps la même chose au boulot, ce qui est loin d'être toujours le cas pour la majorité des situations (en tout cas ce n'est pas la mienne, j'ai tendance à avoir une vie en dehors du code et pourtant mon boulot a fait que j'ai vachement monté en compétence, et ce toujours un peu plus tous les jours).

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: Aide sur Pulseaudio

                      Posté par  . Évalué à 3.

                      Je parlais de les oublier le temps qu'il est hors du taf… j'ai parlé de dev, j'aurai pu parler de n'importe quel professionnel de l'informatique en fait. De même, "oublier la moitié[…]" est une façon de parler, s'il les oubliais vraiment il ne pourrais pas les retrouver en franchissant le seuil de sa boîte.

        • [^] # Re: Aide sur Pulseaudio

          Posté par  (site web personnel) . Évalué à 5.

          Tu m'intéresses là… Moi aussi j'ai des problèmes de son (pulseaudio qui ne se lance pas) depuis mon passage à Mageia 5, alors que toutes les Mageia précédentes fonctionnaient sans soucis à ce niveau là. Je n'ai même pas ouvert de bug, ayant ouvert un bug sur un autre sujet critique (base RPM régulièrement corrompue) sans que rien n'avance… Encore un rapport qui va finir fermé au moment de l'arrivée en fin de vie de la distrib…

          • [^] # Re: Aide sur Pulseaudio

            Posté par  . Évalué à 7.

            J'ai fini par régler mon problème (vive les vacances !) en trouvant la solution sur :
            archlinux troubleshooting
            J'ai changé les paramètres de default-fragments et default-fragment-size-msec à respectivement 5 et 2 dans /etc/pulse/daemon.conf. A priori c'est propre à mon DAC usb.
            Depuis la version 5, cela manque un peu de réactivité chez mageia, il y a eu un bug sur polkit qui m'a bien pourri la vie pendant 3 mois.

    • [^] # Re: Aide sur Pulseaudio

      Posté par  . Évalué à 1.

      Bon alors, c'est sûr je vais me faire moinser, car c'est hors sujet.

      Désolé pour toi, si tu voulais te faire moinsser tu as vraiment mal choisi ton hors sujet, ça plusse grave! ;-)

  • # Contrôle du volume en réseau

    Posté par  . Évalué à 2.

    Savez-vous s'il est possible de de contrôler le volume de PA via le réseau ? Sa documentation parle de jouer les sons en réseau, mais ne dit rien sur le mixer. Mon objectif est de pouvoir contrôler le volume de mon ordinateur depuis un téléphone sous Android (je suis prêt à développer une application moi-même si je sais quelle méthode il faut utiliser).

    • [^] # Re: Contrôle du volume en réseau

      Posté par  . Évalué à 2.

      Je n'ai jamais essayé et je connais très mal pulseaudio, mais en cherchant un peu, j'ai (peut-être!) des pistes:

      Dans le paquet (debian) pulseaudio-utils, on a un outil appelé pactl (une version simplifiée de pacmd, même paquet).

      Extraits du man:

      pactl - Control a running PulseAudio sound server

      -s | --server=SERVER Choose the server to connect to.

      set-source-output-volume OUTPUT VOLUME

      Quand je fais un pactl -s 127.0.0.1 info, l'outil tente d'ouvrir une connexion sur le port 4713. La connexion échoue (pas le bon port? Pas de contrôle réseau activé dans PA?). Pas le temps d'aller plus loin. J'espère que ce n'est pas une fausse piste.

      • [^] # Re: Contrôle du volume en réseau

        Posté par  . Évalué à 3.

        Effectivement par défaut le serveur pulseaudio n'active pas le transport tcp (seulement le transport socket unix).

    • [^] # Re: Contrôle du volume en réseau

      Posté par  . Évalué à 2.

      S'il existe un outil en ligne de commande pour piloter PA (style le amixer de alsa) alors tu peux simplement passer par ssh.

  • # Deux versions ?

    Posté par  . Évalué à 10.

    J'ai un peu de mal à comprendre, ils maintiennent et font évoluer deux versions de Pulseaudio ? C'est la première fois que je vois ça…

    Depuis le passage à PA7 je retrouve les joies des débuts de pulseaudio : des craquements incessants, le son qui se coupe quand je lance une vidéo (obligé de tout fermer puis taper pulseaudio -k), et l'impossibilité de remettre la version 6 (dépendances non satisfaites).

    Bref c'est le genre de truc qui me met hors de moi et me donne envie d'installer FreeBSD.

  • # Mécontent de PA

    Posté par  . Évalué à 10.

    Je suis mécontent de PA et il ne me sert à rien. L'objectif est de ne garder qu'Alsa pour le son et de pouvoir se servir de Jack. PA est difficilement ou totalement incontournable sur certains matériels. J'ai réussi à virer PA sur deux mes 3 PC. Sur le 3°, plus récent, pas de PA, pas de son. J'ai tout essayé. Le pire, c'est l'incompatibilité de PA avec Jack. J'ai ouï dire que Jack peut fonctionner avec PA mais ça devient très compliqué.
    Il est regrettable que toutes les distributions aient fait le choix PA pour obtenir le son. L'utilisateur devrait pouvoir choisir entre soit un serveur de son, ex Jack ou PA, soit une configuration pur Alsa.

    • [^] # Re: Mécontent de PA

      Posté par  (Mastodon) . Évalué à 2.

      Ah c'est marrant, ma distrib n'a pas Pulseaudio.
      On peut bien sûr aisément l'installer (ou simplement apulse) si on souhaite, mais il n'y est pas de base.
      Et c'est l'une des plus connues (à défaut d'être une des plus utilisées).

      Yth, le choix, le choix, bah on l'a, na…

      • [^] # Re: Mécontent de PA

        Posté par  . Évalué à 4.

        c'est l'une des plus connues

        On attend son nom

        • [^] # Re: Mécontent de PA

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Je ne sais pas pour lui, mais une Debian où tu ne laisses que le système minimal lorsque l'installeur propose des choix, ça devrait faire l'affaire.

          Ensuite, tu installes tes paquets les uns après les autres (attention à désactiver l'installation des recommandations et à gnome-shell qui dépend/recommande sûrement de pulseaudio).

          • [^] # Re: Mécontent de PA

            Posté par  . Évalué à 1.

            ça devrait faire l'affaire

            Et non… J'utilise Debian (3x(jessie, testing, sid) sur mes trois PC, aucun gnome-***. Si je n'avais qu'une carte son ce serait relativement simple. Ce n'est pas le cas. Sur deux PC, j'ai pu configurer correctement la priorité des cartes. Sur le 3° PC, récent, c'est bizarrement impossible, sauf avec PA. Aucune des méthodes préconisées sur les sites d'Alsa et Debian ne fonctionne.

            • [^] # Re: Mécontent de PA

              Posté par  . Évalué à 2.

              Je ne connais pas ce type de problème, mais serait-il possible qu'une de tes cartes son n'ait pas de firmware assez développé?
              Après tout, tu as bien parlé d'une machine récente. Hors, il me semble que les fabricants de cartes ne font pas toujours des pilotes pour Linux… et rarement en open source, donc peut-être un pilote de non-free à rajouter?

            • [^] # Re: Mécontent de PA

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Je répondais surtout à la question "quelle distribution n'impose pas pulseaudio ?".

              Je pense que l'installation minimale de Debian (sans aucun task-desktop*) correspondrait à ce critère.

              • [^] # Re: Mécontent de PA

                Posté par  (site web personnel) . Évalué à 5.

                La commande apt-rdepends -r pulseaudio renvoie grosso-modo ça :

                cairo-*
                design-desktop*
                gnome-core
                gnome
                task-gnome-desktop
                gqrx-sdr
                kde-telepathy*
                libcanberra-pulse*
                ltsp-client
                osspd*
                acfax
                osspd-dbg
                parl-desktop*
                projectm-pulseaudio
                pulseaudio*
                paprefs
                
                • [^] # Re: Mécontent de PA

                  Posté par  . Évalué à 1.

                  Désinstaller PA est très facile sur Debian et bien d'autre distrib. Ensuite, sur certains matériels, fixer la priorité des cartes son avec Alsa est une autre histoire. Parfois ça marche, parfois non.

        • [^] # Re: Mécontent de PA

          Posté par  . Évalué à 5.

          On attend son nom

          Une LFS, bien sûr ! :-)

          (→[])

        • [^] # Re: Mécontent de PA

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 18 octobre 2015 à 14:38.

          Slackware non plus n'a pas PA et le seul logociel qui me réclame PA est Skype©®™ qu'on peut faire tourner plus ou moins correctement avec apulse (j'ai une machine sur laquelle il fonctionne bien et l'autre avec laquelle mes contacts ne m'entendent pas alors que le service echo de Skype m'enregistre correctement, va comprendre).

          • [^] # Re: Mécontent de PA

            Posté par  (Mastodon) . Évalué à 3.

            Exactement, et skype est bien la seule appli qui nécessite apulse.
            Donc pulseaudio, on s'en passe aisément.
            Et on l'installe aisément si on veut aussi.

            Yth.

    • [^] # Re: Mécontent de PA

      Posté par  . Évalué à 0.

      Tu dis que PA ne sert à rien et juste après, tu dis qu'il est nécessaire pour faire fonctionner le son sur un de tes PC.

      C'est moi où il y a comme une incohérence dans tes propos ?

  • # alternative : sndio, projet OpenBSD pour l'audio

    Posté par  . Évalué à 10. Dernière modification le 16 octobre 2015 à 16:07.

    Sans être expert du domaine, j'ai déjà eu à bidouiller pulseaudio, alsa, et un peu jack pour des projets et je ne peux qu'être surpris par mon constat : c'est le bordel.

    Alsa n'a quasi aucune doc et quand on cherche des choses on tombe souvent sur de très vieux articles (je suis même tombé sur un module pour linux 2.4 …), pulseaudio n'a quasi aucune doc, jack est sympa mais pas toujours simple à prendre en mains… Bref, pas un seul outil aussi simple qu'un stupide cat à prendre en mains pour manipuler l'audio, c'est toujours un peu spécifique, un peu complexe, un peu pas assez documenté.

    Et là, je tombe sur sndio avec un papier super intéressant à lire, qui montre comment on devrait gérer l'audio. Le papier est clair, simple, concis, montre des exemples d'usage, nickel. Pourquoi 5 ans plus tard nous n'avons toujours pas ça ? Pourquoi avoir un outil aussi complexe que PulseAudio ou aussi rustre qu'alsa (dont l'interface alsamixer ne me permet pas de voir seulement les périphériques de capture puis que F4 ferme l'application…) ?

    Une possibilité, pourtant simple, que je souhaiterai avoir c'est rediriger l'audio d'une application (ou d'un ensemble d'applications) en un seul flux. Exemple pourtant tout simple, et pourtant si complexe à mettre en place. Jack semble pouvoir le faire, mais même en galérant comme pas permis j'ai pas réussi.

    Mon avis : l'audio sous linux ça marche très bien pour le grand public, mais au moindre problème ou au moindre besoin spécifique on doit se taper un paquet de nuits blanches.

    • [^] # Re: alternative : sndio, projet OpenBSD pour l'audio

      Posté par  . Évalué à 2.

      (dont l'interface alsamixer ne me permet pas de voir seulement les périphériques de capture puis que F4 ferme l'application…)

      Changes d'émulateur de terminal ou de gestionnaire de fenêtres alors (ou au moins leur configuration), parce que chez moi F4 ne ferme absolument pas l'application. Sur aucune machine sous Debian que j'ai utilisée, F4 n'a jamais fermé alsamixer (ni aucune fenêtre en fait).

      Une possibilité, pourtant simple, que je souhaiterai avoir c'est rediriger l'audio d'une application (ou d'un ensemble d'applications) en un seul flux.

      On a pas la même définition de simple, je le crains.

      • [^] # Re: alternative : sndio, projet OpenBSD pour l'audio

        Posté par  . Évalué à 6.

        Sous GNU/Linux et UNIX en général tout est fichier non ? C'est bien ce que j'ai appris en débutant en tout cas. Et les variables d'environnement sont là pour passer contrôler l'environnement d'exécution du programme. Une sortie audio devrait être un paramètre simple à modifier, aussi simple que d'indiquer une variable d'environnement. Donc question, pourquoi ceci n'est pas faisable :

        AUDIO_OUT_DEV=/dev/XXX AUDIO_IN_DEV=/dev/YYY application
        

        Avec éventuellement la sortie qui serait un fichier (voire un programme qui va écrire dans un fichier, soyons fous). Du coup la seule chose à faire pour enregistrer le son qui sortirait d'un programme serait d'indiquer une autre valeur à AUDIO_OUT_DEV. Périphérique éventuellement virtuel, avec lequel on pourrait mixer des entrées, envoyer ça sur le réseau, ajouter un petit effet, bref faire un peu ce qu'on veut, facilement, en contrôlant le flux avec une application simple à prendre en mains.

        • [^] # Re: alternative : sndio, projet OpenBSD pour l'audio

          Posté par  . Évalué à 3.

          Sous GNU/Linux et UNIX en général tout est fichier non ?

          Pas vraiment, non. Si tu veux un système qui aie vraiment poussé cette idée, il faut plutôt aller voir du côté de plan9, c'est du moins ce que l'on m'a dis.
          De toute façon, GNU/Linux n'est pas UNIX qui est un OS à part, ni même POSIX, qui est une norme inspirée d'UNIX. Cf ce lien que m'a fourni wikipedia et que, je l'admets, je n'ai pas envie d'aller lire :) (du coup on peut me répondre que vu l'âge du document, il est caduc).

          Je crois avoir le souvenir de quelqu'un ici répondre à ce type d'argument en disant, par exemple, que les cgroups ne sont pas des fichiers.

          Et les variables d'environnement sont là pour passer contrôler l'environnement d'exécution du programme. Une sortie audio devrait être un paramètre simple à modifier, aussi simple que d'indiquer une variable d'environnement. Donc question, pourquoi ceci n'est pas faisable :

          AUDIO_OUT_DEV=/dev/XXX AUDIO_IN_DEV=/dev/YYY application

          Je ne sais pas si c'est possible ou pas, je ne m'y connais pas assez. D'ailleurs, est-ce impossible avec ALSA, et si ça l'est, l'était-ce aussi avec OSS, ou l'est-ce devenu par l'évolution du système, le son étant utilisé par de nombreuses applications à la fois, contrairement à l'écran (qui n'est utilisé que par X11 il me semble)?
          Il est probable que ça le serait, avec un serveur de son (comme Xorg qui est un serveur graphique). N'est-ce pas ce que PA essaie d'être, d'ailleurs?

          • [^] # Re: alternative : sndio, projet OpenBSD pour l'audio

            Posté par  . Évalué à 5.

            Je crois avoir le souvenir de quelqu'un ici répondre à ce type d'argument en disant, par exemple, que les cgroups ne sont pas des fichiers.

            Pourtant les cgroups sont des fichiers (pour être précis ce sont des dossiers dans un système de fichier cgroup).

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: alternative : sndio, projet OpenBSD pour l'audio

            Posté par  . Évalué à 4.

            Le « pas vraiment » me gêne : pourquoi ? Ce n'est pas parce qu'on n'a pas poussé cette solution pour l'audio sous linux que « ce n'est pas comme ça qu'on doit faire sous linux ». Et effectivement, Plan9 pousse ces concepts à un tout autre niveau. Il y a de vraiment bonnes idées à reprendre selon moi.

            Je vois à peu près ce que j'aimerai avoir, pouvoir manipuler, et de façon très simple. Je ne connais pas la raison qui fait qu'on a des outils tels qu'aujourd'hui, et si quelqu'un le sait, j'en veux bien la raison.

            • [^] # Re: alternative : sndio, projet OpenBSD pour l'audio

              Posté par  . Évalué à 2.

              Le « pas vraiment » me gêne : pourquoi ? Ce n'est pas parce qu'on n'a pas poussé cette solution pour l'audio sous linux que « ce n'est pas comme ça qu'on doit faire sous linux ».

              Je ne faisais que parler de l'état des choses, pas de l'idéal. Je ne suis ni dev kernel, ni dev temps-réel (l'audio c'est du temps réel pour moi), donc je ne sais pas pourquoi c'est ainsi.

              Il semblerait que OSS mettait un fichier /dev/dsp, que l'on pourrait accéder via les appels système open/close/read/write (qui sont les appels systèmes pour ouvrir/fermer/lire/écrire des fichiers, sur un système POSIX).

              Du coup, la question est plutôt, pourquoi avoir arrêté d'utiliser un fichier accessible simplement pour gérer le son?
              Mais l'article dont descend ce fil devrais te donner un indice: s'il suffit d'écrire dans un fichier pour émettre du son, comment faire pour centraliser la gestion du son? Enfin, c'est la première question qui me viens à l'esprit, n'ayant jamais utilisé OSS je ne sais pas comment ça marche même en terme d'utilisateur (et en terme de programmation, je n'ai utilisé ni l'un ni l'autre. Et le jour ou je devrais, je passerai par une bibliothèque, comme tout le monde).

              Sinon, tu peux jouer du son en ligne de commande, il te suffit de passer tes données directement à aplay. Mais si les applications faisaient ça, je pense que nos CPUs n'aimeraient pas trop… pas sûr que les pipes texte (rappel: la philosophie UNIX c'est que tout doit être lisible par l'homme, donc du texte… pour du son, ça me parait pas très pertinent, parser ça consomme) soient très performants.

              Note: vu qu'on peut accéder à OSS par un fichier dans /dev, je me demande si y'a moyen de jouer avec les socket BSD par la aussi…

              • [^] # Re: alternative : sndio, projet OpenBSD pour l'audio

                Posté par  . Évalué à 9. Dernière modification le 26 octobre 2015 à 10:11.

                pas sûr que les pipes texte (rappel: la philosophie UNIX c'est que tout doit être lisible par l'homme, donc du texte… pour du son, ça me parait pas très pertinent, parser ça consomme) soient très performants

                Les pipes ne transmettent pas nécessairement du texte. Et aplay d’ailleurs ne s’attend pas à avoir du texte en entrée. Et de fait les pipes sont très efficaces, légèrement plus que les sockets unix qui sont eux même plus efficaces que les sockets TCP.

                Mais l'article dont descend ce fil devrais te donner un indice: s'il suffit d'écrire dans un fichier pour émettre du son, comment faire pour centraliser la gestion du son? Enfin, c'est la première question qui me viens à l'esprit, n'ayant jamais utilisé OSS je ne sais pas comment ça marche même en terme d'utilisateur

                Tu mets un driver noyau derrière un fichier de type spécial, c’est comme ça que fait OSS. Dans le modèle d’OSS /dev/dsp n’est pas un accès direct à la carte son mais un accès à OSS (un peu comme le /run/user/$UID/pulse/native de pulseaudio, sauf que OSS c’est en kernelspace avec l’API noyau des périphériques tandis que pulseaudio c’est en userspace avec un socket unix standard)

    • [^] # Re: alternative : sndio, projet OpenBSD pour l'audio

      Posté par  . Évalué à 2.

      Pourquoi avoir un outil aussi complexe que PulseAudio

      Je ne sais pas peut etre parceque le dev original aime bien augmenter la complexite des logiciels?

      Et pour les pro-je-laisse-deviner-qui j'aimerai la reponse a la question suivante:

      Toujours aucune idee de comment faire pour avoir un truc equivalent a nice en userland)

  • # Documentation systèmes audio sous Linux

    Posté par  . Évalué à 10. Dernière modification le 16 octobre 2015 à 16:55.

    Suite aux multiples personne signalant un manque de documentation:

    LinuxMAO est un site sur le son sous GNU/Linux (composition, mixage, édition…). Il y a pas mal de tutos, mais plutôt orientés grand public, par exemple pour pulseaudio ou pour jack. Il y aussi un forum plutôt actif.

    J'espère que ça pourra en aider quelques uns (et si vous connaissiez, désolé pour le bruit)

    Et merci pour l'article bien détaillé!

  • # Un contre-exemple

    Posté par  . Évalué à 9.

    J’ai vu beaucoup de plaintes sur PulseAudio. Je voulais juste dire que PulseAudio est une dépendance pour GNOME, et que ALSA ou PulseAudio, le son n’a jamais mieux fonctionner avec l’un ou l’autre, à part que je profite de fonctionnalités supplémentaires dans KDE comme le changement de volume par application (Xfce se contentant, même avec l’applet adaptée, de ne donner accès qu’au réglage du son).

    Et si le son était parfois problématique quand je suis arrivée sous GNU/Linux il y a maintenant 5 ans, il semble plutôt bien fonctionner désormais. La seule exception semble être le microphone avec Mumble qui semble n’en faire qu’à sa tête alors que le tout simple gnome-sound-recorder semble faire le boulot (à part qu’il s’intègre mal dans ce qui n’est pas GNOME…).

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Un contre-exemple

      Posté par  . Évalué à 1.

      J'ai connu l'heureuse époque où PA n'existait pas, tout fonctionnait bien avec Alsa et éventuellement Jack en option. Puis PA est arrivé et depuis ce moment, c'est le foutoir sinon le pataquès…

    • [^] # Re: Un contre-exemple

      Posté par  . Évalué à 7.

      Moi c'est le contraire. Avant je pouvais régler le son dans VLC sans problèmes. Maintenant, pour une raison inconnue, le volume VLC est locké avec le volume général. Donc quand j'y touche c'est le bordel. Merci pulseaudio.

    • [^] # Re: Un contre-exemple

      Posté par  . Évalué à 3.

      Pour mumble, c'est possible que mumble règle automatiquement le niveau de ton micro (j'avais eu ce problème avec skype).

      bépo powered

  • # Transparence réseau

    Posté par  . Évalué à 5.

    C'est marrant qu'au moment où on passe de X à Wayland (bon, j'anticipe un peu), donc en perdant la transparence réseau (en tout cas native), une des fonctionnalités de PulseAudio est précisément la transparence réseau…

    • [^] # Re: Transparence réseau

      Posté par  . Évalué à -2.

      Je ne comprends rien à ce post. Peux-tu expliquer ?

      • [^] # Re: Transparence réseau

        Posté par  . Évalué à 2.

        Il dit que la ou le passage de X11 à wayland nous fait perdre le fait de pouvoir déporter l'information sur le réseau, PA ajoutes cette possibilité.

        • [^] # Re: Transparence réseau

          Posté par  (site web personnel) . Évalué à 9.

          le passage de X11 à wayland nous fait perdre le fait de pouvoir déporte

          En fait, ce n'est pas vrai. La transparence réseau est un point tellement important dans X11 que la question a été rapidement mise sur le tapis de Wayland. Il y aura donc bien un déport, par exemple sous forme RDP ou SPICE. Or nous sommes tous d'accord pour accepter le fait que RDP est mieux que X11 en terme de bande passante et de latence réseau…

          X11 n'est bon sur le réseau qu'avec le proxy NX crée par No-Machine et jamais intégré, ni dans Xorg, ni dans ssh…

          • [^] # Re: Transparence réseau

            Posté par  . Évalué à 2.

            Oui, je sais que les gens de Wayland disaient qu'il valait mieux utiliser d'autres protocoles pour l'affichage déporté. C'est pour ça que je parlais d'export natif qui n'est pas et ne sera pas dans Wayland.

            C'est vrai que l'export X ne fonctionne bien qu'en LAN mais ça m'a rendu de fiers services… Donc devoir installer et configurer un autre service (RDP ou autre) est bien une perte même si les bonnes distributions feront ça tout seul!

            Je ne connais pas bien PA mais lui le fait en natif pour le son (peut-être en s'appuyant sur d'autres protocoles). Perso, je n'ai pas d'utilisation de ça mais j'imagine que que ça sert.

            En passant, j'ai récemment découvert XPRA qui est vraiment cool! Plus qu'à attendre WPRA (Wayland Persistent Remote Applications).

            • [^] # Re: Transparence réseau

              Posté par  (site web personnel) . Évalué à 9.

              Qui utilise encore X en 'natif' ? Personnellement, cela fait longtemps que j'ai arrêter les telnet + xauth merge + export DISPLAY et autres ;-) Je pense que comme 99% des personnes, je fais du 'ssh -X' ou du x2goclient…

              Bref, si le déport RDP, SPICE (ou xpra que j'aime beaucoup aussi) est intégré nativement dans la session ssh, cela conviendra quasiment pour tout le monde.

  • # Je dois avoir de la chance

    Posté par  . Évalué à 10.

    J'ai suis très satisfait de PulseAudio.
    Je dois avoir de la chance.
    Pourtant je pense lui demander par mal de chose à mon PulseAudio :

    • je bascule régulièrement la sortie audio entre les haut-parleurs de mon ordinateur portable, les haut-parleurs de mon écran HDMI au bureau, les haut-parleurs de mon écran DisplayPort à la maison et bien sur la sortie casque
    • pour les conférences audio, j'utilise un casque USB (avec carte son intégrée) au bureau et un autre à la maison de marque différente. Parfois j'oublie le casque et doit utiliser le micro du portable. Que ce soit sous EtherPad, appear.in, gotomeeting ou Skype, ça marche sans bidouille ni reboot
    • j'utilise parfois un enregistreur audio autonome pour capter des réunions. Il n'y a aucun lien avec PulseAudio sauf qu'en le branchant en USB j'ai constaté qu'il pouvait servir de micro d'excellente qualité. Je n'ai aucun soucis pour utiliser cette source en entrée tout en spécifiant une sortie différente
    • j'ai une oreillette bluetooth que j'utilise principalement avec mon téléphone mais qui m'a dépanné plusieurs sur mon ordinateur portable
    • à la maison ma chaine HiFi est relié à un petit PC avec Kodi. Quand je veux écouter de la musique depuis mon ordinateur portable je peux le faire car le petit PC est vu comme une sortie réseau sous PulseAudio
    • quand je veux gagner quelques Watt, je laisse le petit PC éteins et j'utilise la connexion Bluetooth vers mon ampli HiFi qui la gère
    • j'ai une pédale d'effet pour ma guitare relié à un ampli. En reliant la pédale d'effet en USB à mon portable pour utiliser un logiciel de configuration plus avancé (sous VirtualBox/Windows :-/) j'ai eu la bonne surprise de voir que la pédale d'effet était reconnu sous Linux comme une carte son. Du coup je peux écouter de la musique sur mon ampli guitare

    Il m'arrive d'avoir un petit soucis parfois mais c'est insignifiant. Probablement moins de un cas sur cent !

    Ce n'est peut-être que de la chance mais je ne dois pas être le seul quand même ;-)

    • [^] # Re: Je dois avoir de la chance

      Posté par  (site web personnel) . Évalué à 7.

      Pas de problème non plus, alors du coup je ne fais pas d'article régulier pour dire "aujourd'hui, PulseAudio a bien marché, comme d'habitude".

      Je l'utilise sur 4 PC (sous Kubuntu), souvent en sortie analogique 2.0 (HP ou casque), mais également en Bluetooth et en HDMI : pas de souci, ça juste marche, tout ce que j'ai à faire parfois c'est d'indiquer quelle sortie utiliser quand je branche un nouveau matériel.

    • [^] # Re: Je dois avoir de la chance

      Posté par  . Évalué à 5.

      Que ce soit sous EtherPad, appear.in, gotomeeting ou Skype, ça marche sans bidouille ni reboot

      Heu… Tu arrives à faire fonctionner gotomeeting sous Linux ou tu utilises une VM Windows ? Je suis intéressé par ton retour.

      • [^] # Re: Je dois avoir de la chance

        Posté par  . Évalué à 1.

        J'utilise la version free qui a le mérite d'être gratuite, de ne pas nécessiter de création et d'être mieux tolérée par les parrefeux de certain clients.
        Attention cette version n'est pas mise-en-avant sur la page d'accueil GoToMeeting. Il faut connaitre.

        Quand j'ai le choix, je préfère appear.in.

        Dans les 2 cas, c'est le partage d'écran (ou d'une simple application) qui est la fonctionnalité la plus utile. Pas besoins d'installer des trucs comme teamviewer.

        Donc oui, la version free de GotoMeting fonctionne sous Linux sans VM Windows.

        • [^] # Re: Je dois avoir de la chance

          Posté par  . Évalué à 2.

          Ah, ok. Dans mon cas, c'est pour communiquer avec mon équipe, et on est plus de trois… Sinon je viens de voir qu'il y a une appli Web gotomeeting, elle fonctionnerait sous Firefox et Chrome (sous Linux) : https://app.gotomeeting.com/home.html

          • [^] # Re: Je dois avoir de la chance

            Posté par  . Évalué à 3.

            Quand je l'ai essayé, elle me disait que linux, n'était pas supporté… (j'ai pas essayé de faire des changements de user agent)

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Je dois avoir de la chance

          Posté par  . Évalué à 2. Dernière modification le 19 octobre 2015 à 09:51.

          J'utilise la version free qui a le mérite d'être gratuite, de ne pas nécessiter de création et d'être mieux tolérée par les parrefeux de certain clients.
          Attention cette version n'est pas mise-en-avant sur la page d'accueil GoToMeeting. Il faut connaître.

          Tu peux t'en servir pour te connecter à une réunion de la version payante ?

          Quand j'ai le choix, je préfère appear.in.

          Je n'ai jamais essayé, c'est un peu comme Firefox Hello (que j'ai jamais essayé non plus) ?

          Dans les 2 cas, c'est le partage d'écran (ou d'une simple application) qui est la fonctionnalité la plus utile. Pas besoins d'installer des trucs comme teamviewer.

          Nous on utilise Skype, mais j'ai jamais réussi à avoir quelque chose de correct sous linux (c'est toujours mon contact qui partage son écran avec moi). L'image est toujours réduite et totalement illisible… (Ça paraît une évidence, mais Skype sous linux c'est une plaie)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Je dois avoir de la chance

            Posté par  . Évalué à 1.

            Tu peux t'en servir pour te connecter à une réunion de la version payante ?

            Je n'ai jamais essayé la version payante.
            Mais tu peux probablement combiner les deux en passant un simple URL à tes contacts de la réunion.

            c'est un peu comme Firefox Hello

            Le pré-requis de Firefox Hello … c'est Firefox !
            Alors que appear.in, basé sur WebRTC uniquement, n'est pas limité à Firefox.
            C'est à mon sens encore plus léger car tu n'as qu'un seul URL à communiquer, par exemple : https://appear.in/linuxfr

            j'ai jamais réussi à avoir quelque chose de correct sous linux

            Via ces solutions WebRTC de partage d'écran, ça marche très bien sous Linux. Tu peux même choisir de ne partager qu'une fenêtre ou tout ton bureau (y-compris en multi-écran).
            A la première tentative de partage, tu dois installer une extension au navigateur (avec un simple clic sans avoir à être admin).

            • [^] # Re: Je dois avoir de la chance

              Posté par  . Évalué à 4.

              Le pré-requis de Firefox Hello … c'est Firefox !

              Uniquement pour initier, si je ne m'abuse.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Je dois avoir de la chance

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                Quels navigateurs pour utiliser Firefox Hello ?

                D'après l'article, le service s'utilise avec n'importe quel navigateur compatible avec WebRTC (Firefox, Google Chrome, Opera…), mais Firefox semble néanmoins nécessaire pour gérer les contacts ou lancer une nouvelle conversation.

                Maintenant, j'imagine que ça fait uniquement référence au service « Firefox Hello », qui est un partenariat entre Mozilla et Telefónica, si je ne dis pas de bêtises. Mais au final, les autres navigateurs pourront très bien (si ce n'est pas déjà le cas) ouvrir des services similaires, pour que leurs utilisateurs puissent eux aussi initier de nouvelles conversations, qui seront elles-mêmes compatibles avec Firefox.

    • [^] # Re: Je dois avoir de la chance

      Posté par  (site web personnel) . Évalué à 8.

      J'ai suis très satisfait de PulseAudio.

      L'exception qui confirme la règle :-D :-D

      Bah non en fait ! moi non us je n'ai rien à reprocher à Pulse Audio depuis quelques années (à part le volume de VLC qui est câblé "en dur" avec le master mais c'est pas trop gênant).

      kentoc'h mervel eget bezan saotred

  • # Commentaire supprimé

    Posté par  . Évalué à -10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: 2016, l'annee du desktop Linux...

      Posté par  . Évalué à 6. Dernière modification le 20 octobre 2015 à 09:43.

      Alors oui il y a aussi des problemes de sons sous Windows, mais ca ne concerne en majorites les musiciens,

      Mes collegues sous windows ils ont constamment des problemes de son/microphone et c'est tous des ingenieurs qui connaisent l¨informatique

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -10.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: 2016, l'annee du desktop Linux...

          Posté par  . Évalué à 3. Dernière modification le 20 octobre 2015 à 13:53.

          https://www.bing.com/search?q=Windows+problem&pc=MOZI&form=MOZSBR
          https://www.bing.com/search?q=Linux+problem&pc=MOZI&form=MOZSBR

          quand je vois le nombre de hits pour Windows, je me marre…

          Hint : ce genre de stats ne veut rien dire.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -10.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: 2016, l'annee du desktop Linux...

              Posté par  . Évalué à 4.

              Hint: ce genre de stat est en realite relativement pertinent.

              Hint : pas du tout.

              D'un côte Windows a beaucoup plus de hits : mais c'est parce que Windows est mainstream depuis 30 ans. Les hits mélangent toutes les versions de Windows, avec tous les pilotes et matériels mal faits imaginables, etc… : bref, rien d'utile, même d'un point de vue statistique, quant à la qualité ou non de Windows (lequel, d'ailleurs… car il a beaucoup changé le bougre…).

              D'un autre côté Linux a beaucoup moins de hits : c'est parce qu'il est vraiment arrivé bien après Windows. Et même s'il y en aurait plus, entre les bugs propres aux distribs, propres à une config mal faite, propres à un pilote, les anciennes versions du kernel qui date du siècle dernier : c'est comme pour Windows t'as que du bruit, rien à en retirer.

              Bref, ce genre de "comparaisons" c'est de l'appeau à troll. Rien de plus.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Commentaire supprimé

                Posté par  . Évalué à -10.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: 2016, l'annee du desktop Linux...

                  Posté par  . Évalué à 3.

                  Tu ne sais vraiment pas lire.

                  J'ai dit que pour les DEUX os, ça ne veut absolument rien dire.

                  Quelque que soit l'OS d'ailleurs.

                  Quant à me rassurer, mon audio fonctionne très bien avec PulseAudio, merci pour lui.

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # HFP

    Posté par  . Évalué à 3.

    PulseAudio prend en charge les profils Bluetooth HPS (casque audio) via le backend natif et HFP (kit mains-libres) via le backend oFono, grâce à BlueZ 5. Seul l’un est actif mais ce n’est pas gênant car la plupart des appareils gèrent à la fois HPS et HFP. Cependant, chaque backend a ses limitations.

    Le natif ne gère pas le « rôle casque audio », ce qui signifie que connecter un PC à un téléphone mobile pour que le PC se comporte comme casque n’est pas pris en charge. À l’inverse, le backend oFono ne permet pas d’utiliser le téléphone mobile comme casque audio pour le PC. De plus, le contrôle du volume n’est pas aussi bien géré qu’il pourrait l’être (PulseAudio n’informe pas l’appareil connecté de son volume donc les deux gèrent leur volume indépendamment).

    Comme les deux backends ne se chevauchent pas, ils pourraient être activés en même temps. Cependant, il n’y pour l’instant pas de consensus sur le fait que ça soit la voie à suivre ou non. Pour le moment, on ne peut activer cette fonctionnalité qu’en appliquant un patch à PulseAudio.

    Jusque là, j'avais trouvé HFP for Linux, qui devait me permettre de faire passer mon ordinateur pour une oreillette Bluetooth, et donc prendre et passer mes appels depuis l'ordinateur, donc en parallèle de ce que j'y fais déjà (en gros, pouvoir continuer à écouter le son d'un jeu ou de la musique, etc. dans ses écouteurs, tout en étant au téléphone en même temps).

    J'avais mis le truc de côté en attendant de me pencher dessus pour le faire fonctionner. Donc si j'ai bien compris, cela sera bientôt intégré par défaut ? Il y a une solution efficace qui soit déjà simple à mettre en œuvre pour réaliser cela sur le desktop linux d'aujourd'hui ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.