Это продолжает появляться, поскольку людям действительно нравится визуализатор 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, поэтому убедитесь, что моно / стерео действительно совпадают.
Куда это делось? это будет добавлено в основной пакет?
Над этим не работают, так как нам нужно было бы преобразовать его в 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 :
$ wget -qO- https://get.docker.com/ | sh
$ sudo gpasswd -a ${USER} docker
$ 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.
У меня сейчас нет решения. Думаю о решениях:
--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
:
Я не совсем понимаю, что вы имеете в виду, говоря «в разных сетях». Если вы хотите изолировать аудиотрафик на локальный компьютер, вы должны использовать 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:
O_RDONLY | O_NONBLOCK
Любой желающий также может попробовать из моей ветки (после установки 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 секунда)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
, что у меня тоже было раньше. Однако визуализатор по какой-то причине кажется действительно очень медленным, я не уверен, что это из-за того, что Работает идеально после перезагрузки ... все же немного медленнее. С Pulselink он продолжал жаловаться на плагины gstreamer. Даже после того, как (я полагаю) я установил все пакеты плагинов для gst в официальных репозиториях Arch. Примечание autoaudiosink
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 просто предлагал закрыть эту проблему 🙂
Я согласен с этим.
Самый полезный комментарий
К вашему сведению, я добавил поддержку
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