Mopidy: Посмотрите на добавление раковины GSTREAMER FIFO

Созданный на 8 июл. 2014  ·  73Комментарии  ·  Источник: mopidy/mopidy

Это продолжает появляться, поскольку людям действительно нравится визуализатор ncmpcpp.

Уловка для создания надежного приемника FIFO двоякая. Вам нужно использовать неблокирующую запись, что означает, что открытие сокета записи не удастся, если нет считывателя, поэтому вам также понадобится считыватель. Во-вторых, если буфер заполняется из-за того, что внешний считыватель отстает или отсутствует, вашему внутреннему считывателю необходимо очистить буфер.

Следующий код отражает основную суть этого, но все же требует дополнительной работы в отношении обработки ошибок.

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 

Приведенный выше код теперь необходимо интегрировать с GStreamer. Предполагая, что 0.10 это на самом деле очень выполнимо, я сомневаюсь, что мы планируем переход на 1.x, а привязка gir не подходит для создания элементов в python. В случае этого кода в 1.x проблема сводится к невозможности создания шаблонов пэдов, которые BaseSink ожидает найти. Создание этого в виде простого элемента может быть выполнимым, но вам нужно будет заново реализовать способ обработки, основанный на BaseSink, чтобы убедиться, что вы все делаете правильно.

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) 

Обратите внимание, что одна проблема, с которой я столкнулся при тестировании, заключалась в том, что на самом деле я забыл соответствовать аудиоформату, ожидаемому ncmpcpp, поэтому убедитесь, что моно / стерео действительно совпадают.

C-enhancement A-audio

Самый полезный комментарий

К вашему сведению, я добавил поддержку udpsink gstreamer в ncmpcpp, так что теперь его можно использовать напрямую, без хаков с помощью FIFO.

Подробнее см. Https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 .

Ниже тизер. Это mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

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

Все 73 Комментарий

Куда это делось? это будет добавлено в основной пакет?

Над этим не работают, так как нам нужно было бы преобразовать его в GStreamer 1.0, и все мои эксперименты с этим пока не выявили проблем при создании пользовательских элементов в python. Есть и другие способы решить все это, но у меня нет времени над этим работать.

Хочу добавить поддержку FIFO :)

Я только что нашел это в поисках способа заставить музыкальный визуализатор ncmpcpp работать с mopidy. Я за.

Да, это та же самая причина, по которой я нашел это. Было бы здорово
уметь визуализировать потоковое воспроизведение музыки,

2014-11-06 2:19 GMT-05: 00 Блейк [email protected] :

Я только что нашел это в поисках способа получить музыкальный визуализатор ncmpcpp в
работа с мопидами. Я за.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

Существуют плагины визуализации gstreamer, можете ли вы просто их не использовать?
6 ноября 2014 г. в 08:35 "Диего Беррокаль" [email protected] написал:

Да, это та же самая причина, по которой я нашел это. Было бы здорово
уметь визуализировать потоковое воспроизведение музыки,

2014-11-06 2:19 GMT-05: 00 Блейк [email protected] :

Я только что нашел это в поисках способа получить музыкальный визуализатор ncmpcpp
к
работа с мопидами. Я за.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -62007426.

Обратите внимание, что они скоро исчезнут в следующем выпуске.

Кто-нибудь над этим работает? Было бы здорово иметь возможность использовать визуализатор ncmpcpp с mopidy.

Не то, чтобы я знал об этом, и мы, вероятно, не хотим делать это как элемент GStreamer, так как это заблокирует нашу миграцию на GStreamer 1.x.

Это ИМО также заблокировано при добавлении правильной поддержки для выходов.

Просто добавлю, что я также столкнулся с этой проблемой при попытке добавить поддержку визуализатора в Mopidy / ncmpcpp. Хотелось бы иметь это в будущем, даже если в настоящее время над этим не работают. Я также хотел бы выразить свое глубокое уважение тем, кто вкладывает свое время в проекты с открытым исходным кодом. :улыбка:

В идеале это работало бы удаленно. Сила Mopidy на самом деле заключается в том, чтобы быть решением, которое может быть в вашем частном облаке.

В общем, FIFO - не очень переносимый метод межпроцессного взаимодействия, и его следует избегать IMO. У них также есть неприятные побочные эффекты, о которых уже упоминалось в этой ветке. Я думаю, вам лучше выгружать свои пакеты с помощью приемника UDP лично ... это более общее решение, и его можно легко адаптировать к чему-то, что записывает в FIFO (при необходимости) за пределами Mopidy ... это единственный строка сценария оболочки для чтения данных из порта UDP (с помощью netcat) и записи их в FIFO.

Это звучит неплохо. Возможно, клиенты лгут, что ncmpcpp также позволит использовать это в качестве входных данных.

Другая идея - использовать PulseAudio напрямую, поскольку это не потребует дополнительной реализации на стороне Mopidy. Созданный мной контейнер Docker использует TCP для доступа к PulseAudio по сети. ncmpcpp может использовать это напрямую.

Из того, что я читал, визуализатор просто выполняет БПФ для блоков выборок, которые считываются из файла FIFO. Я хочу сказать, что вы можете создать FIFO вне Mopidy, используя mkfifo а затем прочитать данные UDP из Mopidy, используя netcat и перенаправить вывод из netcat в FIFO файл. Таким образом, ничего не нужно менять в том, что касается ncmpcpp , он просто читает файл FIFO.

Для достижения цели Mopidy не требуется никаких усилий по реализации, поскольку вы можете изменить свойство вывода звука на вывод в элемент udpsink GStreamer. Скорее всего, вы захотите сделать его частью «тройника», который выводит как на ваш приемник ALSA / Pulse, так и на udpsink.

Следующее должно работать ... не тестировалось, поэтому может потребоваться небольшая настройка.

В аудио конфигурации Mopidy:

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

На вашем хосте Linux запустите netcat, чтобы прослушать на localhost данные UDP через порт 5555 и вывести образцы в FIFO:

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

В вашем mpd.conf:

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

Примечание. Если вы используете выход PulseAudio, возможно, можно будет сделать что-то подобное с его модулем подключения направления TCP. Однако вам может потребоваться реконструировать любой протокол, который он запускает поверх TCP-соединения, например, его нельзя будет рассматривать как необработанный приемник.

Спасибо @ liamw9534 за то, что поделился. Мне потребовалось бы время, чтобы понять конфигурацию достаточно, чтобы сделать это, или даже знать, что я могу. Я попробую добавить это в контейнер Docker, чтобы посмотреть, работает ли он.

Это может вызвать проблемы, если у вас нет чего-то, что очищает fifo. Поскольку netcat заполнит буфер ядра и затем выйдет из строя. И в зависимости от того, как открывается FIFO, вы также можете столкнуться с проблемами, поскольку для FIFO может потребоваться присутствие читателя для записи: /

Но вы можете адаптировать мой код FifoStreamer, чтобы он принимал данные UDP и обрабатывал их за вас, поскольку я, надеюсь, уже обработал большинство случаев ошибок, с которыми вы можете столкнуться там.

@adamcik Если у вас есть рабочий сценарий, я был бы рад включить его как часть docker-ncmpcpp, чтобы люди могли его использовать. Я бы также изменил docker-mopidy на широковещательную передачу по UDP по умолчанию, используя описанный выше трюк с выводом.

Я провел несколько базовых экспериментов в командной строке, и все работает нормально, если вы используете тайм-аут соединения, например, nc -kluw 1 127.0.0.1 5555 > /tmp/mopidy.fifo . Это заставляет netcat всегда прослушивать новое соединение с исходным портом после разрыва последнего соединения (таймаут 1 с).

Вышеупомянутая команда работает независимо от того, читает ли что-либо из файла FIFO, а также работает, если процесс чтения из файла FIFO останавливается и закрывает файл.

@wernight см. описание этой ошибки, это весь код, который у меня есть.

И только для ремней и фигурных скобок я бы вставил команду в цикл while, например, while :; do nc -kluw 1 127.0.0.1 5555> /tmp/mopidy.fifo; sleep 1; done - если он все же завершится, он просто запустится снова после задержки в 1 секунду.

@ liamw9534 У вас есть mpd.conf. Меня это смущает. Вы используете автономный сервер MPD в дополнение к mopidy-mpd?

@lrvick да, моя ошибка, я, конечно, думал о конфигурации, которую нужно добавить в ~ / .ncmpcpp / config

.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

(сюда добавлено -p ).

~/.ncmpcpp/config

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

(сделано также в wernight / docker-mopidy и wernight / docker-ncmpcpp )

Однако кажется, что он не может подключиться к 5555, хотя журнал Mopidy показывает, что он понял конфигурацию output . netstat также не показывает открытого UDP на 5555. Я не совсем понимаю строку output : tee - это команда bash, остальное похоже на материал Mopidy.

Однако я нашел udp6 [::]:51307 во время проигрывания музыки.

output интерпретируется как элемент GstBin который передается playbin2 как часть Mopidy - под капотом это просто конвейер Gstreamer, ничего особенного. Следовательно, tee на самом деле является элементом Gstreamer. Это не имеет ничего общего с командой оболочки tee .

Таким образом, вы можете приблизительно оценить, что происходит внутри Mopidy, в командной строке, выполнив примерно следующее:

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

Начнется воспроизведение синусоидального тона. Затем выполните следующую команду:

nc -kluw 1 127.0.0.1 5555

Затем я могу начать видеть множество странных символов на моем дисплее .... это тестовый аудиопоток, выводимый на стандартный вывод из nc . Это эффективно доказывает, что базовый подход работает. Можете ли вы подтвердить, что можете повторить то же поведение?

Затем вы можете попробовать добавить FIFO в качестве второго шага и подтвердить, что вы можете cat FIFO в стандартный вывод и увидеть те же странные символы.

Я бы также дважды проверил формат конфигурации, необходимый для ncmpcpp . Я бегло просмотрел https://wiki.archlinux.org/index.php/Ncmpcpp#Enhibited_visualization и увидел, что, возможно, необходимый формат конфигурации отличается, например,

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

Я не использую ncmpcpp , так что проблема тоже может быть здесь ...

$ 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

nc ... -p иначе я получаю ошибку)

Хотя я слышу звук.

Какой дистрибутив вы используете? Также, когда вы набираете nc -h что будет на выходе?

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

Параметр -p не требуется с nc я использую в Ubuntu. На странице руководства также подразумевается, что указание -p в сочетании с -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.

Использование Debian Wheezy.

Вот полные шаги для Ubuntu, начиная с установки Docker :

  1. Установите Docker :

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

  1. Включить удаленный PulseAudio
  2. Запустите 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

Пробовал с пакетом netcat-openbsd , который дает:

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

Теперь nc просто ничего не показывает во время воспроизведения тона (что кажется несколько лучше):

$ nc -kluw 1 127.0.0.1 5555
(nothing here)

Хорошо, откройте два терминала и в первом терминале запустите:

nc -kluw 1 127.0.0.1 5555

Затем во втором терминале запустите:

nc -u 127.0.0.1 5555

Введите несколько символов на стандартный ввод во втором терминале и нажмите ENTER. Вы видите, что те же символы появляются в первом терминале на стандартном выводе?

Да, это работает. Даже получил работающие кросс-докеры:

$ 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

Это не объясняет, почему nc ничего не показал с gst-launch . Однако я обнаружил, что мне нужно установить host=SOMETHING чтобы он работал между контейнерами. Это будет проблематично. Кажется, он не может транслироваться. Но это то, что я могу решить, если он будет работать хотя бы с одним контейнером.

Ага! Если я установлю host=0.0.0.0 это сработает!

Вам нужно отправить данные по сети? Я предполагал, что вам нужны только пакеты на локальной машине. Использование udpsink host=0.0.0.0 port=5555 будет транслировать пакеты повсюду в вашей сети. Наверное, не то, что ты хочешь ...

Вместо этого вы должны иметь возможность сказать host=127.0.0.1 чтобы ограничить пакеты локальной петлей.

Я подозреваю, что реальная проблема заключается в конфигурации маршрутизации по умолчанию. По умолчанию в вашей системе исходящие пакеты направляются на другой интерфейс. Возможны разные версии элемента gstreamer или различия в настройке IP-маршрутизации.

Из контейнера мне пришлось использовать 0.0.0.0 или, возможно, IP-адрес машины. Настройка по умолчанию не работала даже на одной машине / контейнере.

Но да, сейчас мне нужно использовать сеть, потому что рекомендуется хранить ncmpcpp и mopidy в отдельных контейнерах Docker, что означает, что они находятся в разных сетях. Это действительно хорошо для безопасности, изоляции и тому подобного, но создает небольшие проблемы:

Клиент ncmpcpp подключается к серверу MPD, чтобы запросить потоковую передачу музыки, и только после этого становится известен IP-адрес ncmpcpp, и пакет UDP должен транслироваться на его IP-адрес; но в настоящее время IP жестко запрограммирован в конфигурации Mopidy.

У меня сейчас нет решения. Думаю о решениях:

  • Создание FIFO в Mopidy и совместное использование его с ncmpcpp, но я боюсь, что ничто не очистит FIFO, и это большая проблема. Кроме того, совместное использование файлов не так чисто, как сетевые сокеты.
  • Локальный демон отслеживает соединения и перенаправляет UDP-трафик на найденный IP-адрес клиента; взломать.
  • UDP SSH-туннель , но он сложен, добавляет бесполезное шифрование, добавляет еще одного демона ... плохо!
  • Посмотрите на код, чтобы узнать, можно ли по умолчанию использовать хост
  • Скажите Docker, чтобы он предоставил общий доступ к хосту через --net=container:NAME_or_ID который добавляет еще один параметр для ввода пользователями, но это сильно упростит!

Есть решения для этой циклической зависимости. По-прежнему кажется ужасным взломом, но в конечном итоге пользователям должно быть достаточно легко его использовать. Спасибо liamw9534 за помощь, особенно с командами nc которыми я был пришельцем.

FIFO работает, за исключением того, что There is no output named "my_fifo"! . Кажется, что имя должно совпадать с именем в mdp.conf :

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

Я могу попробовать поделиться файлом FIFO, если знаю, как добавить этот аудиовыход в Mopidy. тошнота (простой визуализатор), похоже, имеет те же требования.

Я нашел эту документацию visualizer_output_name :

  • Параметр ниже необходим для ncmpcpp, чтобы определить, какой вывод предоставляет данные для визуализатора и, таким образом, позволяет синхронизировать визуализацию и звук, поскольку в настоящее время с ним возникают некоторые проблемы.
  • Выход FIFO, параметр формата которого должен быть установлен на 44100: 16: 1 для моно-визуализации или 44100: 16: 2 для стереовизуализации.

Я не совсем понимаю, что вы имеете в виду, говоря «в разных сетях». Если вы хотите изолировать аудиотрафик на локальный компьютер, вы должны использовать 127.0.0.1 для udpsink . Если вы выберете 0.0.0.0 тогда он будет направлять пакеты, используя маршрут по умолчанию, что, вероятно, означает отправку пакетов UDP по сети ... в общем, я бы сказал, что это плохая идея, потому что сетевой трафик будет потреблять большая пропускная способность, т.е. 2 x 16 x 44100 = 1,41 Мбит / с.

Теоретически можно настроить nc с помощью 0.0.0.0 независимо от того, какой сетевой интерфейс используется udpsink . Это будет прослушивать все сетевые интерфейсы. Это нормально, если вы не используете один и тот же номер IP-порта для других служб на разных сетевых интерфейсах.

Я использовал свое последнее предложение и подключил их к одной сети. Эти сети в любом случае локальные, это просто логическое разделение. Это работает для создания FIFO, но ncmpcpp этого не хочет (см. Мой предыдущий ответ, 2 выше).

Есть идеи по поводу названия этого канала? Или есть другой путь к FIFO, например mpd.conf ? Кажется, что без него вообще не работает.

Я думал, что mpd.conf использовалось только для конфигурации демона MPD. В этом случае это должно быть избыточным, потому что mopidy - это демон MPD, а ваш докер создает файл FIFO. В этом случае единственное, что должно быть необходимо, - это убедиться, что .ncmpcpp/config соответствует клиенту, верно?

Вроде. Что именно он делает, я не знаю. Но, как видите, visualizer_output_name = "my_fifo" должно соответствовать audio_output { name "my_fifo" } . В настоящее время ncmpcpp показывает There is no output named "my_fifo" . Описание visualizer_output_name всего 5 постами выше. Похоже, он на самом деле каким-то образом напрямую подключается к выходу для синхронизации.

Я не использую ничего из этого, но мне кажется, что visualizer_output_name должен соответствовать одному из ваших выходов MPD (протокол, а не программа) (т.е. что-то в mpc outputs ). Mopidy в настоящее время не поддерживает настраиваемые выходы и имеет только один выход MPD: «Mute».

Вы, вероятно, захотите сбросить visualizer_output_name , если это возможно.

Пробовал не ставить. Визуализатора все еще не видно. Интересно, какой формат вывода udpsink : должен быть 44100:16:2 для работы визуализаторов ( ncmpcpp или nausea ).

Попробовал Mute всякий случай, получил очень забавный опыт: он просто отключил звук, не показывая ошибки, но и не показывая визуализаторы. Точнее, отключил вывод Mute .

Мне действительно интересно, где выполняется функция БПФ для визуализатора.
Выполняется ли это на выходе из FIFO или на входе в FIFO? Ты
потребуется проверить код клиента MPD, чтобы увидеть, как он обрабатывает данные FIFO.

Есть ли способ поддержать это только для тестирования, даже если обычно создается чудовищно огромный файл.

Тебе тоже не нужно поддерживать. Вам нужно узнать, где находится БПФ
должно быть сделано, а затем выберите правильный подход. Если БПФ
сделать это в визуализаторе, тогда будет напрасной тратой усилий
реализовать это снова.

13 мая 2015 года в 15:09 Вернер Беру [email protected] написал:

Есть ли способ поддержать то или иное, только для тестирования, даже если бы это было
обычно создают чудовищно огромный файл.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101676033.

БПФ выполняется визуализатором, и для этого требуется определенный аудиоформат в FIFO. Ссылка: http://git.2f30.org/nausea/about/

Хорошо - значит, нет причин не работать! Вы сделали
параллельное сравнение системы, на которой запущен стандартный демон MPD, с
локальный клиент ncmpcpp? Что произойдет, если вы переименуете имя файла FIFO в обоих
файлы конфигурации? Это все еще работает? Просто пытаюсь понять,
жестко запрограммированный путь где-то существует ...

13 мая 2015 года в 15:57 Вернер Беру [email protected] написал:

БПФ выполняется визуализатором и требует определенного аудиоформата.
в FIFO работать для этого. Ссылка: http://git.2f30.org/nausea/about/

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101702624.

Мой комментарий основан на источнике ncmpcpp .

Выход Mopidy Mute отключен по умолчанию, т.е. звук не отключен. Визуализатор ncmpcpp примет выданный вами вывод, отключит его (без эффекта), а затем включит, таким образом отключив звук. Возможно, им стоит просто переключить его дважды.

Звук в неправильном формате - хорошая возможность. В вашем конвейере gstreamer нет ничего, что могло бы гарантировать его правильность, в отличие от @adamcik в его коде выше.

Трудно понять, почему формат может быть проблемой .... это 16-битная подпись
целые числа. Худшее, что может случиться, это то, что вы поменяете местами каналы L / R?

13 мая 2015 года в 16:33 Ник Стил [email protected] написал:

Мой комментарий основан на источнике ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.

Выход Mopidy Mute отключен по умолчанию, т.е. звук не отключен.
Визуализатор ncmpcpp примет выданный вами вывод и отключит его (нет
эффект), а затем включите его, отключив звук. Возможно, им следует
просто переключите его дважды.

Звук в неправильном формате - хорошая возможность. У вас есть
ничего в вашем конвейере gstreamer, чтобы убедиться, что он правильный, в отличие от @adamcik
https://github.com/adamcik имел в своем коде выше.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

И даже если порядок байтов был неправильным, вы могли бы просто ожидать, что БПФ
выход для генерации неправильной частотной характеристики ... но вы все равно увидите
что-то.

13 мая 2015 года в 16:37 Лиам Уикинс [email protected] написал:

Трудно понять, почему формат может быть проблемой .... это 16-битная подпись
целые числа. Худшее, что может случиться, это то, что вы поменяете местами каналы L / R?

13 мая 2015 года в 16:33 Ник Стил [email protected] написал:

Мой комментарий основан на источнике ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.

Выход Mopidy Mute отключен по умолчанию, т.е. звук не отключен.
Визуализатор ncmpcpp примет выданный вами вывод и отключит его (нет
эффект), а затем включите его, отключив звук. Возможно, им следует
просто переключите его дважды.

Звук в неправильном формате - хорошая возможность. У вас есть
ничего в вашем конвейере gstreamer, чтобы убедиться, что он правильный, в отличие от
@adamcik https://github.com/adamcik имел в своем коде выше.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

да, верно, так что, возможно, это потому, что оставление вывода Mute Mopidy включенным означает, что udpsink не будет отправлять никаких данных.

cat /tmp/mdp.fifo (созданный из UDP, как указано выше) правильно показывает постоянный поток данных.

Посмотрел код визуализатора ncmpcpp:

  1. открывает файл как O_RDONLY | O_NONBLOCK
  2. читает сверху ; учитывая, что он настроен для стерео в моей конфигурации mopidy, он должен быть 44100: 16: 2.

Любой желающий также может попробовать из моей ветки (после установки 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

Пришлось потратить довольно много времени на споры о netcat, поскольку -k у меня не сработал, но вот что я придумал для автоматического перезапуска его при переключении песен:

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

другие варианты, как указано выше в основном.

@ S0lll0s @wernight netcat -k у меня тоже не работал, и его пришлось перезапускать после изменения песни. Пока ваше решение работает, я обнаружил, что socat работает лучше:

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

Для пользователей Arch Linux:

Чтобы получить nc с поддержкой -k вам нужно установить пакет openbsd-netcat , но у меня он тоже не сработал, поэтому попробуйте использовать скрипт @SjRNMzU - вам нужно пакет socat для его запуска.

@johnhamelink (я предполагаю, что вы запускаете Arch из своего комментария) Были ли у вас проблемы с визуализатором, пытающимся «догнать» после того, как вы приостановили песню с помощью решения socat ?

@ theos-space Не могу сказать, что сам это заметил

Я использую Arch и не могу заставить его работать либо с nc (как gnu и openbsd ), так и с socat . Кроме того, я не могу читать из gst-launch-1.0 ... udpsink port=5555 с помощью nc -kluw 1 127.0.0.1 5555 , так как он ничего не выводит на экран.

Можно подтвердить, что это работает на 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:

запустить socat в автозагрузке системы:

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 (для udpsink необходимо было указать хост примечания):

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

ranisalt для Arch, вам нужно скомпилировать ncmpcpp с проверкой поддержки fifo здесь: https://bbs.archlinux.org/viewtopic.php?id=99915

Вот моя рабочая настройка Arch, после прочтения оставшейся части ветки + документации + справочных страниц + различных блогов. Я запускаю Mopidy как системную службу и отправляю аудио в пользовательскую службу PulseAudio через TCP. Я добавил несколько дополнительных аннотаций, которые, надеюсь, помогут менее опытным.

Пакеты

Все это из официальных репозиториев 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

Настраивать

Включите системную службу mopidy:

sudo systemctl enable mopidy.service

Замените системную конфигурацию mopidy символической ссылкой на конфигурацию пользователя для простоты редактирования (необязательно):

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

Создайте файл fifo:

mkfifo "/tmp/mpd.fifo"

Конфиги

в ~/.config/mopidy/mopidy.conf (или /etc/mopidy/mopidy.conf если вы не создавали символическую ссылку): Сообщите mopidy, чтобы он отправлял звук на сервер pulseaudio, прослушивающий на localhost, и на приемник UDP на localhost: 5555

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

в ~/.ncmpcpp/config : Сообщите ncmpcpp, где найти файл FIFO, который ему нужно прослушать, и некоторые другие разные настройки

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

в ~/.config/pulse/default.pa : Скажите PulseAudio, чтобы он принимал аудио через TCP от localhost (настройка, вероятно, уже существует и ее можно просто раскомментировать)

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

в ~/.zshrc (также должно работать в ~/.bashrc ): создайте функцию-оболочку "nplayer" для обработки запуска и остановки netcat с помощью ncmpcpp :

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

Что это значит:

  • определить функцию с подоболочкой, обертывающей все ее содержимое
  • запустить в фоновом режиме процесс netcat чтобы прослушивать аудиоданные, отправленные в приемник UDP, и перенаправлять их в созданный ранее fifo. Флаги:

    • -k продолжать прослушивание после завершения текущего соединения

    • -l включить режим прослушивания

    • -u включить режим UDP

    • -w NUM тайм-аут простаивающих соединений через NUM секунд (в данном случае 1 секунда)

  • установить ловушку EXIT, чтобы убить процесс netcat когда процесс ncmpcpp завершается и вызывает выход подоболочки функции
  • запустить процесс ncmpcpp на переднем плане

Я запускаю mopidy на Manjaro (арочный дистрибутив). У меня возникли проблемы с получением вывода через socat или netcat. Однако я смог наблюдать за пакетами, приходящими с tcpdump:
sudo tcpdump -i lo -n udp port 5555 -XX

Это заняло у меня много времени, и я бы не нашел проблему без @mosbasik .
Проблема заключалась не в том, чтобы host=127.0.0.1 после udpsink, почему это работает для других людей, а не для меня, я не знаю. Но если вы не получаете никакого вывода, возможно, это так. Эти 2 работали для меня:

[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↪

Замечание: мне не удалось заставить pulsesink работать, поэтому мне пришлось оставить его на autoaudiosink , что у меня тоже было раньше. Однако визуализатор по какой-то причине кажется действительно очень медленным, я не уверен, что это из-за того, что autoaudiosink Работает идеально после перезагрузки ... все же немного медленнее. С Pulselink он продолжал жаловаться на плагины gstreamer. Даже после того, как (я полагаю) я установил все пакеты плагинов для gst в официальных репозиториях Arch. Примечание flump3dec и mad


Вывод 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

Я столкнулся с проблемой, пытаясь заставить udpsink работать с Mopidy и всеми удаленными клиентами ncmpcpp. Mopidy настраивается с MacVLAN в среде докеров. Я успешно вижу порт на контейнере.

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!

В настоящее время Mopidy использует следующий бит конфигурации:

[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

Есть мысли о том, как я могу использовать netcat для успешного получения необработанных данных в mpd.fifo? Я думаю, что следующее не работает, потому что я неправильно использую netcat. Некоторые исследования не дали никаких ответов, так что, надеюсь, кто-нибудь укажет мне правильное направление.

#!/bin/bash

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

Я получаю следующую ошибку:

nc: Can't assign requested address

Есть мысли о том, как я могу заставить это работать?

Ваше здоровье!

К вашему сведению, я добавил поддержку udpsink gstreamer в ncmpcpp, так что теперь его можно использовать напрямую, без хаков с помощью FIFO.

Подробнее см. Https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 .

Ниже тизер. Это mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

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

@arybczak Замечательно ! Вы должны опубликовать это на https://discourse.mopidy.com/c/show-and-tell/9

@adamcik Разве это не означает, что эта проблема, назад, «устарела» в пользу лучшего решения реальной проблемы, которая ее вызвала (поддержка визуализации в ncmpcpp)?

@pspeder , что именно ты имеешь в виду? Есть ли проблема с использованием https://github.com/mopidy/mopidy/issues/775#issuecomment -747725806?

@kingosticks просто предлагал закрыть эту проблему 🙂

Я согласен с этим.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги