Mopidy: Envisagez d'ajouter un évier fifo gstreamer

Créé le 8 juil. 2014 · 73Commentaires · Source: mopidy/mopidy

Cela revient sans cesse car les gens semblent vraiment aimer le visualiseur de ncmpcpp

L'astuce pour fabriquer un évier FIFO fiable est double. Vous devez utiliser des écritures non bloquantes, ce qui signifie que l'ouverture du socket d'écriture échouera à moins qu'il n'y ait un lecteur, vous avez donc également besoin d'un lecteur. Deuxièmement, si le tampon se remplit parce que le lecteur externe prend du retard ou qu'il n'y en a pas, votre lecteur interne doit vider le tampon.

Le code suivant capture l'essentiel de cela, mais nécessite encore un peu de travail en ce qui concerne la gestion des erreurs.

import errno
import os
import stat

LINUX_FIFO_BUFFER_SIZE = 65536


class FifoStreamer(object):                                                     
    def __init__(self, location):                                               
        self.location = location                                                
        self.reader = None                                                      
        self.writer = None                                                      

    def create(self):                                                           
        try:                                                                    
            mode = os.stat(self.location).st_mode                               
            if not stat.S_ISFIFO(mode):                                         
                raise Exception('File exists but is not a FIFO')                
        except OSError as e:                                                    
            if e.errno == errno.ENOENT:                                         
                os.mkfifo(self.location)                                        
            else:                                                               
                raise                                                           

        # TODO: wrap in could not open reader / writer?
        self.reader = os.open(self.location, os.O_NONBLOCK | os.O_RDONLY)       
        self.writer = os.open(self.location, os.O_NONBLOCK | os.O_WRONLY)       

    def close(self):                                                            
        # TODO: make closing robust
        os.close(self.writer)                                                   
        os.close(self.reader)                                                   

    def write(self, data):                                                      
        while data:                                                             
            try:                                                                
                written = os.write(self.writer, data)                           
                data = data[written:]                                           
            except OSError as e:                                                
                if e.errno == errno.EINTR:                                      
                    continue                                                    
                elif e.errno in (errno.EAGAIN, errno.EWOULDBLOCK):              
                    self.flush()                                                
                else:                                                           
                    raise                                                       

    def flush(self):                                                            
        while True:                                                             
            try:                                                                    
                if not os.read(self.reader, LINUX_FIFO_BUFFER_SIZE):                             
                    break                                                       
            except OSError as e:                                                
                if e.errno in (errno.EAGAIN, errno.EWOULDBLOCK):                
                    break                                                       
                elif e.errno == errno.EINTR:                                    
                    continue                                                    
                else:                                                           
                    raise

Le code ci-dessus doit maintenant être intégré à GStreamer pour faire son travail. En supposant que 0,10, cela soit en fait tout à fait faisable, la raison pour laquelle j'hésite est que nous prévoyons de passer à 1.x et que la liaison gir n'est pas adaptée à la création d'éléments en python. Dans le cas de ce code dans 1.x, le problème se résume à l'impossibilité de créer les modèles de blocs que BaseSink s'attend à trouver. Créer ceci en tant qu'élément simple peut être faisable, mais vous auriez besoin de ré-implémenter une grande partie de la gestion que BaseSink vous assure de bien faire.

import gobject                                                                  

import pygst                                                                    
pygst.require('0.10')                                                           
import gst                                                             


class FifoSink(gst.BaseSink):                                                   
    __gstdetails__ = (                                                          
        'FifoSink',                                                             
        'Sink',                                                                 
        'Sink designed to handle FIFO output.',                        
        'Mopidy')                                                               

    __gsttemplates__ = (gst.PadTemplate('sink', gst.PAD_SINK, gst.PAD_ALWAYS,   
                                        gst.caps_new_any()),)                   

    # TODO: don't allow changing location in flight, i.e. create getter/setter
    location = gobject.property(type=str)                                       

    def __init__(self):                                                         
        gst.BaseSink.__init__(self)                                             
        self.streamer = None                                                    

    def do_start(self):                                                                                               
        self.streamer = FifoStreamer(self.location)                             
        self.streamer.create()                                                  
        return True                                                             

    def do_stop(self):                                                          
        self.streamer.close()                                                   
        return True                                                             

    def do_render(self, buf):                                                   
        try:                                                                    
            self.streamer.write(bytes(buf))                                     
            return gst.FLOW_OK                                                  
        except OSError as e:                                                    
            self.error("Failed: %s", e)                                         
            return gst.FLOW_ERROR                                               


gobject.type_register(FifoSink)                                                 
gst.element_register(                                                           
    FifoSink, 'fifosink', gst.RANK_MARGINAL)                                    

if __name__ == '__main__':                                                      
    import gobject                                                              
    gobject.threads_init()                                                      

    output = """                                                                
capsfilter caps="audio/x-raw-int,width=16,rate=44100,channels=1" ! 
tee name=t 
t. ! queue ! alsasink                                                           
t. ! queue ! fifosink location=/tmp/test2.fifo                                  
"""                                                                             

    sink = gst.parse_bin_from_description(                                      
        output, ghost_unconnected_pads=True)                                    

    playbin = gst.element_factory_make('playbin2')                              
    playbin.set_property('audio_sink', sink)

Notez qu'un problème que j'ai rencontré lors du test était en fait d'oublier de faire correspondre le format audio attendu par ncmpcpp, alors assurez-vous que mono/stéréo correspond bien.

C-enhancement A-audio

Source

adamcik

👍8

Commentaire le plus utile

Pour info, j'ai ajouté le support de udpsink de gstreamer à ncmpcpp afin qu'il puisse maintenant être utilisé directement sans hacks fifo.

Voir https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 pour plus de détails.

Ci-dessous un teaser. Il s'agit de mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

https://user-images.githubusercontent.com/387658/102549720-e41bf980-40bc-11eb-8127-70889011e52f.mp4

arybczak le 17 déc. 2020

❤10 🎉6 👍6 👀2

Tous les 73 commentaires

Où est-ce passé? cela sera-t-il ajouté au package principal ?

CestDiego le 6 oct. 2014

Cela ne fonctionne pas car nous aurions besoin de le convertir en GStreamer 1.0, et toutes mes expériences avec cela jusqu'à présent ont révélé des problèmes lors de la création d'éléments personnalisés en python. Il y a peut-être d'autres moyens de tout résoudre, mais pas quelque chose sur lequel j'ai le temps de travailler.

adamcik le 11 oct. 2014

J'aimerais voir le support FIFO ajouté :)

johnhamelink le 6 nov. 2014

Je viens de trouver cette recherche d'un moyen de faire fonctionner le visualiseur de musique de ncmpcpp avec mpidy. Je suis en faveur.

proxa le 6 nov. 2014

Oui, c'est la même raison pour laquelle j'ai trouvé ça. Ce serait vraiment super de
être capable de visualiser la musique en streaming,

06-11-2014 2:19 GMT-05:00 Blake [email protected] :

Je viens de trouver cette recherche d'un moyen d'obtenir le visualiseur de musique de ncmpcpp pour
travailler avec mopidy. Je suis en faveur.
-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment-61936376 .

CestDiego le 6 nov. 2014

Il existe des plugins de visualisation gstreamer, ne pouvez-vous pas simplement les utiliser ?
Le 6 novembre 2014 08:35, "Diego Berrocal" [email protected] a écrit :

Oui, c'est la même raison pour laquelle j'ai trouvé ça. Ce serait vraiment super de
être capable de visualiser la musique en streaming,

06-11-2014 2:19 GMT-05:00 Blake [email protected] :

Je viens de trouver cette recherche d'un moyen d'obtenir le visualiseur de musique de ncmpcpp
à
travailler avec mopidy. Je suis en faveur.
-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment-61936376 .

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment-62007426 .

kingosticks le 6 nov. 2014

Notez que ceux-ci sont en voie de disparition dans la prochaine version.

adamcik le 6 nov. 2014

Y a-t-il quelqu'un qui travaille là-dessus ? Ce serait vraiment bien de pouvoir utiliser le visualiseur ncmpcpp avec mpidy.

andreasboden le 13 févr. 2015

Pas à ma connaissance, et nous ne voulons probablement pas le faire en tant qu'élément GStreamer car cela bloquerait notre migration vers GStreamer 1.x.

adamcik le 14 févr. 2015

Ceci est également bloqué par l'OMI lors de l'ajout d'un support approprié pour les sorties.

adamcik le 25 févr. 2015

J'ajoute juste que j'ai également rencontré ce problème en essayant d'ajouter la prise en charge du visualiseur à Mopidy/ncmpcpp. J'adorerais avoir cela à l'avenir même si cela n'est pas en cours d'élaboration actuellement. J'aimerais également exprimer mon plus grand respect pour ceux qui donnent de leur temps à des projets open source. :le sourire:

codeurge le 15 avr. 2015

Idéalement, cela fonctionnerait à distance. La puissance de Mopidy réside vraiment dans le fait d'être une solution qui peut être dans votre cloud privé.

wernight le 27 avr. 2015

En général, les FIFO ne sont pas une méthode très portable de communications interprocessus et doivent être évitées selon l'OMI. Ils ont également des effets secondaires désagréables, déjà mentionnés dans ce fil. Je pense que vous feriez mieux de vider vos paquets en utilisant un récepteur UDP personnellement... c'est une solution plus générique et peut facilement être adaptée à quelque chose qui écrit sur un FIFO (si nécessaire) en dehors de Mopidy... c'est un seul ligne de script shell pour lire les données d'un port UDP (en utilisant netcat) et les écrire dans une FIFO.

liamw9534 le 27 avr. 2015

Ça sonne bien. Peut-être que les clients ncmpcpp permettraient également de l'utiliser comme entrée.

Une autre idée est d'utiliser PulseAudio directement car cela ne nécessiterait aucune implémentation supplémentaire du côté de Mopidy. Le conteneur Docker que j'ai créé utilise TCP pour accéder à PulseAudio sur le réseau. ncmpcpp pourrait en fait l'utiliser directement.

wernight le 27 avr. 2015

D'après ce que j'ai lu, le visualiseur exécute simplement une FFT sur des blocs d'échantillons lus à partir d'un fichier FIFO. Ce que je veux dire, c'est que vous pouvez créer une FIFO en dehors de Mopidy en utilisant mkfifo , puis lire les données UDP de Mopidy en utilisant netcat et rediriger la sortie de netcat vers le fichier FIFO. Ainsi, rien n'a besoin de changer en ce qui concerne ncmpcpp , il ne fait que lire le fichier FIFO.

Pour atteindre ce que vous visez sur Mopidy, aucun effort de mise en œuvre n'est nécessaire, car vous pouvez modifier la propriété de sortie audio pour qu'elle soit transmise à un élément udpsink GStreamer. Il est plus probable que vous voudriez l'organiser dans le cadre d'un « té » qui sort à la fois de votre évier ALSA/Pulse et de l'udpsink.

liamw9534 le 28 avr. 2015

Ce qui suit devrait fonctionner .... non testé, donc peut-être besoin d'un peu de tweeking.

En configuration audio Mopidy :

output = tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555

Sur votre hôte Linux, lancez netcat pour écouter sur localhost les données UDP sur le port 5555 et sortez les exemples vers la FIFO :

mkfifo /tmp/mopidy.fifo
nc -u -l 127.0.0.1 5555 > /tmp/mopidy.fifo &

Dans votre mpd.conf :

audio_output {
    type                    "fifo"
    name                    "my_fifo"
    path                    "/tmp/mopidy.fifo"
    format                  "44100:16:2"
}

liamw9534 le 28 avr. 2015

Remarque : Si vous utilisez une sortie PulseAudio, il peut être possible de faire quelque chose de similaire avec son module de connexion de direction TCP. Cependant, vous devrez peut-être procéder à l'ingénierie inverse de tout protocole qu'il exécute au-dessus de la connexion TCP, par exemple, il pourrait ne pas être possible de le traiter comme un récepteur brut.

liamw9534 le 28 avr. 2015

Merci @liamw9534 pour le partage. Il m'aurait fallu un certain temps pour comprendre suffisamment la configuration pour faire cela ou même savoir que je pouvais. Je vais essayer de l'ajouter au conteneur Docker pour voir si cela fonctionne.

wernight le 28 avr. 2015

Cela peut cependant poser des problèmes si vous n'avez rien qui vide le fifo. Comme netcat remplira le tampon du noyau puis échouera. Et selon la façon dont le FIFO est ouvert, vous pouvez également rencontrer des problèmes car les FIFO peuvent nécessiter la présence d'un lecteur pour être inscriptible :/

adamcik le 28 avr. 2015

Mais vous pouvez adapter mon code FifoStreamer pour accepter les données UDP et gérer cela pour vous car j'espère avoir déjà géré la plupart des cas d'erreur que vous pouvez rencontrer là-bas.

adamcik le 28 avr. 2015

@adamcik Si vous avez un script fonctionnel, je serais heureux de l'inclure dans docker-ncmpcpp pour que les gens puissent l'utiliser. Je changerais également docker-mopidy pour diffuser sur UDP par défaut en utilisant l'astuce de sortie ci-dessus.

wernight le 29 avr. 2015

J'ai fait quelques expériences de base sur la ligne de commande et tout fonctionne bien à condition que vous utilisiez un délai de connexion, par exemple nc -kluw 1 127.0.0.1 5555 > /tmp/mopidy.fifo . Cela oblige netcat à toujours écouter une nouvelle connexion de port source après la chute de la dernière connexion (délai d'expiration de 1 s).

La commande ci-dessus fonctionne indépendamment du fait que quelque chose soit lu ou non à partir du fichier FIFO et fonctionne également si le processus de lecture à partir du fichier FIFO s'arrête et ferme le fichier.

liamw9534 le 29 avr. 2015

@wernight voir la description de ce bug, c'est tout le code que j'ai.

adamcik le 29 avr. 2015

Et juste pour les ceintures et les bretelles, je collerais la commande dans une boucle while, par exemple, while :; do nc -kluw 1 127.0.0.1 5555> /tmp/mopidy.fifo; sleep 1; done - si elle se termine, elle se relancera après 1 seconde de délai.

liamw9534 le 29 avr. 2015

@liamw9534 Vous avez un mpd.conf là-bas. Je suis confus par cela. Vous utilisez un serveur MPD autonome en plus de mpidy-mpd ?

lrvick le 2 mai 2015

@lrvick oui mon erreur, je pensais bien sûr à la configuration qui doit être ajoutée à ~/.ncmpcpp/config

liamw9534 le 2 mai 2015

.config/mopidy/mopidy.conf

...

[audio]
output = tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555

$ mkfifo /tmp/mopidy.fifo
$ while :; do nc -kluw 1 127.0.0.1 -p 5555> /tmp/mopidy.fifo; sleep 1; done

(ajouté -p ici).

~/.ncmpcpp/config

audio_output {
    type                    "fifo"
    name                    "my_fifo"
    path                    "/tmp/mopidy.fifo"
    format                  "44100:16:2"
}

(fait aussi dans wernight/docker-mopidy et wernight/docker-ncmpcpp )

Cependant, il semble qu'il ne puisse pas se connecter au 5555 même si le journal de Mopidy montre qu'il a compris la configuration output . netstat montre pas non plus d'UDP ouvert sur 5555. Je ne comprends pas tout à fait la ligne output : tee est une commande bash, le reste ressemble à des trucs de Mopidy.

J'ai cependant trouvé udp6 [::]:51307 en jouant de la musique.

wernight le 8 mai 2015

Le output est interprété comme un élément GstBin qui est passé à playbin2 dans le cadre de Mopidy - sous le capot, ce n'est qu'un pipeline Gstreamer, rien de spécial vraiment. Le tee est donc en fait un élément Gstreamer. Cela n'a rien à voir avec la commande shell tee .

Vous pouvez donc approximer ce qui se passe dans Mopidy sur la ligne de commande en faisant quelque chose comme :

gst-launch audiotestsrc ! tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555 &

Cela commencera à jouer une tonalité sinusoïdale. Exécutez ensuite la commande suivante :

nc -kluw 1 127.0.0.1 5555

Je peux alors commencer à voir beaucoup de caractères étranges sur mon écran... il s'agit du flux audio de test sortant sur stdout à partir de nc . Cela prouve effectivement que l'approche sous-jacente fonctionne. Pouvez-vous confirmer que vous pouvez reproduire le même comportement ?

Vous pouvez ensuite essayer d'ajouter le FIFO dans un deuxième temps et confirmer que vous pouvez cat le FIFO à la sortie standard et voir les mêmes caractères étranges.

liamw9534 le 8 mai 2015

Je vérifierais également le format de configuration requis par ncmpcpp . J'ai jeté un bref coup d'œil à https://wiki.archlinux.org/index.php/Ncmpcpp#Enabling_visualization et je peux voir que le format de configuration nécessaire est peut-être différent, par exemple,

visualizer_fifo_path = "/tmp/mpd.fifo"
visualizer_output_name = "my_fifo"
visualizer_sync_interval = "30" 
visualizer_in_stereo = "yes"
visualizer_type = "spectrum" (spectrum/wave)

Je n'utilise pas ncmpcpp , donc le problème pourrait être ici aussi...

liamw9534 le 8 mai 2015

$ apt-get install gstreamer-tools
$ gst-launch audiotestsrc ! tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555 &
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
$ nc -kluw 1 127.0.0.1 -p 5555
no connection : Connection timed out

(avec nc ... -p sinon j'obtiens une erreur)

J'entends le ton jouer cependant.

wernight le 11 mai 2015

Quelle distro utilisez-vous? De plus, lorsque vous tapez nc -h quelle est la sortie ?

$ nc -h
OpenBSD netcat (Debian patchlevel 1.89-4ubuntu1)
This is nc from the netcat-openbsd package. An alternative nc is available
in the netcat-traditional package.
usage: nc [-46DdhklnrStUuvzC] [-i interval] [-P proxy_username] [-p source_port]
      [-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_protocol]
      [-x proxy_address[:port]] [hostname] [port[s]]
    Command Summary:
        -4      Use IPv4
        -6      Use IPv6
        -D      Enable the debug socket option
        -d      Detach from stdin
        -h      This help text
        -i secs     Delay interval for lines sent, ports scanned
        -k      Keep inbound sockets open for multiple connects
        -l      Listen mode, for inbound connects
        -n      Suppress name/port resolutions
        -P proxyuser    Username for proxy authentication
        -p port     Specify local port for remote connects
        -q secs     quit after EOF on stdin and delay of secs
        -r      Randomize remote ports
        -S      Enable the TCP MD5 signature option
        -s addr     Local source address
        -T ToS      Set IP Type of Service
        -C      Send CRLF as line-ending
        -t      Answer TELNET negotiation
        -U      Use UNIX domain socket
        -u      UDP mode
        -Z      DCCP mode
        -v      Verbose
        -w secs     Timeout for connects and final net reads
        -X proto    Proxy protocol: "4", "5" (SOCKS) or "connect"
        -x addr[:port]  Specify proxy address and port
        -z      Zero-I/O mode [used for scanning]
    Port numbers can be individual or ranges: lo-hi [inclusive]

L'option -p n'est pas nécessaire avec le nc j'utilise sur Ubuntu. La page de manuel implique également que cela devrait être une erreur de spécifier -p en conjonction avec -l :

     -l      Used to specify that nc should listen for an incoming connection
             rather than initiate a connection to a remote host.  It is an error
             to use this option in conjunction with the -p, -s, or -z options.
             Additionally, any timeouts specified with the -w option are ignored.

liamw9534 le 11 mai 2015

Utilisation de Debian Wheezy.

Voici les étapes complètes pour Ubuntu en commençant par installer Docker :

Installer Docker :

$ wget -qO- https://get.docker.com/ | sh $ sudo gpasswd -a ${USER} docker

Activer PulseAudio à distance
Exécuter sur Debian :

$ docker run --rm -it \ -e PULSE_SERVER=tcp:$(hostname -i):4713 \ -e PULSE_COOKIE_DATA=$(pax11publish -d | grep --color=never -Po '(?<=^Cookie: ).*') \ debian:wheezy $ apt-get update && apt-get install -y netcat $ nc -h [v1.10-40] connect to somewhere: nc [-options] hostname port[s] [ports] ... listen for inbound: nc -l -p port [-options] [hostname] [port] options: -c shell commands as `-e'; use /bin/sh to exec [dangerous!!] -e filename program to exec after connect [dangerous!!] -b allow broadcasts -g gateway source-routing hop point[s], up to 8 -G num source-routing pointer: 4, 8, 12, ... -h this cruft -i secs delay interval for lines sent, ports scanned -k set keepalive option on socket -l listen mode, for inbound connects -n numeric-only IP addresses, no DNS -o file hex dump of traffic -p port local port number -r randomize local and remote ports -q secs quit after EOF on stdin and delay of secs -s addr local source address -T tos set Type Of Service -t answer TELNET negotiation -u UDP mode -v verbose [use twice to be more verbose] -w secs timeout for connects and final net reads -z zero-I/O mode [used for scanning] port numbers can be individual or ranges: lo-hi [inclusive]; hyphens in port names must be backslash escaped (e.g. 'ftp\-data'). $ nc -kluw 1 127.0.0.1 5555 UDP listen needs -p arg $ apt-get install -y net-tools gstreamer-tools gstreamer0.10-plugins-good $ echo -ne $(echo $PULSE_COOKIE_DATA | sed -e 's/../\\x&/g') >$HOME/pulse.cookie $ export PULSE_COOKIE=$HOME/pulse.cookie $ gst-launch audiotestsrc ! tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555 & $ nc -kluw 1 127.0.0.1 -p 5555 no connection : Connection timed out

wernight le 11 mai 2015

Essayé avec le package netcat-openbsd qui donne :

$ nc -h
OpenBSD netcat (Debian patchlevel 1.105-7)
...

Maintenant, nc n'affiche plus rien pendant que la tonalité est jouée (ce qui semble un peu mieux) :

$ nc -kluw 1 127.0.0.1 5555
(nothing here)

wernight le 11 mai 2015

Ok, ouvrez deux terminaux et dans le premier terminal, lancez :

nc -kluw 1 127.0.0.1 5555

Ensuite, dans le deuxième terminal, exécutez :

nc -u 127.0.0.1 5555

Entrez quelques caractères sur stdin dans le deuxième terminal et appuyez sur ENTER. Voyez-vous les mêmes caractères apparaître dans le premier terminal sur stdout ?

liamw9534 le 11 mai 2015

Oui ça marche. J'ai même réussi à le faire fonctionner sur Dockers :

$ docker run --rm --name nc1 -it my-debian-with-nc nc -kluw 1 0.0.0.0 5555
Hello

$ docker run --rm --link nc1:nc1 -it my-debian-with-nc nc -u nc1 5555
Hello

Cela n'explique donc pas pourquoi nc n'a rien montré avec gst-launch . Cependant, j'ai découvert que je devais définir host=SOMETHING pour qu'il fonctionne sur tous les conteneurs. Ce sera problématique. On dirait qu'il ne peut pas diffuser. Mais c'est quelque chose que je pourrai résoudre une fois que cela fonctionnera au moins sur un seul conteneur.

wernight le 11 mai 2015

Ah ! Si je mets host=0.0.0.0 ça marche !

wernight le 11 mai 2015

👍2

Avez-vous besoin d'envoyer les données sur un réseau ? J'avais supposé que vous n'aviez besoin que des paquets sur la machine locale. L'utilisation de udpsink host=0.0.0.0 port=5555 diffusera des paquets partout sur votre réseau. Ce n'est probablement pas ce que vous voulez...

Vous devriez pouvoir dire host=127.0.0.1 place pour restreindre les paquets au bouclage local.

Je soupçonne que le vrai problème est donc dû à la configuration de routage par défaut. Par défaut, sur votre système, les paquets sortants sont acheminés vers une interface différente. Peut-être des versions différentes de l'élément gstreamer ou des différences dans la configuration du routage IP.

liamw9534 le 11 mai 2015

À partir du conteneur, je devais utiliser 0.0.0.0 ou éventuellement l'adresse IP de la machine. Le paramètre par défaut ne fonctionnait pas même sur une seule machine/conteneur.

Mais oui, je dois utiliser le réseau maintenant car il est recommandé de conserver ncmpcpp et mopidy dans des conteneurs Docker séparés, ce qui signifie qu'ils se trouvent sur des réseaux différents. C'est vraiment bon pour la sécurité et l'isolement et ainsi de suite, mais cela crée un peu de problèmes :

Le client ncmpcpp se connecte au serveur MPD pour demander la diffusion de musique, et seulement après ce point, l'adresse IP de ncmpcpp est connue et le paquet UDP doit être diffusé sur son IP ; mais actuellement l'IP est codée en dur dans la configuration Mopidy.

Je n'ai pas de solution pour le moment. Je réfléchis à des solutions :

Créer le FIFO dans Mopidy et le partager avec ncmpcpp, mais je crains que rien n'efface le FIFO et c'est un gros problème. De plus, le partage de fichiers n'est pas aussi propre que les sockets réseau.
Démon local surveillant les connexions et acheminant le trafic UDP vers l'adresse IP du client trouvé ; pirater.
Tunnel UDP SSH , mais c'est complexe, ajoute un cryptage inutile, ajoute un autre démon... mauvais !
En regardant le code pour voir si l'hôte udpsink peut être
Dites à Docker de partager l'hôte via --net=container:NAME_or_ID ce qui ajoute un autre paramètre à saisir par les utilisateurs, mais cela simplifierait beaucoup !

Il existe des solutions à cette dépendance circulaire. Ressemble toujours à un horrible hack, mais il devrait être assez facile à utiliser pour les utilisateurs à la fin. Merci à liamw9534 pour son aide en particulier avec les commandes nc lesquelles j'étais étranger.

wernight le 12 mai 2015

Le FIFO fonctionne sauf que There is no output named "my_fifo"! . Il semble que le nom doit correspondre à celui de mdp.conf :

 audio_output {
        type            "fifo"
        name            "my_fifo"
        path            "/tmp/mpd.fifo"
        format           "44100:16:2"
}

Je peux essayer de partager le fichier FIFO si je sais comment ajouter cette sortie audio à Mopidy. les nausées (un simple visualiseur uniquement) semblent avoir les mêmes exigences.

J'ai trouvé cette documentation de visualizer_output_name :

Le paramètre ci-dessous est nécessaire pour que ncmpcpp détermine quelle sortie fournit des données pour le visualiseur et permet ainsi la synchronisation entre la visualisation et le son car il y a actuellement quelques problèmes avec cela.
sortie fifo, dont le paramètre de format doit être réglé sur 44100:16:1 pour une visualisation mono ou 44100:16:2 pour une visualisation stéréo

wernight le 12 mai 2015

Je ne sais pas ce que vous entendez par "sur différents réseaux". Si vous souhaitez isoler le trafic audio vers la machine locale, vous devez utiliser 127.0.0.1 pour udpsink . Si vous choisissez 0.0.0.0 il dirigera les paquets en utilisant la route par défaut, ce qui signifie probablement l'envoi de paquets UDP sur le réseau... en général, je dirais que c'est une mauvaise idée car le trafic réseau consommera un beaucoup de bande passante, c'est-à-dire 2 x 16 x 44100 = 1,41 Mbps.

En théorie, il devrait être possible de configurer nc avec 0.0.0.0 quelle udpsink . Cela écoutera sur toutes les interfaces réseau. C'est bien tant que vous n'utilisez pas le même numéro de port IP pour d'autres services sur différentes interfaces réseau.

liamw9534 le 12 mai 2015

J'ai utilisé ma dernière suggestion et mis les deux sur le même réseau. Ces réseaux sont de toute façon locaux, c'est juste une séparation logique. Cela fonctionne pour construire le FIFO, juste ncmpcpp n'en veut pas (voir ma réponse précédente, 2 ci-dessus).

wernight le 12 mai 2015

Une idée sur le nom de cette chaîne ? Ou s'il existe un autre moyen de créer un FIFO comme mpd.conf ? Ne semble pas fonctionner du tout sans.

wernight le 13 mai 2015

Je pensais que mpd.conf n'était utilisé que pour la configuration du démon MPD. Dans ce cas, cela devrait être redondant car mpidy est le démon MPD et votre docker crée le fichier FIFO. Dans ce cas, la seule chose qui devrait être nécessaire est de s'assurer que le .ncmpcpp/config correspond au client, n'est-ce pas ?

liamw9534 le 13 mai 2015

Type de. Qu'est-ce que ça fait exactement, je ne sais pas. Mais comme vous pouvez le voir, le visualizer_output_name = "my_fifo" doit correspondre à audio_output { name "my_fifo" } . Actuellement, ncmpcpp affiche There is no output named "my_fifo" . La description de visualizer_output_name est juste 5 messages ci-dessus. Il semble qu'il se connecte directement d'une manière ou d'une autre à la sortie à synchroniser.

wernight le 13 mai 2015

Je n'utilise rien de tout cela, mais il me semble que le visualizer_output_name devrait correspondre à l'une de vos sorties MPD (protocole, pas programme) (c'est-à-dire quelque chose dans mpc outputs ). Mopidy ne permet actuellement pas de sorties configurables et n'a qu'une seule sortie MPD : "Mute".

Vous voudriez probablement désactiver visualizer_output_name , si possible.

kingosticks le 13 mai 2015

J'ai essayé de ne pas le régler. Toujours pas de visualiseur visible. Je m'interroge sur le format de sortie de udpsink : Devrait être 44100:16:2 pour que les visualiseurs fonctionnent ( ncmpcpp ou nausea ).

J'ai essayé Mute juste au cas où, j'ai eu une expérience très amusante : il a juste coupé le son, sans afficher d'erreur mais aussi sans afficher de visualiseurs. Ou plus exactement, il a désactivé la sortie Mute .

wernight le 13 mai 2015

Je me demande où la fonction FFT est exécutée pour le visualiseur.
S'effectue-t-il en sortie de la FIFO ou en entrée de la FIFO ? Vous
aurait besoin de vérifier le code client MPD pour voir comment il gère les données FIFO.

liamw9534 le 13 mai 2015

Existe-t-il un moyen de prendre en charge l'un ou l'autre, juste pour tester, même si cela créerait normalement un fichier monstrueusement énorme.

wernight le 13 mai 2015

Vous n'avez pas besoin de soutenir non plus. Vous devez savoir où se trouve la FFT
censé être fait, puis choisissez la bonne approche. Si la FFT est
fait dans le visualiseur, ce serait juste un gaspillage d'efforts pour
l'implémenter à nouveau.

Le 13 mai 2015 à 15h09, Werner Beroux [email protected] a écrit :

Existe-t-il un moyen de prendre en charge l'un ou l'autre, juste pour tester, même si cela
créent normalement un fichier monstrueusement énorme.
-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment-101676033 .

liamw9534 le 13 mai 2015

La FFT est effectuée par le visualiseur et nécessite le format audio spécifique du FIFO pour fonctionner. Référence : http://git.2f30.org/nausea/about/

wernight le 13 mai 2015

Bien - alors il n'y a aucune raison que cela ne fonctionne pas ! Avez-vous fait un
comparaison côte à côte d'un système exécutant un démon MPD standard avec un
client ncmpcpp local ? Que se passe-t-il si vous renommez le nom de fichier FIFO dans les deux
les fichiers de configuration ? Est-ce que ça marche toujours ? J'essaye juste de voir si un
le chemin codé en dur existe quelque part...

Le 13 mai 2015 à 15h57, Werner Beroux [email protected] a écrit :

La FFT est effectuée par le visualiseur et nécessite le format audio spécifique
dans le FIFO pour travailler pour ça. Référence : http://git.2f30.org/nausea/about/
-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment-101702624 .

liamw9534 le 13 mai 2015

Mon commentaire était basé sur la source ncmpcpp .

La sortie Muet de Mopidy est désactivée par défaut, c'est-à-dire que le son n'est pas coupé. Le visualiseur ncmpcpp prendra la sortie que vous lui avez donnée, la désactivera (aucun effet) puis l'activera, coupant ainsi le son. On peut dire qu'ils devraient simplement l'activer deux fois.

L'audio étant dans le mauvais format est une bonne possibilité. Vous n'avez rien dans votre pipeline gstreamer pour vous assurer qu'il est correct contrairement à @adamcik avait dans son code ci-dessus.

kingosticks le 13 mai 2015

Difficile de voir comment le format pourrait être un problème... il est signé 16 bits
entiers. Le pire qui puisse arriver est que vous échangez les canaux L/R ?

Le 13 mai 2015 à 16h33, Nick Steel [email protected] a écrit :

Mon commentaire était basé sur la source ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.
La sortie Muet de Mopidy est désactivée par défaut, c'est-à-dire que le son n'est pas coupé.
Le visualiseur ncmpcpp prendra la sortie que vous lui avez donnée, la désactivera (non
effet), puis activez-le, coupant ainsi le son. Ils devraient sans doute
il suffit de le basculer deux fois.
L'audio étant dans le mauvais format est une bonne possibilité. Vous avez
rien dans votre pipeline gstreamer pour vous assurer qu'il est correct contrairement à @adamcik
https://github.com/adamcik avait dans son code ci-dessus.
-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment-101716947 .

liamw9534 le 13 mai 2015

Et même si l'ordre des octets était erroné, vous pourriez alors vous attendre à ce que la FFT
sortie pour générer la mauvaise réponse en fréquence ...... mais vous verriez toujours
quelque chose.

Le 13 mai 2015 à 16h37, Liam Wickins [email protected] a écrit :

Difficile de voir comment le format pourrait être un problème... il est signé 16 bits
entiers. Le pire qui puisse arriver est que vous échangez les canaux L/R ?
Le 13 mai 2015 à 16h33, Nick Steel [email protected] a écrit :
Mon commentaire était basé sur la source ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.
La sortie Muet de Mopidy est désactivée par défaut, c'est-à-dire que le son n'est pas coupé.
Le visualiseur ncmpcpp prendra la sortie que vous lui avez donnée, la désactivera (non
effet), puis activez-le, coupant ainsi le son. Ils devraient sans doute
il suffit de le basculer deux fois.
L'audio étant dans le mauvais format est une bonne possibilité. Vous avez
rien dans votre pipeline gstreamer pour s'assurer qu'il est correct contrairement
@adamcik https://github.com/adamcik avait dans son code ci-dessus.
-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment-101716947 .

liamw9534 le 13 mai 2015

oui c'est vrai, alors c'est peut-être parce que laisser la sortie Muet de Mopidy activée signifie que l'udpsink n'enverra aucune donnée.

kingosticks le 13 mai 2015

cat /tmp/mdp.fifo (créé à partir d'UDP comme ci-dessus) affiche correctement un flux constant de données.

J'ai regardé le code ncmpcpp du visualiseur :

ouvre le fichier en tant que O_RDONLY | O_NONBLOCK
lit du haut ; étant donné qu'il est réglé pour la stéréo dans ma configuration mpidy, il devrait être 44100:16:2.

N'importe qui peut aussi essayer depuis ma branche (après avoir installé Docker) :

git clone https://github.com/wernight/docker-mopidy.git
cd docker-mopidy
git checkout udpsink
docker build -t mopidy .
cd ..

git clone https://github.com/wernight/docker-ncmpcpp.git
cd docker-ncmpcpp
git checkout udpsink
docker build -t ncmpcpp .
cd ..

# Remember to enable PulseAudio over network 

docker run --name mopidy -d \
      -e PULSE_SERVER=tcp:$(hostname -i):4713 \
      -e PULSE_COOKIE_DATA=$(pax11publish -d | grep --color=never -Po '(?<=^Cookie: ).*') \
      mopidy
docker run --rm -it --link mopidy:mopidy ncmpcpp --host mopidy

wernight le 18 mai 2015

J'ai dû passer pas mal de temps à discuter de netcat car -k ne fonctionnait pas pour moi, mais voici ce que j'ai proposé pour le redémarrer automatiquement sur les commutateurs de chanson :

while :; do yes $'\n' | nc -lu 127.0.0.1 5555 > /tmp/mopidy.fifo; done

d'autres options comme ci-dessus essentiellement.

s-ol le 28 déc. 2015

@S0lll0s @wernight netcat -k n'a pas non plus fonctionné pour moi et a dû être redémarré après des changements de chanson. Bien que votre solution fonctionne, j'ai trouvé que socat fonctionnait mieux :

while :; do socat -d -d -T 1 -u UDP4-LISTEN:5555 OPEN:/tmp/mopidy.fifo; done

SjRNMzU le 6 févr. 2016

❤3

Pour les utilisateurs d'arch Linux :

Pour obtenir nc avec le support -k vous devez installer le package openbsd-netcat , mais cela n'a pas fonctionné pour moi non plus, alors essayez d'utiliser le script de @SjRNMzU - vous avez besoin le package socat pour l'exécuter.

johnhamelink le 3 sept. 2016

❤1

@johnhamelink (je suppose que vous exécutez Arch à partir de votre commentaire) Avez-vous eu des problèmes avec le visualiseur essayant de "rattraper" après avoir mis en pause une chanson en utilisant la solution socat ?

tmb le 4 juin 2017

@theos-space je ne peux pas dire que j'ai remarqué ça moi-même

johnhamelink le 5 juin 2017

Je suis sur Arch et je n'arrive pas à le faire fonctionner avec nc (à la fois gnu et openbsd ) ou socat . De plus, je ne peux pas lire à partir de gst-launch-1.0 ... udpsink port=5555 avec nc -kluw 1 127.0.0.1 5555 , car cela n'imprime rien à l'écran.

ranisalt le 6 juin 2017

👍1

Peut confirmer que cela fonctionne sur debian buster (4.11.6-1), mpidy 2.1.0-1, gstreamer1.0-tools 1.12.2-1, ncmpcpp 0.7.4-1+b3, socat 1.7.3.2-1 :

démarrer socat au démarrage du système :

open_mpd_fifo() {
    local fifo
    readonly fifo='/tmp/mpd.fifo'

    mkfifo "$fifo"
    while :; do socat -d -d -T 1 -u UDP4-LISTEN:5555 OPEN:"$fifo"; done
}

mpidy [audio] conf (notez que l'hôte devait être défini pour udpsink) :

[audio]
output = tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink host=127.0.0.1 port=5555

laur89 le 27 août 2017

ranisalt pour Arch, vous devez compiler ncmpcpp avec le support fifo, vérifiez ici : https://bbs.archlinux.org/viewtopic.php?id=99915

r1ft4469 le 30 sept. 2017

Voici ma configuration de travail Arch, après avoir lu le reste du fil + docs + pages de manuel + blogs assortis. J'exécute Mopidy en tant que service système et j'envoie l'audio au service utilisateur PulseAudio via TCP. J'ai inclus quelques annotations supplémentaires qui, espérons-le, aideront les moins expérimentés.

Paquets

Tous ces éléments proviennent des dépôts officiels d'Arch :

gstreamer 1.12.3-1
mopidy 2.1.0
ncmpcpp 0.8.1  # this had fifo support without any special compiling for me
openbsd-netcat 1.178_3-1  # gnu-netcat lacks the -k flag, as discussed above
pulseaudio 11.1

Installer

Activer le service système mpidy :

sudo systemctl enable mopidy.service

Remplacez la configuration système de mopidy par un lien symbolique vers la configuration utilisateur pour faciliter l'édition (facultatif) :

sudo ln -sf ~/.config/mopidy/mopidy.conf /etc/mopidy/mopidy.conf

Créez le fichier fifo :

mkfifo "/tmp/mpd.fifo"

Configurations

dans ~/.config/mopidy/mopidy.conf (ou /etc/mopidy/mopidy.conf si vous n'avez pas créé le lien symbolique): dites à mopidy d'envoyer l'audio à un serveur pulseaudio écoutant sur localhost et à un récepteur UDP sur localhost:5555

[audio]
output = tee name=t ! queue ! pulsesink server=127.0.0.1 t. ! queue ! udpsink host=127.0.0.1 port=5555

dans ~/.ncmpcpp/config : Dites à ncmpcpp où trouver le fichier fifo qu'il doit écouter, et quelques autres paramètres divers

visualizer_fifo_path = "/tmp/mpd.fifo"
visualizer_output_name = "my_fifo"
visualizer_sync_interval = "30"
visualizer_in_stereo = "yes"
visualizer_type = "spectrum"
visualizer_look = "+|"

in ~/.config/pulse/default.pa : Dites à pulseaudio d'accepter l'audio sur TCP de localhost (le paramètre est probablement déjà là et peut simplement être décommenté)

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1

dans ~/.zshrc (devrait également fonctionner dans ~/.bashrc ): Créez une fonction wrapper "nplayer" pour gérer le démarrage et l'arrêt de netcat avec ncmpcpp :

nplayer () (nc -kluw 1 127.0.0.1 5555 > /tmp/mpd.fifo & trap "kill $!" EXIT; ncmpcpp)

Qu'est-ce que cela fait :

définir une fonction avec un sous-shell enveloppant tout son contenu
démarrez un processus netcat en arrière-plan pour écouter les données audio envoyées au récepteur UDP et les rediriger vers la fifo créée précédemment. Drapeaux :
- -k continue d'écouter une fois la connexion en cours établie
- -l activer le mode d'écoute
- -u activer le mode UDP
- -w NUM timeout des connexions inactives après NUM secondes (1 seconde dans ce cas)
définir une interruption EXIT pour tuer le processus netcat lorsque le processus ncmpcpp se termine et provoque la sortie du sous-shell de la fonction
démarrer un processus ncmpcpp au premier plan

mosbasik le 27 nov. 2017

👍16 ❤1

J'exécute mpidy sur Manjaro (distro arch). J'avais du mal à obtenir une sortie via socat ou netcat. J'ai cependant pu observer les paquets entrants avec tcpdump :
sudo tcpdump -i lo -n udp port 5555 -XX

Cela m'a pris beaucoup de temps et je n'aurais pas trouvé le problème sans @mosbasik .
Le problème n'était pas d'avoir host=127.0.0.1 après udpsink, pourquoi cela fonctionne pour d'autres personnes et pas pour moi, je ne sais pas. Mais si vous n'obtenez aucune sortie, c'est possible. Ces 2 ont fonctionné pour moi:

[audio]
output = tee name=t ! queue ! autoaudiosink server=127.0.0.1 t. ! queue ! udpsink host=127.0.0.1 port=5555↪

[audio]
output = tee name=t ! queue ! autoaudiosink  t. ! queue ! udpsink host=127.0.0.1 port=5555↪

En passant : je n'ai pas réussi à faire fonctionner pulsesink , j'ai donc dû le laisser à autoaudiosink , ce que j'avais déjà réglé auparavant. ~~Cependant, le visualiseur semble être vraiment très lent pour une raison quelconque, je ne sais pas si c'est à cause de autoaudiosink~~ Fonctionne parfaitement après un redémarrage .. toujours légèrement lent cependant. Avec pulselink, il n'arrêtait pas de se plaindre des plugins gstreamer. Même après (je suppose) que j'ai installé tous les packages de plugins pour gst sur les dépôts officiels d'Arch. Remarque flump3dec et mad

Sortie de mopidy deps

Executable: /usr/bin/mopidy
Platform: Linux-4.16.7-1-MANJARO-x86_64-with-glibc2.2.5
Python: CPython 2.7.15 from /usr/lib/python2.7
Mopidy: 2.2.1 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
    chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
    idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
    urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
    futures: 3.2.0 from /usr/lib/python2.7/site-packages
    singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
      six: 1.11.0 from /usr/lib/python2.7/site-packages
    backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
Mopidy-Iris: 3.4.9 from /usr/lib/python2.7/site-packages
  setuptools>=3.3: 40.5.0 from /usr/lib/python2.7/site-packages
  pylast>=1.6.0: 2.3.0 from /usr/lib/python2.7/site-packages
    six: 1.11.0 from /usr/lib/python2.7/site-packages
  Mopidy>=2.0: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Mopidy-Local-Images>=1.0: 1.0.0 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    Mopidy>=1.1: 2.2.1 from /usr/lib/python2.7/site-packages
      Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
      requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
        chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
        idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
        urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
      setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
      tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
        futures: 3.2.0 from /usr/lib/python2.7/site-packages
        singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
          six: 1.11.0 from /usr/lib/python2.7/site-packages
        backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    uritools>=1.0: 1.0.1 from /usr/lib/python2.7/site-packages
      ipaddress>=1.0.6: 1.0.22 from /usr/lib/python2.7/site-packages
      ipaddress>=1.0.6: 1.0.22 from /usr/lib/python2.7/site-packages
  ConfigObj>=5.0.6: 5.0.6 from /usr/lib/python2.7/site-packages
  raven>=6.1.0: 6.9.0 from /usr/lib/python2.7/site-packages
    contextlib2: 0.5.5 from /usr/lib/python2.7/site-packages
Mopidy-Local-Images: 1.0.0 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  Mopidy>=1.1: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  uritools>=1.0: 1.0.1 from /usr/lib/python2.7/site-packages
    ipaddress>=1.0.6: 1.0.22 from /usr/lib/python2.7/site-packages
    ipaddress>=1.0.6: 1.0.22 from /usr/lib/python2.7/site-packages
Mopidy-Spotify-Tunigo: 1.0.0 from /usr/lib/python2.7/site-packages
  Mopidy>=0.19.0: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Mopidy-Spotify>=1.2.0: 3.1.0 from /usr/lib/python2.7/site-packages
    Mopidy>=2.0: 2.2.1 from /usr/lib/python2.7/site-packages
      Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
      requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
        chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
        idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
        urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
      setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
      tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
        futures: 3.2.0 from /usr/lib/python2.7/site-packages
        singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
          six: 1.11.0 from /usr/lib/python2.7/site-packages
        backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    pyspotify>=2.0.5: 2.0.5 from /usr/lib/python2.7/site-packages
      cffi>=1.0.0: 1.11.5 from /usr/lib/python2.7/site-packages
        pycparser: 2.19 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  tunigo>=1.0.0: 1.0.0 from /usr/lib/python2.7/site-packages
    requests>=2.0.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
Mopidy-SoundCloud: 2.1.0 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  Mopidy>=1.0: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  requests>=2.0.0: 2.20.1 from /usr/lib/python2.7/site-packages
    chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
    idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
    urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
Mopidy-Spotify: 3.1.0 from /usr/lib/python2.7/site-packages
  Mopidy>=2.0: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  pyspotify>=2.0.5: 2.0.5 from /usr/lib/python2.7/site-packages
    cffi>=1.0.0: 1.11.5 from /usr/lib/python2.7/site-packages
      pycparser: 2.19 from /usr/lib/python2.7/site-packages
  requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
    chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
    idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
    urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
GStreamer: 1.14.4.0 from /usr/lib/python2.7/site-packages/gi
  Detailed information: 
    Python wrapper: python-gi 3.30.2
    Relevant elements:
      Found:
        uridecodebin
        souphttpsrc
        appsrc
        alsasink
        osssink
        oss4sink
        pulsesink
        id3demux
        id3v2mux
        lamemp3enc
        mpegaudioparse
        mpg123audiodec
        vorbisdec
        vorbisenc
        vorbisparse
        oggdemux
        oggmux
        oggparse
        flacdec
        flacparse
        shout2send
      Not found:
        flump3dec
        mad

ducklin5 le 14 déc. 2018

👍3

Je rencontre un problème en essayant de faire fonctionner udpsink avec Mopidy et tous les clients ncmpcpp distants. Mopidy est configuré avec MacVLAN dans un environnement Docker. Je peux voir avec succès le port sur le conteneur.

nc -vz -u mopidy.lan 5555
found 0 associations
found 1 connections:
     1: flags=82<CONNECTED,PREFERRED>
    outif (null)
    src x.x.x.x port 50630
    dst x.x.x.x port 5555
    rank info not available

Connection to mopidy.lan port 5555 [udp/personal-agent] succeeded!

Actuellement, Mopidy utilise le bit de configuration suivant :

[audio]
mixer = software
mixer_volume = 100
output = tee name=t ! queue ! lamemp3enc ! shout2send async=false mount=mopidy ip="mopidy.lan" port=8092 username="some username" password="some password" t. ! queue ! udpsink host=0.0.0.0 port=5555

Des idées sur la façon dont je peux utiliser netcat pour réussir à obtenir les données brutes dans mpd.fifo ? L'utilisation de ce qui suit ne fonctionne pas, je pense parce que j'utilise netcat de la mauvaise manière. Certaines recherches n'ont fourni aucune réponse, alors j'espère que quelqu'un pourra m'orienter dans la bonne direction.

#!/bin/bash

mkfifo /tmp/mpd.fifo
while :; do yes $'\n' | nc -lu mopidy 5555 > /tmp/mpd.fifo; done

J'obtiens l'erreur suivante :

nc: Can't assign requested address

Des idées sur la façon dont je peux faire fonctionner cela?

Acclamations!

80scyborgninja le 1 mars 2019

Pour info, j'ai ajouté le support de udpsink de gstreamer à ncmpcpp afin qu'il puisse maintenant être utilisé directement sans hacks fifo.

Voir https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 pour plus de détails.

Ci-dessous un teaser. Il s'agit de mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

https://user-images.githubusercontent.com/387658/102549720-e41bf980-40bc-11eb-8127-70889011e52f.mp4

arybczak le 17 déc. 2020

❤10 🎉6 👍6 👀2

@arybczak Génial ! Vous devriez poster ceci sur https://discourse.mopidy.com/c/show-and-tell/9

jodal le 19 déc. 2020

👍2

@adamcik Cela ne signifie-t-il pas que ce problème de près de 7 ans est "obsolète" au profit d'une meilleure résolution du problème réel qui l'a déclenché (prise en charge des visualisations dans ncmpcpp) ?

pspeder le 12 févr. 2021

@pspeder , qu'est-ce que tu veux dire exactement ? Y a-t-il un problème avec l'utilisation de https://github.com/mopidy/mopidy/issues/775#issuecomment -747725806 ?

kingosticks le 12 févr. 2021

@kingosticks suggérait simplement que ce problème soit clos 🙂

pspeder le 13 févr. 2021

Je suis d'accord avec ca.

kingosticks le 13 févr. 2021

Cette page vous a été utile?

0 / 5 - 0 notes