Journal Écouter de la musique sous Plasma

-15
19
juil.
2019

n'est il pas triste qu'il ne reste que mpd/cantata pour écouter musique/radio/podcast de la meilleure faaçon qui soit (ie avec sortie redirigé vers un device airplay ou assimilé. En France, par exemple, des enceintes sur une freebox)

Clémentine semble endormi
amarok est dans le coma

  • # pas le boulot du lecteur audio

    Posté par  (Mastodon) . Évalué à 10. Dernière modification le 19 juillet 2019 à 08:19.

    Pour envoyer du son sur airplay, j'aurais tendance à dire que le boulot se fait dans pulseaudio. Je ne vois pas bien pourquoi Clementine, Amarok ou un autre lecteur devraient gérer ça.

    Et ça tombe bien, pulseaudio supporte raop2 depuis la version 11.0 (septembre 2017).

    Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

    • [^] # Re: pas le boulot du lecteur audio

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 19 juillet 2019 à 09:14.

      Exactement, c'est au serveur de son de faire le travail. D'autant plus que si on utilise plusieurs applications audio, on a pas envie de se prendre la tête à rediriger chacune d'entre elle via les options / configuration / interfaces graphique de celles ci.

      Sinon on implémente la même fonctionnalité 1000 fois dans toutes les applications qui font de l'audio et on a donc 1000 fois une implémentation avec possibles bugs à résoudre et maintenir.

      En bref à chacun sa responsabilité :

      • lecteur audio : salut, je joue ça maintenant.
      • serveur audio : bien reçu j'envoie ça sur l'enceinte bluetooth via bluez.

      git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: pas le boulot du lecteur audio

        Posté par  . Évalué à 2. Dernière modification le 20 juillet 2019 à 20:02.

        c'est au serveur de son de faire le travail.

        Pas forcément, je peux avoir envie de la bypasser.

        D'autant plus que si on utilise plusieurs applications audio, on a pas envie de se prendre la tête à rediriger chacune d'entre elle via les options / configuration / interfaces graphique de celles ci.

        Ben si on peut en avoir l'envie.

        Sinon on implémente la même fonctionnalité 1000 fois dans toutes les applications qui font de l'audio et on a donc 1000 fois une implémentation avec possibles bugs à résoudre et maintenir.

        Ah, et les bibliothèqies, c'est fait pour les chiens ?

        Tiens sinon une question que je me pose … Peut-on avoir sur une mahines deux instances de serveur pulseaudio qui redirigerait les sons vers deux hardwares différents ? Pas 1 serveur qui gère tout, mais la possibilité d'avoir 1 serveur par carte son par exemple (c'est pas anodin comme question, je pourrais avoir besoin de ça un de ces 4).

        • [^] # Re: pas le boulot du lecteur audio

          Posté par  . Évalué à 10.

          Il faut bien comprendre comment fonctionne les serveurs sons sous Linux - surtout depuis Pulse Audio et la mort de toutes les fonctionnalités Alsa un poil intéressantes au niveau capture/dispatch des flux audios. (DMIX, Virtual sound card etc.). Je dis mort parce que personne ne s'en sert, les fonctionnalités existent toujours dans le projet Alsa mais vu a) que personne ne s'en sert et b) la qualité de la doc Alsa - il faut vraiment être motivé pour utiliser ces éléments.

          Donc aujourd'hui la config par défaut des distribs et de filer les clefs totalement à Pulse Audio, lequel présente des interfaces diverses (y compris des interfaces compatibles ESD et Alsa) aux applications. Bref en mode de fonctionnement "par défaut" Pulse Audio choppe les droits exclusifs sur la carte et décide automagiquement des buffers/latences/fréquences et autres priorités pour les applicatifs.
          On peut bien sur effectuer des réglages sur ces éléments, mais Pulse Audio fonctionne en mode "best effort", et grosso-modo on va dire que sur la latence on peut se brosser, et sur la fréquence d’échantillonnage il faut pas vraiment s'attendre à grand chose.

          Cela est du au fait que Pulse Audio est destiné au grand public et fait systématiquement le choix médiocre mais safe. C'est très suffisant pour les utilisateurs dans l'immense majorité des cas.

          Déconnecter Pulse Audio, ou même simplement le faire passer en mode non exclusif est loin d'être trivial tant les applications Linux moderne s'attendent à le trouver en mode "réglage par défaut". D'ailleurs dans les distribs populaire, à chaque installation d'un package multimédia, il faut s'attendre à revoir débarquer pulse audio et toute la clique qui va avec (même si le package fonctionne parfaitement bien sans pulse audio).

          Bref à moins d'être un maniaque de la latence (ce que je suis), une personne férocement contre tout ce que fait L.Pottering (ce que je ne suis pas vraiment, mais on va dire ça vu que la version longue est vraiment trop longue) ou d'avoir des besoin de MAO professionnelle (ça m'arrive aussi, mais c'est rare) il n'y a aucune raison de vouloir passer par autre chose que pulse audio.

          Pulse Audio permet quand même de faire pas mal de choses, comme de découper un sink en tranche, de rajouter des filtres sur les sources et/ou sur les sinks, de dupliquer une source sur plusieurs sink (oui enfin, si il n'y a pas besoin de trop de synchro ou de gestion de latence fine) etc.

          Bref tu peux avec un seul serveur pulse audio piloter N cartes audio et K diffuseurs avec une séparation assez fine des sources et des destinations.

          Par contre si tu veux du mixage temps réel, du réglage de latence (pour sonoriser une salle par exemple) ou même simplement un poil de précision dans un travail de MAO - là il te faut absolument déconnecter Pulse Audio (au moins sur tes cartes de travail) et passer à Jack et/ou Ardour (l'option "et" étant de loin la meilleure) le tout sur une carte son de bonne facture.

          Jack est un serveur son qui fait tout ce que fait Pulse Audio mais avec une philosophie totalement différente. Avec Jack il faut tout connecter à la main, tout régler et vraiment bien comprendre ce qu'il se passe pour obtenir un résultat pro. Bref pas d'auto-magie.

          Donc voilà, suivant tes besoins - soit regarde un peu plus en détail ce que fait Pulse Audio, soit investis dans Jack.

          • [^] # Re: pas le boulot du lecteur audio

            Posté par  . Évalué à 2.

            Merci pour la réponse. J'avais déjà regardé Jack, et personellement je préfère largement cette approche. Mais comme tu le dis c'est pas forcément toujours simple (les applis ne fonctionnent pas toujours bien avec).

            Petite question, plutôt que de se battre avec Pulseaudio ou Jack, pourquoi ne pas définir une interface commune que toutes les applis utiliseraient ? Ainsi, que ce soit PulseAudio ou Jack, ou autre, l'appli enverrait vers un truc, et lez truc se chargerait de faire comme il veut. Ah et qu'on me dise pas 't'as qu'a utiliser les libs pulseaudio' : je préfèrerais un truc 'neutre'.

            • [^] # Re: pas le boulot du lecteur audio

              Posté par  . Évalué à 6.

              Petite question, plutôt que de se battre avec Pulseaudio ou Jack, pourquoi ne pas définir une interface commune que toutes les applis utiliseraient ?

              Ben en fait avec les cartes son "entrée de gamme" ce n'est pas vraiment possible. Grosso-modo il existe plusieurs interfaces "standards" - en l’occurrence Alsa, Jack et Pulse Audio.

              Alsa est le plus proche du matériel, mais il a les défauts qui vont avec - tu définis ton échantillonnage (32k, 44.1k, 48k, 96k etc.) ta précision (16 ou 24 bits) la priorité de ton flux etc. Mais derrière quand tu veux rajouter un second flux c'est la panique. Si ta carte est de bonne qualité elle peut supporter de faire du mixing hard avec des flux divers - sinon il faut remonter le mixage au niveau supérieur avec DMix, et là ça passe ou ça casse.

              Pulse Audio va tout faire pour donner des priorités équivalentes à tous les flux et tout mixer quoi qu'il arrive, quitte à baisser la qualité et augmenter la latence (genre tu as 4 flux différents, tout le monde se retrouve en 48k 16bits, parce que c'est ce qui est le mieux supporté par ta carte - et tant pis si ça génère de la distorsion ou de la perte de précision)

              Jack te laisse les clefs et cherche à faire ce que tu lui demandes, si tu en demandes trop, la latence explose, la charge CPU explose, le son est haché et les logs se remplissent.

              Personnellement j'utilise j'ai une carte qui supporte le mix hardware et une station extérieure mais je passe tout par Jack. Pulse Audio se connecte à Jack et n'a aucun droit exclusif sur le hard (il a sink jack dédié par contre). Mais mon setup correspond à mes besoins. Honnêtement avec une très bonne carte audio (genre la essence STX II d'ASUS) pulse audio peut suffire un moment.

        • [^] # Re: pas le boulot du lecteur audio

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

          Ah, et les bibliothèques, c'est fait pour les chiens ?

          Oh le naïf. Penses-tu vraiment que c'est aussi simple que ça ? Rien que la bibliothèque alsa nécessite plusieurs appels de fonctions pour juste récupérer le volume courant. Alors imagine quand il s'agit de transmettre du son. En plus il existe plusieurs bibliothèques, mais à vrai dire le son sous Linux a toujours et malheureusement été un bordel monstre.

          Tiens sinon une question que je me pose … Peut-on avoir sur une mahines deux instances de serveur pulseaudio qui redirigerait les sons vers deux hardwares différents ? Pas 1 serveur qui gère tout, mais la possibilité d'avoir 1 serveur par carte son par exemple (c'est pas anodin comme question, je pourrais avoir besoin de ça un de ces 4).

          Je ne sais pas pour pulseaudio, en tout cas NAS était prévu pour ça mais il est largement tombé en désuétude. Je l'ai un peu essayé par le passé mais c'était loin d'être parfait.

          git is great because linus did it, mercurial is better because he didn't

          • [^] # Re: pas le boulot du lecteur audio

            Posté par  . Évalué à 3.

            Oh le naïf. Penses-tu vraiment que c'est aussi simple que ça ?

            ŒBen c le principe d'une bibliotrhèque: développer du code réutilisable par d'autres pour que les autres n'aient pas à le faire.

            Rien que la bibliothèque alsa nécessite plusieurs appels de fonctions pour juste récupérer le volume courant.

            Tiens tu m'apprends un truc. Quand on programme, on doit faire appel a plusieurs appels de fonctions pour effectuer une action. Je pensais qu'une seule fonction par tache était nécessaire.

    • [^] # Re: pas le boulot du lecteur audio

      Posté par  . Évalué à 1.

      Quelq'un connait il une alternative a https://github.com/masmu/pulseaudio-dlna pour envoyer vers un chromecast audio?

      • [^] # Re: pas le boulot du lecteur audio

        Posté par  . Évalué à 2.

        Normalement vlc en est capable… normalement, sous Linus j'ai du réussir a le faire fonctionner une demi fois mais je n'ai pas vraiment insisté. La dernière fois il ne voyait pas le chromecast.

    • [^] # Re: pas le boulot du lecteur audio

      Posté par  . Évalué à 1.

      https://github.com/clementine-player/clementine/issues/4023

      ce n'était pas corrigé il y a un an

  • # cantata

    Posté par  . Évalué à 8. Dernière modification le 19 juillet 2019 à 15:40.

    super GUI pour mpd: https://github.com/CDrummond/cantata

    apres ce que tu demandes n'est pas du domaine d'un player mais de kmix/pulseaudio dans le cadre de plasma (et ca marche tres bien!)

  • # Clementine endormi

    Posté par  . Évalué à 3.

    Clémentine semble endormi

    Comment ça ? Ils n'ont pas sorti de version stable depuis 2016 (ce qui est regrettable), mais le projet est actif, les distributions GNU/Linux actuelles fournissent une version récente et il y a des commits réguliers dans le dépôt git de Clementine.

    Très bon lecteur audio, peut-être un peu gourmand.

Suivre le flux des commentaires

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