Mopidy: Considere la posibilidad de agregar un fregadero gstreamer FIFO

Creado en 8 jul. 2014 · 73Comentarios · Fuente: mopidy/mopidy

Esto sigue apareciendo ya que a la gente realmente parece gustarle el visualizador de ncmpcpp

El truco para hacer un fregadero FIFO confiable es doble. Debe utilizar escrituras sin bloqueo, lo que significa que la apertura del conector de escritura fallará a menos que haya un lector, por lo que también necesita un lector. En segundo lugar, si el búfer se llena porque el lector externo se queda atrás o no hay ninguno, su lector interno debe borrar el búfer.

El siguiente código captura la esencia básica de esto, pero aún necesita un poco más de trabajo con respecto al manejo de errores.

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

El código anterior ahora debe integrarse con GStreamer. Suponiendo que 0.10 esto es realmente muy factible, la razón por la que dudo es que estamos planeando un cambio a 1.xy la encuadernación gir no es adecuada para hacer elementos en Python. En el caso de este código en 1.x, el problema se reduce a no poder crear las plantillas de pad que BaseSink espera encontrar. Crear esto como un elemento simple podría ser factible, pero necesitaría volver a implementar gran parte del manejo de BaseSink para asegurarse de hacerlo bien.

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)

Tenga en cuenta que un problema que encontré al probar esto fue en realidad olvidarme de hacer coincidir el formato de audio esperado por ncmpcpp, así que asegúrese de que mono / estéreo coincidan.

C-enhancement A-audio

Fuente

adamcik

👍8

Comentario más útil

Para su información, agregué soporte para udpsink de gstreamer a ncmpcpp, por lo que ahora se puede usar directamente sin quince hacks.

Consulte https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 para obtener más detalles.

Debajo de un teaser. Esto es mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

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

arybczak en 17 dic. 2020

❤10 🎉6 👍6 👀2

Todos 73 comentarios

¿A dónde se fue esto? ¿Se agregará esto al paquete principal?

CestDiego en 6 oct. 2014

No se está trabajando en esto, ya que necesitaríamos convertirlo a GStreamer 1.0, y todos mis experimentos con eso hasta ahora han descubierto problemas al hacer elementos personalizados en Python. Hay otras formas de resolverlo todo, pero no es algo en lo que tenga tiempo para trabajar.

adamcik en 11 oct. 2014

Me gustaría ver agregado soporte FIFO :)

johnhamelink en 6 nov. 2014

Encontré esto buscando una manera de hacer que el visualizador de música de ncmpcpp funcione con mopidy. Yo estoy a favor.

proxa en 6 nov. 2014

Sí, esa es la misma razón por la que encontré esto. Sería realmente genial
poder visualizar la música transmitida,

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

Encontré esto buscando una manera de hacer que el visualizador de música de ncmpcpp
trabajar con mopidy. Yo estoy a favor.
-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

CestDiego en 6 nov. 2014

Existen complementos de visualización de gstreamer, ¿no puedes usarlos simplemente?
El 6 de noviembre de 2014 a las 08:35, "Diego Berrocal" [email protected] escribió:

Sí, esa es la misma razón por la que encontré esto. Sería realmente genial
poder visualizar la música transmitida,

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

Encontré esto buscando una forma de obtener el visualizador de música de ncmpcpp
a
trabajar con mopidy. Yo estoy a favor.
-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -62007426.

kingosticks en 6 nov. 2014

Tenga en cuenta que están a punto de desaparecer en la próxima versión.

adamcik en 6 nov. 2014

¿Hay alguien trabajando en esto? Sería muy bueno poder usar el visualizador ncmpcpp con mopidy.

andreasboden en 13 feb. 2015

No que yo sepa, y es probable que no queramos hacer esto como elemento GStreamer ya que bloquearía nuestra migración a GStreamer 1.x.

adamcik en 14 feb. 2015

Esto también está bloqueado en la OMI para volver a agregar el soporte adecuado para las salidas.

adamcik en 25 feb. 2015

Solo agregué que también encontré este problema al intentar agregar soporte de visualizador a Mopidy / ncmpcpp. Me encantaría tener esto en el futuro incluso si no se está trabajando actualmente. También me gustaría extender mi mayor respeto por aquellos que contribuyen con su tiempo a proyectos de código abierto. :sonrisa:

codeurge en 15 abr. 2015

Idealmente, esto funcionaría de forma remota. El poder de Mopidy radica realmente en ser una solución que puede estar en su nube privada.

wernight en 27 abr. 2015

En general, los FIFO no son un método muy portátil de comunicaciones entre procesos y, en mi opinión, deben evitarse. También tienen algunos efectos secundarios desagradables, ya mencionados en este hilo. Creo que es mejor que descargue sus paquetes usando un sumidero UDP personalmente ... esa es una solución más genérica y se puede adaptar fácilmente a algo que escribe en un FIFO (si es necesario) fuera de Mopidy ... es una única línea de script de shell para leer datos de un puerto UDP (usando netcat) y escribirlos en un FIFO.

liamw9534 en 27 abr. 2015

Eso suena bien. Puede ser que los clientes mientan ncmpcpp también permitiría usar eso como entrada.

Otra idea es usar PulseAudio directamente, ya que no requeriría una implementación adicional por parte de Mopidy. El contenedor Docker que hice usa TCP para acceder a PulseAudio a través de la red. ncmpcpp podría usar eso directamente.

wernight en 27 abr. 2015

Por lo que he leído, el visualizador solo está ejecutando una FFT en bloques de muestras que se leen desde un archivo FIFO. El punto que estoy diciendo es que puede crear un FIFO fuera de Mopidy usando mkfifo y luego leer los datos UDP de Mopidy usando netcat y redirigir la salida de netcat al Archivo FIFO. Por lo tanto, no es necesario cambiar nada en lo que respecta a ncmpcpp , solo lee el archivo FIFO.

Para lograr lo que busca en Mopidy no se requiere ningún esfuerzo de implementación, ya que puede cambiar la propiedad de salida de audio para que se envíe a un elemento udpsink GStreamer. Lo más probable es que desee disponerlo como parte de una "T" que emite tanto a su disipador ALSA / Pulse como al disipador udpsink.

liamw9534 en 28 abr. 2015

Lo siguiente debería funcionar ... no probado, por lo que es posible que necesite algunos ajustes.

En la configuración de audio de Mopidy:

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

En su host Linux, inicie netcat para escuchar en localhost los datos UDP en el puerto 5555 y envíe las muestras al FIFO:

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

En su mpd.conf:

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

liamw9534 en 28 abr. 2015

Nota: Si está utilizando una salida PulseAudio, es posible que haga algo similar con su módulo de conexión de dirección TCP. Sin embargo, es posible que deba aplicar ingeniería inversa a cualquier protocolo que se ejecute en la parte superior de la conexión TCP, por ejemplo, es posible que no sea posible tratarlo como un sumidero sin formato.

liamw9534 en 28 abr. 2015

Gracias @ liamw9534 por compartir. Me habría llevado un tiempo comprender la configuración lo suficiente como para hacer eso o incluso saber que podría hacerlo. Intentaré agregar eso al contenedor Docker para ver si funciona.

wernight en 28 abr. 2015

Sin embargo, esto podría tener problemas si no tiene algo que vacíe el quince. Como netcat llenará el búfer del kernel y luego fallará. Y dependiendo de cómo se abra el FIFO, también puede tener problemas, ya que los FIFO pueden requerir que un lector esté presente para poder escribir: /

adamcik en 28 abr. 2015

Pero podría adaptar mi código FifoStreamer para aceptar los datos UDP y manejar esto por usted, ya que espero que ya haya manejado la mayoría de los casos de error que puede encontrar allí.

adamcik en 28 abr. 2015

@adamcik Si tiene un script que funcione, me complacería incluirlo como parte de docker-ncmpcpp para que la gente lo use. También cambiaría docker-mopidy para transmitir en UDP de forma predeterminada usando el truco de salida anterior.

wernight en 29 abr. 2015

Hice algunos experimentos básicos en la línea de comandos y todo funciona bien siempre que use un tiempo de espera de conexión, por ejemplo, nc -kluw 1 127.0.0.1 5555 > /tmp/mopidy.fifo . Esto obliga a netcat a escuchar siempre una nueva conexión de puerto de origen después de que se caiga la última conexión (tiempo de espera de 1 s).

El comando anterior funciona independientemente de si se está leyendo o no algo del archivo FIFO y también funciona si el proceso de lectura del archivo FIFO se detiene y cierra el archivo.

liamw9534 en 29 abr. 2015

@wernight vea la descripción de este error, ese es todo el código que tengo.

adamcik en 29 abr. 2015

Y solo para cinturones y tirantes, pegaría el comando en un ciclo while, por ejemplo, while :; do nc -kluw 1 127.0.0.1 5555> /tmp/mopidy.fifo; sleep 1; done - si sale, simplemente se lanzará nuevamente después de 1 segundo de retraso.

liamw9534 en 29 abr. 2015

@ liamw9534 Tienes un mpd.conf allí. Estoy confundido por esto. ¿Está ejecutando un servidor MPD independiente además de mopidy-mpd?

lrvick en 2 may. 2015

@lrvick, sí, mi error, por supuesto, estaba pensando en la configuración que debe agregarse a ~ / .ncmpcpp / config

liamw9534 en 2 may. 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

(agregado -p aquí).

~/.ncmpcpp/config

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

(hecho también en wernight / docker-mopidy y wernight / docker-ncmpcpp )

Sin embargo, parece que no puede conectarse a 5555 aunque el registro de Mopidy muestra que entendió la configuración output . netstat tampoco muestra UDP abierto en 5555. No entiendo completamente la línea output : tee es un comando bash, el resto se parece a cosas de Mopidy.

Sin embargo, encontré udp6 [::]:51307 mientras reproducía música.

wernight en 8 may. 2015

El output se interpreta como un elemento GstBin que se pasa a playbin2 como parte de Mopidy; bajo el capó, esto es solo una tubería de Gstreamer, nada especial en realidad. El tee es en realidad, por lo tanto, un elemento de Gstreamer. No tiene nada que ver con el comando de shell tee .

Entonces puede aproximar lo que está sucediendo dentro de Mopidy en la línea de comandos haciendo algo como:

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

Esto comenzará a reproducir un tono sinusoidal. Luego ejecute el siguiente comando:

nc -kluw 1 127.0.0.1 5555

Entonces puedo comenzar a ver muchos caracteres extraños en mi pantalla ... esta es la salida de flujo de audio de prueba a stdout desde nc . Esto demuestra efectivamente que el enfoque subyacente funciona. ¿Puede confirmar que puede replicar el mismo comportamiento?

Luego puede intentar agregar el FIFO como un segundo paso y confirmar que puede cat el FIFO para salir estándar y ver los mismos caracteres extraños.

liamw9534 en 8 may. 2015

También comprobaría el formato de configuración que necesita ncmpcpp . Eché un vistazo breve a https://wiki.archlinux.org/index.php/Ncmpcpp#Enabling_visualization y puedo ver que tal vez el formato de configuración necesario es diferente, por ejemplo,

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

No uso ncmpcpp , por lo que el problema también podría estar aquí ...

liamw9534 en 8 may. 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

(con nc ... -p contrario me sale un error)

Sin embargo, escucho el tono.

wernight en 11 may. 2015

¿Qué distro está usando? Además, cuando escribe nc -h ¿cuál es la salida?

$ 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]

La opción -p no es necesaria con la opción nc que estoy usando en Ubuntu. La página de manual también implica que debería ser un error especificar -p junto con -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 en 11 may. 2015

Usando Debian Wheezy.

Aquí están los pasos completos para Ubuntu comenzando instalando Docker :

Instalar Docker :

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

Habilitar PulseAudio remoto
Ejecutar en 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 en 11 may. 2015

Probé con el paquete netcat-openbsd que da:

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

Ahora nc simplemente no muestra nada mientras se reproduce el tono (que parece algo mejor):

$ nc -kluw 1 127.0.0.1 5555
(nothing here)

wernight en 11 may. 2015

Ok, abre dos terminales y en la primera terminal ejecuta:

nc -kluw 1 127.0.0.1 5555

Luego, en la segunda terminal, ejecute:

nc -u 127.0.0.1 5555

Ingrese algunos caracteres en stdin en la segunda terminal y presione ENTER. ¿Ves aparecer los mismos caracteres en la primera terminal en stdout?

liamw9534 en 11 may. 2015

Sí, eso funciona. Incluso consiguió que funcionara entre 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

Entonces esto no explica por qué nc no mostró nada con gst-launch . Sin embargo, descubrí que necesitaría configurar host=SOMETHING para que funcione en todos los contenedores. Esto será problemático. Parece que no se puede transmitir. Pero eso es algo que podré resolver una vez que funcione al menos en un solo contenedor.

wernight en 11 may. 2015

¡Ajá! Si configuro host=0.0.0.0 , ¡funciona!

wernight en 11 may. 2015

👍2

¿Necesita enviar los datos a través de una red? Supuse que solo necesitabas los paquetes en la máquina local. El uso de udpsink host=0.0.0.0 port=5555 transmitirá paquetes a todas partes de su red. Probablemente no sea lo que quieres ...

Debería poder decir host=127.0.0.1 lugar para restringir los paquetes al loopback local.

Sospecho que, por lo tanto, el problema real se debe a la configuración de enrutamiento predeterminada. De forma predeterminada, en su sistema, los paquetes salientes se canalizan a una interfaz diferente. Posiblemente versiones diferentes del elemento gstreamer o diferencias en la configuración del enrutamiento IP.

liamw9534 en 11 may. 2015

Desde el contenedor tuve que usar 0.0.0.0 o posiblemente la IP de la máquina. La configuración predeterminada no funcionaba ni siquiera en una sola máquina / contenedor.

Pero sí, tengo que usar la red ahora porque es una buena práctica mantener ncmpcpp y mopidy en contenedores Docker separados, lo que significa que están en redes diferentes. Eso es realmente bueno para la seguridad y el aislamiento y demás, pero crea un pequeño problema:

El cliente ncmpcpp se conecta al servidor MPD para solicitar la transmisión de música, y solo después de ese punto se conoce la IP de ncmpcpp y el paquete UDP debe transmitirse a su IP; pero actualmente la IP está codificada en la configuración de Mopidy.

No tengo una solución en este momento. Estoy pensando en soluciones:

Crear el FIFO en Mopidy y compartirlo con ncmpcpp, pero me temo que nada borrará el FIFO y eso es un gran problema. Además, compartir archivos no es tan limpio como los enchufes de red.
El demonio local monitorea las conexiones y reenvía el tráfico UDP a la IP del cliente encontrada; cortar a tajos.
Túnel UDP SSH , pero eso es complejo, agrega encriptación inútil, agrega otro demonio ... ¡malo!
Observando el código para ver si el host udpsink se puede establecer de forma predeterminada en la IP del primer cliente o, mejor aún, en las IP de todos los clientes conectados
Dígale a Docker que comparta el host a través de --net=container:NAME_or_ID que agrega otro parámetro para que los usuarios escriban, ¡pero eso simplificaría mucho!

Hay soluciones para esta dependencia circular. Todavía se siente como un truco horrible, pero debería ser lo suficientemente fácil de usar para los usuarios al final. Gracias liamw9534 por ayudar especialmente con los comandos nc que era alienígena.

wernight en 12 may. 2015

El FIFO está funcionando excepto que There is no output named "my_fifo"! . Parece que el nombre tiene que coincidir con el de mdp.conf :

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

Puedo intentar compartir el archivo FIFO si sé cómo agregar esta salida de audio a Mopidy. las náuseas (un simple visualizador) parecen tener los mismos requisitos.

Encontré esta documentación de visualizer_output_name :

El siguiente parámetro es necesario para que ncmpcpp determine qué salida proporciona datos para el visualizador y, por lo tanto, permite la sincronización entre la visualización y el sonido, ya que actualmente existen algunos problemas.
salida Fifa, cuyo parámetro de formato debe establecerse en 44100: 16: 1 para visualización mono o 44100: 16: 2 para visualización estéreo

wernight en 12 may. 2015

No estoy seguro de lo que quiere decir con "en diferentes redes". Si desea aislar el tráfico de audio a la máquina local, debe usar 127.0.0.1 para udpsink . Si elige 0.0.0.0 , dirigirá los paquetes utilizando la ruta predeterminada, lo que probablemente signifique enviar paquetes UDP a través de la red ... en general, diría que esta es una mala idea porque el tráfico de la red consumirá un mucho ancho de banda, es decir, 2 x 16 x 44100 = 1,41 Mbps.

En teoría, debería ser posible configurar nc con 0.0.0.0 independientemente de la interfaz de red que utilice udpsink . Esto escuchará en todas las interfaces de red. Eso está bien siempre que no use el mismo número de puerto IP para otros servicios en diferentes interfaces de red.

liamw9534 en 12 may. 2015

Usé mi última sugerencia y puse ambas en la misma red. De todos modos, esas redes son locales, es solo una separación lógica. Eso funciona para construir el FIFO, solo que ncmpcpp no lo quiere (vea mi respuesta anterior, 2 arriba).

wernight en 12 may. 2015

¿Alguna idea sobre el nombre de ese canal? ¿O si hay otra forma de un FIFO como mpd.conf ? No parece funcionar en absoluto sin.

wernight en 13 may. 2015

Pensé que mpd.conf se usaba solo para la configuración del demonio MPD. En este caso, eso debería ser redundante porque mopidy es el demonio MPD y su ventana acoplable está creando el archivo FIFO. En cuyo caso, lo único que debería ser necesario es asegurarse de que .ncmpcpp/config coincida con el cliente, ¿verdad?

liamw9534 en 13 may. 2015

Mas o menos. No sé qué está haciendo exactamente. Pero como puede ver, visualizer_output_name = "my_fifo" debe coincidir con audio_output { name "my_fifo" } . Actualmente ncmpcpp muestra There is no output named "my_fifo" . La descripción de visualizer_output_name está solo 5 publicaciones arriba. Parece que en realidad se está conectando directamente de alguna manera a la salida para sincronizar.

wernight en 13 may. 2015

No uso nada de esto, pero me parece que visualizer_output_name debería coincidir con una de sus salidas MPD (protocolo, no programa) (es decir, algo en mpc outputs ). Mopidy actualmente no permite salidas configurables y solo tiene una salida MPD: "Mute".

Probablemente desee desarmar visualizer_output_name , si es posible.

kingosticks en 13 may. 2015

Intenté no configurarlo. Todavía no hay visualizador visible. Me pregunto sobre el formato de salida de udpsink : Debería ser 44100:16:2 para que los visualizadores funcionen ( ncmpcpp o nausea ).

Probé Mute si acaso, obtuve una experiencia muy divertida: simplemente silenció el sonido, sin mostrar un error pero también sin mostrar visualizadores. O más exactamente desactivó la salida Mute .

wernight en 13 may. 2015

Me pregunto dónde se realiza la función FFT para el visualizador.
¿Se realiza en la salida del FIFO o en la entrada del FIFO? Ustedes
necesitaría verificar el código del cliente MPD para ver cómo maneja los datos FIFO.

liamw9534 en 13 may. 2015

¿Hay alguna manera de admitir cualquiera de los dos, solo para pruebas, incluso si normalmente crearía un archivo monstruosamente enorme?

wernight en 13 may. 2015

Tampoco necesitas apoyo. Necesita averiguar dónde está la FFT
se supone que debe hacerse y luego elija el enfoque correcto. Si la FFT es
hecho en el visualizador, entonces sería una completa pérdida de esfuerzo
implementarlo de nuevo.

El 13 de mayo de 2015 a las 15:09, Werner Beroux [email protected] escribió:

¿Hay alguna manera de admitir cualquiera de los dos, solo para pruebas, incluso si
normalmente crea un archivo monstruosamente enorme.
-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101676033.

liamw9534 en 13 may. 2015

FFT lo realiza el visualizador y requiere el formato de audio específico en el FIFO para funcionar. Referencia: http://git.2f30.org/nausea/about/

wernight en 13 may. 2015

Bien, entonces no hay razón para que no funcione. Has hecho un
comparación en paralelo de un sistema que ejecuta un demonio MPD estándar con un
cliente local ncmpcpp? ¿Qué sucede si cambia el nombre del archivo FIFO en ambos
los archivos de configuración? ¿Todavía funciona? Solo trato de ver si un
La ruta codificada existe en algún lugar ...

El 13 de mayo de 2015 a las 15:57, Werner Beroux [email protected] escribió:

FFT lo realiza el visualizador y requiere el formato de audio específico
en el FIFO para trabajar por eso. Referencia: http://git.2f30.org/nausea/about/
-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101702624.

liamw9534 en 13 may. 2015

Mi comentario se basó en la fuente ncmpcpp .

La salida de silencio de Mopidy está desactivada de forma predeterminada, es decir, el audio no está silenciado. El visualizador ncmpcpp tomará la salida que le dio, la deshabilitará (sin efecto) y luego la habilitará, silenciando así el audio. Podría decirse que deberían alternarlo dos veces.

El audio en el formato incorrecto es una buena posibilidad. No tiene nada en su canalización de gstreamer para asegurarse de que sea correcto, a diferencia de lo que @adamcik tenía en su código anterior.

kingosticks en 13 may. 2015

Es difícil ver cómo el formato podría ser un problema ... está firmado en 16 bits
enteros. ¿Lo peor que podría pasar es que intercambie los canales L / R?

El 13 de mayo de 2015 a las 16:33, Nick Steel [email protected] escribió:

Mi comentario se basó en la fuente ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.
La salida de silencio de Mopidy está desactivada de forma predeterminada, es decir, el audio no está silenciado.
El visualizador ncmpcpp tomará el resultado que le dio, lo desactivará (no
efecto) y luego habilítelo, silenciando así el audio. Podría decirse que deberían
simplemente alternarlo dos veces.
El audio en el formato incorrecto es una buena posibilidad. Tienes
nada en su canalización de gstreamer para garantizar que sea correcto a diferencia de @adamcik
https://github.com/adamcik tenía en su código anterior.
-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

liamw9534 en 13 may. 2015

E incluso si el orden de los bytes fuera incorrecto, podría esperar que la FFT
salida para generar la respuesta de frecuencia incorrecta ... pero todavía vería
algo.

El 13 de mayo de 2015 a las 16:37, Liam Wickins [email protected] escribió:

Es difícil ver cómo el formato podría ser un problema ... está firmado en 16 bits
enteros. ¿Lo peor que podría pasar es que intercambie los canales L / R?
El 13 de mayo de 2015 a las 16:33, Nick Steel [email protected] escribió:
Mi comentario se basó en la fuente ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.
La salida de silencio de Mopidy está desactivada de forma predeterminada, es decir, el audio no está silenciado.
El visualizador ncmpcpp tomará el resultado que le dio, lo desactivará (no
efecto) y luego habilítelo, silenciando así el audio. Podría decirse que deberían
simplemente alternarlo dos veces.
El audio en el formato incorrecto es una buena posibilidad. Tienes
nada en su canalización de gstreamer para garantizar que sea correcto, a diferencia de
@adamcik https://github.com/adamcik tenía en su código anterior.
-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

liamw9534 en 13 may. 2015

Sí, es cierto, así que tal vez sea porque dejar la salida Mute de Mopidy habilitada significa que el udpsink no enviará ningún dato.

kingosticks en 13 may. 2015

cat /tmp/mdp.fifo (creado a partir de UDP como arriba) muestra correctamente un flujo constante de datos.

Miré el código ncmpcpp del visualizador:

abre el archivo como O_RDONLY | O_NONBLOCK
lee desde arriba ; dado que está configurado para estéreo en mi configuración de mopidy, debería ser 44100: 16: 2.

Cualquiera también puede probar desde mi rama (después de haber instalado 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 en 18 may. 2015

Tuve que pasar bastante tiempo discutiendo netcat porque -k no funcionó para mí, pero esto es lo que se me ocurrió para reiniciarlo automáticamente en los interruptores de canción:

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

otras opciones como las anteriores básicamente.

s-ol en 28 dic. 2015

@ S0lll0s @wernight netcat -k tampoco funcionó para mí y tuve que reiniciar después de los cambios de canción. Si bien su solución funciona, he descubierto que socat funciona mejor:

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

SjRNMzU en 6 feb. 2016

❤3

Para usuarios de arch linux:

Para obtener nc con -k soporte, necesita instalar el paquete openbsd-netcat , pero tampoco funcionó para mí, así que intente usar el script de socat para ejecutarlo.

johnhamelink en 3 sept. 2016

❤1

@johnhamelink (supongo que está ejecutando Arch desde su comentario) ¿Ha tenido problemas con el visualizador tratando de "ponerse al día" después de pausar una canción usando la solución socat ?

tmb en 4 jun. 2017

@ theos-space No puedo decir que me haya dado cuenta de eso

johnhamelink en 5 jun. 2017

Estoy en Arch y no pude hacer que funcione con nc (tanto gnu como openbsd ) o socat . Además, no puedo leer desde gst-launch-1.0 ... udpsink port=5555 con nc -kluw 1 127.0.0.1 5555 , ya que no imprime nada en la pantalla.

ranisalt en 6 jun. 2017

👍1

Puedo confirmar que esto funciona en debian buster (4.11.6-1), mopidy 2.1.0-1, gstreamer1.0-tools 1.12.2-1, ncmpcpp 0.7.4-1 + b3, socat 1.7.3.2-1:

iniciar socat en el inicio del sistema:

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
}

mopidy [audio] conf (tenga en cuenta que el host debe definirse para udpsink):

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

laur89 en 27 ago. 2017

ranisalt para Arch, tienes que compilar ncmpcpp con soporte de FIFO, verifica aquí: https://bbs.archlinux.org/viewtopic.php?id=99915

r1ft4469 en 30 sept. 2017

Aquí está mi configuración de Arch en funcionamiento, después de leer el resto del hilo + documentos + páginas de manual + blogs variados. Estoy ejecutando Mopidy como un servicio del sistema y envío el audio al servicio de usuario PulseAudio a través de TCP. He incluido algunas anotaciones adicionales que, con suerte, ayudarán a los menos experimentados.

Paquetes

Todos estos son de los repositorios oficiales de 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

Configuración

Habilite el servicio del sistema mopidy:

sudo systemctl enable mopidy.service

Reemplace la configuración del sistema de mopidy con un enlace simbólico a la configuración del usuario para facilitar la edición (opcional):

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

Crea el archivo FIFO:

mkfifo "/tmp/mpd.fifo"

Configs

en ~/.config/mopidy/mopidy.conf (o /etc/mopidy/mopidy.conf si no creó el enlace simbólico): Dígale a mopidy que envíe audio a un servidor pulseaudio que escucha en localhost y a un receptor UDP en localhost: 5555

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

en ~/.ncmpcpp/config : Dígale a ncmpcpp dónde encontrar el archivo FIFO que necesita escuchar, y algunas otras configuraciones misceláneas

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

en ~/.config/pulse/default.pa : Dígale a pulseaudio que acepte audio a través de TCP desde localhost (es probable que la configuración ya esté allí y se pueda descomentar)

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

en ~/.zshrc (también debería funcionar en ~/.bashrc ): Cree una función contenedora "nplayer" para manejar el inicio y la detención de netcat con ncmpcpp :

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

Que hace esto:

definir una función con una subcapa que envuelve todo su contenido
inicie un proceso netcat en segundo plano para escuchar los datos de audio enviados al sumidero UDP y redirigirlos a la FIFo creada anteriormente. Banderas:
- -k siga escuchando después de que se complete la conexión actual
- -l habilitar el modo de escucha
- -u habilitar el modo UDP
- -w NUM timeout conexiones inactivas después de NUM segundos (1 segundo en este caso)
establecer una trampa EXIT para matar el proceso netcat cuando el proceso ncmpcpp termina y hace que la función subshell salga
iniciar un proceso ncmpcpp en primer plano

mosbasik en 27 nov. 2017

👍16 ❤1

Estoy ejecutando mopidy en Manjaro (arch distro). Tenía problemas para obtener resultados a través de socat o netcat. Sin embargo, pude observar los paquetes que entraban con tcpdump:
sudo tcpdump -i lo -n udp port 5555 -XX

Me tomó mucho tiempo y no habría encontrado el problema sin @mosbasik .
El problema era no tener host=127.0.0.1 después de udpsink, no sé por qué esto funciona para otras personas y no para mí. Pero si no obtiene ningún resultado, es posible que este sea el caso. Estos 2 funcionaron para mí:

[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 una nota al margen: no pude hacer que pulsesink funcionara, así que tuve que dejarlo en autoaudiosink , que es lo que también tenía configurado antes. ~~Sin embargo, el visualizador parece ser muy lento por alguna razón, no estoy seguro si eso se debe a que autoaudiosink~~ funciona perfectamente después de un reinicio ... aunque sigue siendo un poco lento. Con pulselink seguía quejándose de los complementos de gstreamer. Incluso después (supongo) instalé todos los paquetes de complementos para gst en los repositorios oficiales de Arch. Tenga en cuenta flump3dec y mad

Salida 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 en 14 dic. 2018

👍3

Tengo un problema al intentar que udpsink funcione con Mopidy y todos los clientes ncmpcpp remotos. Mopidy está configurado con MacVLAN en un entorno de ventana acoplable. Puedo ver con éxito el puerto en el contenedor.

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!

Actualmente, Mopidy está usando el siguiente bit de configuración:

[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

¿Alguna idea sobre cómo puedo usar netcat para obtener con éxito los datos sin procesar en mpd.fifo? Usar lo siguiente no funciona, creo que porque estoy usando netcat de manera incorrecta. Algunas investigaciones no han proporcionado ninguna respuesta, así que espero que alguien pueda señalarme en la dirección correcta.

#!/bin/bash

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

Obtuve el siguiente error:

nc: Can't assign requested address

¿Alguna idea sobre cómo puedo hacer que esto funcione?

¡Salud!

80scyborgninja en 1 mar. 2019

Para su información, agregué soporte para udpsink de gstreamer a ncmpcpp, por lo que ahora se puede usar directamente sin quince hacks.

Consulte https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 para obtener más detalles.

Debajo de un teaser. Esto es mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

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

arybczak en 17 dic. 2020

❤10 🎉6 👍6 👀2

@arybczak ¡Impresionante! Debería publicar esto en https://discourse.mopidy.com/c/show-and-tell/9

jodal en 19 dic. 2020

👍2

@adamcik ¿No significa esto que este problema de casi 7 años está "desaprobado" a favor de una mejor resolución del problema del mundo real que lo provocó (soporte de visualizaciones en ncmpcpp)?