Mopidy: Considere adicionar um coletor fifo gstreamer

Criado em 8 jul. 2014  ·  73Comentários  ·  Fonte: mopidy/mopidy

Isso continua surgindo, pois as pessoas realmente parecem gostar do visualizador do ncmpcpp

O truque para fazer um coletor FIFO confiável é duplo. Você precisa usar gravações sem bloqueio, o que significa que a abertura do soquete de gravação falhará, a menos que haja um leitor, portanto, você também precisa de um leitor. Em segundo lugar, se o buffer ficar cheio porque o leitor externo fica para trás ou não há nenhum, o leitor interno precisa limpar o buffer.

O código a seguir captura a essência disso, mas ainda precisa de mais algum trabalho com relação ao tratamento de erros.

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

O código acima agora precisa ser integrado ao GStreamer para realmente fazer isso. Supondo que 0,10 isso seja realmente muito viável, estou hesitante porque estamos planejando uma mudança para 1.xe a ligação gir não é adequada para fazer elementos em python. No caso deste código em 1.x, o problema se resume a não ser capaz de criar os modelos de pad que a BaseSink espera encontrar. Criar isso como um elemento simples pode ser viável, mas você precisaria reimplementar muito do tratamento que BaseSink garante que você acertou.

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)

Observe que um problema que encontrei ao testar isso foi esquecer de corresponder ao formato de áudio esperado pelo ncmpcpp, portanto, certifique-se de que mono / estéreo realmente correspondam.

C-enhancement A-audio
Fonte
picture adamcik
👍8

Comentários muito úteis

Para sua informação, adicionei suporte para udpsink do gstreamer ao ncmpcpp, então agora ele pode ser usado diretamente sem hacks de fifo.

Consulte https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 para obter mais detalhes.

Abaixo de um teaser. Este é mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

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

picture arybczak em 17 dez. 2020
❤10 🎉6 👍6 👀2

Todos 73 comentários

Para onde foi isso? isso será adicionado ao pacote principal?

CestDiego picture CestDiego em 6 out. 2014

Isso não está sendo trabalhado, pois precisaríamos convertê-lo para GStreamer 1.0, e todos os meus experimentos com isso até agora descobriram problemas ao fazer elementos personalizados em python. Existem outras maneiras de talvez resolver tudo, mas não algo que eu tenha tempo para trabalhar.

adamcik picture adamcik em 11 out. 2014

Eu gostaria de ver o suporte FIFO adicionado :)

johnhamelink picture johnhamelink em 6 nov. 2014

Eu acabei de encontrar isso procurando uma maneira de fazer o visualizador de música do ncmpcpp funcionar com o mopidy. Eu sou a favor

proxa picture proxa em 6 nov. 2014

Sim, é o mesmo motivo pelo qual encontrei isso. Seria muito bom
ser capaz de visualizar música transmitida,

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

Acabei de encontrar uma maneira de fazer o visualizador de música do ncmpcpp
trabalhar com mopidy. Eu sou a favor

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

CestDiego picture CestDiego em 6 nov. 2014

Existem plug-ins de visualização do gstreamer, você não pode simplesmente usá-los?
Em 6 de novembro de 2014 08:35, "Diego Berrocal" [email protected] escreveu:

Sim, é o mesmo motivo pelo qual encontrei isso. Seria muito bom
ser capaz de visualizar música transmitida,

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

Acabei de encontrar isso procurando uma maneira de obter o visualizador de música do ncmpcpp
para
trabalhar com mopidy. Eu sou a favor

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -62007426.

kingosticks picture kingosticks em 6 nov. 2014

Observe que eles serão eliminados na próxima versão.

adamcik picture adamcik em 6 nov. 2014

Alguém está trabalhando nisso? Seria muito bom poder usar o visualizador ncmpcpp com mopidy.

andreasboden picture andreasboden em 13 fev. 2015

Não que eu saiba, e provavelmente não queremos fazer isso como um elemento do GStreamer, pois isso bloquearia nossa migração para o GStreamer 1.x.

adamcik picture adamcik em 14 fev. 2015

Este é IMO também bloqueado na adição de suporte adequado para saídas.

adamcik picture adamcik em 25 fev. 2015

Apenas acrescentando que também me deparei com esse problema ao tentar adicionar suporte ao visualizador para Mopidy / ncmpcpp. Adoraria ter isso no futuro, mesmo que não esteja sendo trabalhado atualmente. Eu também gostaria de estender meu maior respeito por aqueles que contribuem com seu tempo para projetos de código aberto. :sorriso:

codeurge picture codeurge em 15 abr. 2015

Idealmente, isso funcionaria remotamente. O poder da Mopidy está realmente em ser uma solução que pode estar em sua nuvem privada.

wernight picture wernight em 27 abr. 2015

Em geral, os FIFOs não são um método muito portátil de comunicações entre processos e devem ser evitados por IMO. Eles também têm alguns efeitos colaterais desagradáveis, já mencionados neste tópico. Eu acho que é melhor você despejar seus pacotes usando um coletor de UDP pessoalmente .... essa é uma solução mais genérica e pode ser facilmente adaptada para algo que grava em um FIFO (se necessário) fora do Mopidy .... é um único linha de script de shell para ler dados de uma porta UDP (usando netcat) e gravá-los em um FIFO.

liamw9534 picture liamw9534 em 27 abr. 2015

Isso soa bem. Pode ser que os clientes mentem, o ncmpcpp também permitiria usar isso como entrada.

Outra ideia é usar o PulseAudio diretamente, pois não exigiria nenhuma implementação extra do lado do Mopidy. O contêiner Docker que fiz usa TCP para acessar o PulseAudio pela rede. ncmpcpp poderia realmente usar isso diretamente.

wernight picture wernight em 27 abr. 2015

Pelo que li, o visualizador está apenas executando um FFT em blocos de amostras que são lidos de um arquivo FIFO. O que estou defendendo é que você pode criar um FIFO fora do Mopidy usando mkfifo e então ler os dados UDP do Mopidy usando netcat e redirecionar a saída de netcat para o Arquivo FIFO. Portanto, nada precisa mudar no que diz respeito a ncmpcpp , ele apenas lê o arquivo FIFO.

Para alcançar o que você deseja no Mopidy, não é necessário nenhum esforço de implementação, pois você pode alterar a propriedade de saída de áudio para gerar um elemento udpsink GStreamer. O mais provável é que você queira organizá-lo como parte de um "tee" que produz tanto o coletor ALSA / Pulse quanto o udpsink.

liamw9534 picture liamw9534 em 28 abr. 2015

O seguinte deve funcionar ... não testado, então pode precisar de alguns ajustes.

Na configuração de áudio Mopidy:

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

Em seu host Linux, inicie o netcat para ouvir no localhost os dados UDP na porta 5555 e enviar as amostras para o FIFO:

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

Em seu mpd.conf:

audio_output {
    type                    "fifo"
    name                    "my_fifo"
    path                    "/tmp/mopidy.fifo"
    format                  "44100:16:2"
}
liamw9534 picture liamw9534 em 28 abr. 2015

Nota: Se você estiver usando uma saída PulseAudio, pode ser possível fazer algo semelhante com seu módulo de conexão de direção TCP. No entanto, você pode precisar fazer a engenharia reversa de qualquer protocolo executado por cima da conexão TCP, por exemplo, pode não ser possível tratá-lo como um coletor bruto.

liamw9534 picture liamw9534 em 28 abr. 2015

Obrigado @ liamw9534 por compartilhar. Eu teria demorado um pouco para entender a configuração o suficiente para fazer isso ou mesmo saber que eu poderia. Vou tentar adicionar isso ao contêiner do

wernight picture wernight em 28 abr. 2015

Isso pode gerar problemas se você não tiver algo esvaziando o fifo. Como o netcat irá preencher o buffer do kernel e então falhar. E dependendo de como o FIFO é aberto, você também pode ter problemas, pois os FIFOs podem exigir que um leitor esteja presente para ser gravável: /

adamcik picture adamcik em 28 abr. 2015

Mas você poderia adaptar meu código FifoStreamer para aceitar os dados UDP e lidar com isso para você, pois espero que já tenha resolvido a maioria dos casos de erro que você pode encontrar lá.

adamcik picture adamcik em 28 abr. 2015

@adamcik Se você tiver um script de trabalho, ficaria feliz em incluí-lo como parte do docker-ncmpcpp para as pessoas usarem. Eu também alteraria docker-mopidy para transmitir em UDP por padrão usando o truque de saída acima.

wernight picture wernight em 29 abr. 2015

Fiz alguns experimentos básicos na linha de comando e tudo funciona bem, desde que você use um tempo limite de conexão, por exemplo, nc -kluw 1 127.0.0.1 5555 > /tmp/mopidy.fifo . Isso força o netcat a sempre escutar uma nova conexão de porta de origem após a última conexão cair (tempo limite de 1s).

O comando acima funciona independentemente de haver ou não alguma leitura do arquivo FIFO e também funciona se o processo de leitura do arquivo FIFO parar e fechar o arquivo.

liamw9534 picture liamw9534 em 29 abr. 2015

@wernight veja a descrição desse bug, esse é todo o código que tenho.

adamcik picture adamcik em 29 abr. 2015

E apenas para cintos e chaves, eu colocaria o comando em um loop while, por exemplo, while :; do nc -kluw 1 127.0.0.1 5555> /tmp/mopidy.fifo; sleep 1; done - se ele sair, ele será iniciado novamente após 1 segundo de atraso.

liamw9534 picture liamw9534 em 29 abr. 2015

@ liamw9534 Você tem um mpd.conf aí. Eu estou confusa com isso. Você está executando um servidor MPD independente além do mopidy-mpd?

lrvick picture lrvick em 2 mai. 2015

@lrvick sim, meu erro, claro que estava pensando sobre a configuração que precisa ser adicionada a ~ / .ncmpcpp / config

liamw9534 picture liamw9534 em 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

(adicionado -p aqui).

~/.ncmpcpp/config

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

(feito também em wernight / docker-mopidy e wernight / docker-ncmpcpp )

No entanto, parece que ele não pode se conectar ao 5555, embora o log do Mopidy mostre que ele entendeu a configuração output . netstat também não mostra nenhum UDP aberto no 5555. Não entendo totalmente a linha output : tee é um comando bash, o resto se parece com coisas Mopidy.

No entanto, encontrei udp6 [::]:51307 enquanto reproduzia música.

wernight picture wernight em 8 mai. 2015

O output é interpretado como um elemento GstBin que é passado para playbin2 como parte do Mopidy - por baixo do capô, este é apenas um pipeline do Gstreamer, nada de especial. O tee é na verdade, portanto, um elemento Gstreamer. Não tem nada a ver com o comando shell tee .

Assim, você pode aproximar o que está acontecendo dentro do Mopidy na linha de comando fazendo algo como:

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

Isso começará a tocar um tom sinusoidal. Em seguida, execute o seguinte comando:

nc -kluw 1 127.0.0.1 5555

Posso então começar a ver muitos caracteres estranhos em minha tela ... este é o fluxo de áudio de teste saindo para saída padrão de nc . Isso prova efetivamente que a abordagem subjacente funciona. Você pode confirmar que pode replicar o mesmo comportamento?

Você pode então tentar adicionar o FIFO em uma segunda etapa e confirmar se pode cat o FIFO para stdout e ver os mesmos caracteres estranhos.

liamw9534 picture liamw9534 em 8 mai. 2015

Eu também checaria o formato de configuração necessário para ncmpcpp . Dei uma olhada rápida em https://wiki.archlinux.org/index.php/Ncmpcpp#Enabling_visualization e posso ver que talvez o formato de configuração necessário seja diferente, por exemplo,

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

Eu não uso ncmpcpp , então o problema pode estar aqui também ...

liamw9534 picture liamw9534 em 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

(com nc ... -p senão recebo um erro)

Eu ouço o tom sendo reproduzido.

wernight picture wernight em 11 mai. 2015

Qual distro você está usando? Além disso, quando você digita nc -h qual é a saída?

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

A opção -p não é necessária com o nc que estou usando no Ubuntu. A página do manual também indica que deve ser um erro especificar -p em conjunto com -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 picture liamw9534 em 11 mai. 2015

Usando o Debian Wheezy.

Aqui estão as etapas completas para o Ubuntu começando com a instalação do Docker :

  1. Instale o Docker :

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

  1. Habilitar PulseAudio remoto
  2. Executar no 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 picture wernight em 11 mai. 2015

Tentei com netcat-openbsd pacote que dá:

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

Agora nc simplesmente não mostra nada enquanto o tom está tocando (o que parece um pouco melhor):

$ nc -kluw 1 127.0.0.1 5555
(nothing here)
wernight picture wernight em 11 mai. 2015

Ok, abra dois terminais e no primeiro terminal execute:

nc -kluw 1 127.0.0.1 5555

Então, no segundo terminal, execute:

nc -u 127.0.0.1 5555

Insira alguns caracteres em stdin no segundo terminal e pressione ENTER. Você vê os mesmos caracteres aparecerem no primeiro terminal em stdout?

liamw9534 picture liamw9534 em 11 mai. 2015

Sim, isso funciona. Até consegui funcionar entre os 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

Portanto, isso não explica por que nc não mostrou nada com gst-launch . No entanto, descobri que precisaria definir host=SOMETHING para que funcione em todos os contêineres. Isso será problemático. Parece que não pode transmitir. Mas isso é algo que poderei resolver quando funcionar pelo menos em um único contêiner.

wernight picture wernight em 11 mai. 2015

Aha! Se eu definir host=0.0.0.0 , funciona!

wernight picture wernight em 11 mai. 2015
👍2

Você precisa enviar os dados pela rede? Achei que você só precisava dos pacotes na máquina local. Usar udpsink host=0.0.0.0 port=5555 transmitirá pacotes para todos os lugares da sua rede. Provavelmente não é o que você quer ...

Você deve ser capaz de dizer host=127.0.0.1 vez de restringir os pacotes ao loopback local.

Suspeito que o verdadeiro problema seja, portanto, a configuração de roteamento padrão. Por padrão, em seu sistema, os pacotes de saída são canalizados para uma interface diferente. Possivelmente versões diferentes do elemento gstreamer ou diferenças na configuração de roteamento de IP.

liamw9534 picture liamw9534 em 11 mai. 2015

Do container tive que usar 0.0.0.0 ou possível o IP da máquina. A configuração padrão não estava funcionando mesmo em uma única máquina / contêiner.

Mas sim, tenho que usar a rede agora porque é uma boa prática manter ncmpcpp e mopidy em contêineres Docker separados, o que significa que eles estão em redes diferentes. Isso é muito bom para segurança e isolamento e tal, mas cria um pouco de problema:

O cliente ncmpcpp se conecta ao servidor MPD para solicitar streaming de música e, somente depois desse ponto, o IP do ncmpcpp é conhecido e o pacote UDP deve ser transmitido para seu IP; mas atualmente o IP está codificado na configuração Mopidy.

Não tenho uma solução agora. Estou pensando em soluções:

  • Criando o FIFO no Mopidy e compartilhando com o ncmpcpp, mas temo que nada irá limpar o FIFO e isso é um grande problema. Além disso, o compartilhamento de arquivos não é tão simples quanto os soquetes de rede.
  • Daemon local monitorando conexões e encaminhando o tráfego UDP para o IP do cliente encontrado; hack.
  • Túnel UDP SSH , mas isso é complexo, adiciona criptografia inútil, adiciona outro daemon ... ruim!
  • Olhando o código para ver se o host udpsink pode ser padronizado para o IP do primeiro cliente ou ainda melhor para todos os IPs dos clientes conectados
  • Diga ao Docker para compartilhar o host por meio de --net=container:NAME_or_ID que adiciona outro parâmetro para os usuários digitarem, mas isso simplificaria muito!

Existem soluções para essa dependência circular. Ainda parece um hack horrível, mas deve ser fácil o suficiente para os usuários usarem no final. Obrigado liamw9534 por ajudar especialmente com os comandos nc que eu era estranho.

wernight picture wernight em 12 mai. 2015

O FIFO está funcionando, exceto que There is no output named "my_fifo"! . Parece que o nome deve corresponder ao de mdp.conf :

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

Posso tentar compartilhar o arquivo FIFO se souber como adicionar essa saída de áudio ao Mopidy. náuseas (um visualizador simples) parecem ter os mesmos requisitos.

Encontrei esta documentação de visualizer_output_name :

  • O parâmetro abaixo é necessário para ncmpcpp para determinar qual saída fornece dados para o visualizador e, assim, permitir a sincronização entre a visualização e o som, pois atualmente existem alguns problemas com isso.
  • saída fifo, cujo parâmetro de formato deve ser definido como 44100: 16: 1 para visualização mono ou 44100: 16: 2 para visualização estéreo
wernight picture wernight em 12 mai. 2015

Não tenho certeza do que você quer dizer com "em redes diferentes". Se você deseja isolar o tráfego de áudio para a máquina local, você deve usar 127.0.0.1 para udpsink . Se você escolher 0.0.0.0 , os pacotes serão direcionados usando a rota padrão, o que provavelmente significa o envio de pacotes UDP pela rede ... em geral, diria que é uma má ideia porque o tráfego da rede consumirá um muita largura de banda, ou seja, 2 x 16 x 44100 = 1,41 Mbps.

Em teoria, deveria ser possível configurar nc com 0.0.0.0 independentemente de qual interface de rede é usada por udpsink . Isso ouvirá em todas as interfaces de rede. Tudo bem, desde que você não use o mesmo número de porta IP para outros serviços em interfaces de rede diferentes.

liamw9534 picture liamw9534 em 12 mai. 2015

Usei minha última sugestão e coloquei os dois na mesma rede. Essas redes são locais de qualquer maneira, é apenas uma separação lógica. Isso funciona para construir o FIFO, apenas ncmpcpp não o quer (veja minha resposta anterior, 2 acima).

wernight picture wernight em 12 mai. 2015

Alguma ideia sobre o nome do canal? Ou se houver outra maneira de fazer um FIFO como mpd.conf ? Não parece funcionar sem.

wernight picture wernight em 13 mai. 2015

Achei que mpd.conf fosse usado apenas para a configuração do daemon MPD. Nesse caso, isso deve ser redundante porque mopidy é o daemon MPD e seu docker está criando o arquivo FIFO. Nesse caso, a única coisa que deve ser necessária é garantir que .ncmpcpp/config corresponda ao cliente, certo?

liamw9534 picture liamw9534 em 13 mai. 2015

Tipo de. O que exatamente está fazendo, não sei. Mas como você pode ver, visualizer_output_name = "my_fifo" deve corresponder a audio_output { name "my_fifo" } . Atualmente o ncmpcpp mostra There is no output named "my_fifo" . A descrição de visualizer_output_name está apenas 5 postagens acima. Parece que ele está se conectando diretamente de alguma forma à saída para sincronizar.

wernight picture wernight em 13 mai. 2015

Eu não uso nada disso, mas me parece que visualizer_output_name deve corresponder a uma de suas saídas MPD (protocolo, não programa) (ou seja, algo em mpc outputs ). Atualmente, o Mopidy não permite saídas configuráveis ​​e possui apenas uma saída MPD: "Mudo".

Você provavelmente deseja remover visualizer_output_name , se possível.

kingosticks picture kingosticks em 13 mai. 2015

Tentei não configurá-lo. Ainda não há visualizador visível. Eu me pergunto sobre o formato de saída de udpsink : deve ser 44100:16:2 para os visualizadores funcionarem ( ncmpcpp ou nausea ).

Tentei Mute por precaução, tive uma experiência muito engraçada: apenas silenciava o som, sem mostrar um erro, mas também sem mostrar os visualizadores. Ou, mais exatamente, desabilitou a saída Mute .

wernight picture wernight em 13 mai. 2015

Eu me pergunto onde a função FFT é executada para o visualizador.
É executado na saída do FIFO ou na entrada do FIFO? Você
precisaria verificar o código do cliente MPD para ver como ele lida com os dados FIFO.

liamw9534 picture liamw9534 em 13 mai. 2015

Existe uma maneira de oferecer suporte, apenas para teste, mesmo que normalmente criaria um arquivo monstruosamente grande.

wernight picture wernight em 13 mai. 2015

Você também não precisa de suporte. Você precisa descobrir onde está o FFT
deve ser feito e, em seguida, escolha a abordagem correta. Se o FFT for
feito no visualizador, seria apenas um desperdício de esforço completo
implementá-lo novamente.

Em 13 de maio de 2015 às 15h09, Werner Beroux [email protected] escreveu:

Existe uma maneira de oferecer suporte, apenas para teste, mesmo que fosse
normalmente cria um arquivo monstruosamente grande.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101676033.

liamw9534 picture liamw9534 em 13 mai. 2015

A FFT é feita pelo visualizador e requer o formato de áudio específico no FIFO para funcionar. Referência: http://git.2f30.org/nausea/about/

wernight picture wernight em 13 mai. 2015

Bom - então não há razão para não funcionar! Você fez um
comparação lado a lado de um sistema executando um daemon MPD padrão com um
cliente ncmpcpp local? O que acontece se você renomear o nome do arquivo FIFO em ambos
os arquivos de configuração? Ainda funciona? Apenas tentando ver se um
caminho codificado existe em algum lugar ...

Em 13 de maio de 2015 às 15:57, Werner Beroux [email protected] escreveu:

FFT é feito pelo visualizador e requer o formato de áudio específico
no FIFO para trabalhar para isso. Referência: http://git.2f30.org/nausea/about/

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101702624.

liamw9534 picture liamw9534 em 13 mai. 2015

Meu comentário foi baseado na fonte ncmpcpp .

A saída Mute do Mopidy é desabilitada por padrão, ou seja, o áudio não é silenciado. O visualizador ncmpcpp pegará a saída que você forneceu, desabilitará (sem efeito) e então habilitará, silenciando assim o áudio. Provavelmente, eles deveriam apenas alternar duas vezes.

O áudio estar no formato errado é uma boa possibilidade. Você não tem nada no pipeline do gstreamer para garantir que está correto, ao contrário do que @adamcik tinha no código acima.

kingosticks picture kingosticks em 13 mai. 2015

É difícil ver como o formato pode ser um problema ... é assinado em 16 bits
inteiros. O pior que poderia acontecer é você trocar os canais L / R?

Em 13 de maio de 2015 às 16:33, Nick Steel [email protected] escreveu:

Meu comentário foi baseado na fonte ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.

A saída Mute do Mopidy é desabilitada por padrão, ou seja, o áudio não é silenciado.
O visualizador ncmpcpp pegará a saída que você forneceu, desabilite-a (não
) e, em seguida, habilite-o, silenciando o áudio. Provavelmente eles deveriam
basta alternar duas vezes.

O áudio estar no formato errado é uma boa possibilidade. Você tem
nada no pipeline do gstreamer para garantir que esteja correto, ao contrário do @adamcik
https://github.com/adamcik tinha em seu código acima.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

liamw9534 picture liamw9534 em 13 mai. 2015

E mesmo que a ordem de bytes esteja errada, você pode esperar que o FFT
saída para gerar a resposta de frequência errada ... mas você ainda verá
algo.

Em 13 de maio de 2015 às 16:37, Liam Wickins [email protected] escreveu:

É difícil ver como o formato pode ser um problema ... é assinado em 16 bits
inteiros. O pior que poderia acontecer é você trocar os canais L / R?

Em 13 de maio de 2015 às 16:33, Nick Steel [email protected] escreveu:

Meu comentário foi baseado na fonte ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.

A saída Mute do Mopidy é desabilitada por padrão, ou seja, o áudio não é silenciado.
O visualizador ncmpcpp pegará a saída que você forneceu, desabilite-a (não
) e, em seguida, habilite-o, silenciando o áudio. Provavelmente eles deveriam
basta alternar duas vezes.

O áudio estar no formato errado é uma boa possibilidade. Você tem
nada no pipeline do gstreamer para garantir que esteja correto, ao contrário
@adamcik https://github.com/adamcik tinha em seu código acima.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

liamw9534 picture liamw9534 em 13 mai. 2015

Sim, é verdade, talvez seja porque deixar a saída Mute do Mopidy habilitada significa que o udpsink não enviará nenhum dado.

kingosticks picture kingosticks em 13 mai. 2015

cat /tmp/mdp.fifo (criado a partir do UDP como acima) mostra corretamente o fluxo constante de dados.

Eu olhei para o código ncmpcpp do visualizador:

  1. abre o arquivo como O_RDONLY | O_NONBLOCK
  2. lê de cima ; dado que está definido para estéreo na minha configuração mopidy, deve ser 44100: 16: 2.

Qualquer um também pode tentar no meu branch (depois de instalar o 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 picture wernight em 18 mai. 2015

Tive que passar algum tempo lutando contra o netcat, pois -k não funcionava para mim, mas aqui está o que eu criei para reiniciá-lo automaticamente nos interruptores de música:

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

outras opções, como acima, basicamente.

s-ol picture s-ol em 28 dez. 2015

@ S0lll0s @wernight netcat -k também não funcionou para mim e teve que ser reiniciado após as mudanças de música. Enquanto sua solução funciona, descobri que o socat funciona melhor:

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

SjRNMzU picture SjRNMzU em 6 fev. 2016
❤3

Para usuários do Arch Linux:

Para obter nc com suporte -k você precisa instalar o pacote openbsd-netcat , mas também não funcionou para mim, então tente usar o script de @SjRNMzU - você precisa o pacote socat para executá-lo.

johnhamelink picture johnhamelink em 3 set. 2016
❤1

@johnhamelink (presumo que você esteja executando o Arch a partir de seu comentário) Você teve problemas com o visualizador tentando "recuperar o atraso" depois de pausar uma música usando a solução socat ?

tmb picture tmb em 4 jun. 2017

@ theos-space não posso dizer que percebi isso

johnhamelink picture johnhamelink em 5 jun. 2017

Estou no Arch e não consigo fazê-lo funcionar com nc (ambos gnu e openbsd ) ou socat . Além disso, não consigo ler gst-launch-1.0 ... udpsink port=5555 com nc -kluw 1 127.0.0.1 5555 , pois não imprime nada na tela.

ranisalt picture ranisalt em 6 jun. 2017
👍1

Pode confirmar que isso funciona no 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:

inicie o socat na inicialização do 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 (observe que o host deve ser definido para udpsink):

[audio]
output = tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink host=127.0.0.1 port=5555
laur89 picture laur89 em 27 ago. 2017

ranisalt para Arch, você deve compilar ncmpcpp com suporte fifo, verifique aqui: https://bbs.archlinux.org/viewtopic.php?id=99915

r1ft4469 picture r1ft4469 em 30 set. 2017

Aqui está minha configuração de trabalho do Arch, depois de ler o resto do tópico + docs + manpages + blogs diversos. Estou executando o Mopidy como serviço do sistema e enviando o áudio para o serviço de usuário do PulseAudio via TCP. Incluí algumas anotações adicionais que, com sorte, ajudarão os menos experientes.

Pacotes

Todos estes são dos repositórios oficiais do 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

Configurar

Ative o serviço do sistema mopidy:

sudo systemctl enable mopidy.service

Substitua a configuração do sistema do mopidy por um link simbólico para a configuração do usuário para facilitar a edição (opcional):

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

Crie o arquivo fifo:

mkfifo "/tmp/mpd.fifo"

Configs

em ~/.config/mopidy/mopidy.conf (ou /etc/mopidy/mopidy.conf se você não criou o link simbólico): Diga ao mopidy para enviar áudio para um servidor pulseaudio ouvindo em localhost e para um coletor UDP em localhost: 5555

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

em ~/.ncmpcpp/config : diga ao ncmpcpp onde encontrar o arquivo fifo que ele precisa ouvir e algumas outras configurações diversas

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

em ~/.config/pulse/default.pa : Diga a pulseaudio para aceitar áudio sobre TCP do host local (a configuração provavelmente já está lá e pode ser descomentada)

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

em ~/.zshrc (também deve funcionar em ~/.bashrc ): Crie uma função wrapper "nplayer" para iniciar e parar netcat com ncmpcpp :

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

O que isso faz:

  • define uma função com um subshell envolvendo todo o seu conteúdo
  • inicie um processo netcat em segundo plano para ouvir os dados de áudio enviados ao coletor UDP e redirecioná-los para o fifo criado anteriormente. Bandeiras:

    • -k continue ouvindo depois que a conexão atual for concluída

    • -l ativar o modo de escuta

    • -u ativar o modo UDP

    • -w NUM tempo limite de conexões inativas após NUM segundos (1 segundo neste caso)

  • defina uma armadilha EXIT para matar o processo netcat quando o processo ncmpcpp terminar e fizer com que o subshell da função saia
  • iniciar um processo ncmpcpp em primeiro plano
mosbasik picture mosbasik em 27 nov. 2017
👍16 ❤1

Estou executando mopidy em Manjaro (distro de arco). Eu estava tendo problemas para obter qualquer saída por meio de socat ou netcat. Eu fui capaz de observar os pacotes que chegam com tcpdump embora:
sudo tcpdump -i lo -n udp port 5555 -XX

Demorei muito e não teria encontrado o problema sem o @mosbasik .
O problema era não ter host=127.0.0.1 após o udpsink, por que isso funciona para outras pessoas e não para mim, eu não sei. Mas se você não estiver obtendo nenhuma saída, é possível que seja esse o caso. Estes 2 funcionaram para mim:

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

ou

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

Em uma nota lateral: eu não consegui fazer pulsesink funcionar, então tive que deixá-lo em autoaudiosink , que é o que eu tinha definido também antes. No entanto, o visualizador parece estar realmente muito lento por algum motivo, não tenho certeza se é por causa de autoaudiosink Funciona perfeitamente após uma reinicialização .. ainda um pouco lento. Com o pulselink, ele reclamava dos plugins do gstreamer. Mesmo depois (presumo) de ter instalado todos os pacotes de plug-ins para gst nos repositórios oficiais do Arch. Nota flump3dec e mad


Resultado 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 picture ducklin5 em 14 dez. 2018
👍3

Estou tendo um problema ao tentar fazer o udpsink funcionar com o Mopidy e todos os clientes ncmpcpp remotos. Mopidy é configurado com MacVLAN em um ambiente docker. Posso ver com sucesso a porta no contêiner.

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!

Atualmente, Mopidy está usando o seguinte bit de configuração:

[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

Alguma ideia de como posso usar o netcat para obter com êxito os dados brutos em mpd.fifo? Usar o seguinte não funciona, acho que estou usando o netcat da maneira errada. Algumas pesquisas não forneceram nenhuma resposta, então espero que alguém possa me apontar a direção certa.

#!/bin/bash

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

Estou tendo o erro a seguir:

nc: Can't assign requested address

Alguma ideia de como posso fazer isso funcionar?

Felicidades!

80scyborgninja picture 80scyborgninja em 1 mar. 2019

Para sua informação, adicionei suporte para udpsink do gstreamer ao ncmpcpp, então agora ele pode ser usado diretamente sem hacks de fifo.

Consulte https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 para obter mais detalhes.

Abaixo de um teaser. Este é mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

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

arybczak picture arybczak em 17 dez. 2020
❤10 🎉6 👍6 👀2

@arybczak Incrível! Você deve postar isso em https://discourse.mopidy.com/c/show-and-tell/9

jodal picture jodal em 19 dez. 2020
👍2

@adamcik Isso não significa que este problema de quase 7 anos está "obsoleto" em favor de uma melhor resolução para o problema do mundo real que o gerou (suporte a visualizações em ncmpcpp)?

pspeder picture pspeder em 12 fev. 2021

@pspeder , o que exatamente você quer dizer? Existe um problema ao usar https://github.com/mopidy/mopidy/issues/775#issuecomment -747725806?

kingosticks picture kingosticks em 12 fev. 2021

@kingosticks estava simplesmente sugerindo que este problema fosse encerrado 🙂

pspeder picture pspeder em 13 fev. 2021

Eu concordo com isso.

kingosticks picture kingosticks em 13 fev. 2021
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

djselbeck picture djselbeck  ·  8Comentários
mczerski picture mczerski  ·  9Comentários
jcass77 picture jcass77  ·  10Comentários
voidmann picture voidmann  ·  11Comentários
altano picture altano  ·  6Comentários