LINUX.ORG.RU
решено Форум — Desktop  

MPD на сервере, ncmpcpp на другой системе, нет звука.

 , , , ,


0

1

Привет, ЛОР. Помогите, пожалуйста, решить проблему. Дано: Сервер в локальной сети, который подключен к NAS и на нем поднят MPD. Конфиг MPD следующий

music_directory    "/var/lib/mpd/music"
playlist_directory "/var/lib/mpd/playlists"
db_file            "/var/lib/mpd/database"
log_file           "/var/log/mpd/mpd.log"
pid_file           "/var/run/mpd.pid"
state_file         "/var/lib/mpd/state"
sticker_file       "/var/lib/mpd/sticker.sql"

audio_output {
        type            "httpd"
        name            "My HTTP Stream"
        encoder         "vorbis"
        port            "8800"
        bitrate         "128"
        format          "44100:16:1"
        always_on       "yes"
        tags            "yes"
}

На клиенте в локальной сети использую ncmpcpp с параметром -h ip:port.

К серверу подключается, библиотеку видит, но звука при воспроизведении нет, равно как и в Volume плеера указано n/a. На клиентской системе ArchLinux + PipeWire. Подскажите, пожалуйста, что я делаю не так?

★★★★
← UID вместо имени
KDE + i3 →
 ← 1 2

использую ncmpcpp с параметром -h ip:port.
звука при воспроизведении нет, равно как и в Volume плеера указано n/a

Тут httpd — это потоковый сервер, а не обычный аудиовывод. Он не играет звук ни на сервере, ни на клиенте сам по себе. Он предоставляет ссылку, по которой клиент (mpv, VLC, браузер, и др.) может получать поток. Поэтому ncmpcpp, подключаясь к MPD, может управлять воспроизведением, видеть плейлист, библиотеку и т. д., но не воспроизводит звук, потому что сам ncmpcpp — не аудио-клиент. httpd-вывод не поддерживает управление громкостью, он отдает поток, и всё. Поэтому MPD сообщает ncmpcpp: «нет громкости, которую можно регулировать» -> Volume: n/a.

Если тебе важно, чтобы звук шел на клиент (через PipeWire/ALSA), ты можешь запустить MPD локально на клиенте (а библиотеку можно монтировать через NFS, SMB или SSHFS). И управляй через ncmpcpp (к нему даже -h не нужен).

Используй audio_output: 

audio_output {
    type    "pipewire"
    name    "Local PipeWire"
}

А если ты хочешь, чтобы звук воспроизводился на клиенте напрямую с сервера MPD, подключись к HTTP-аудиопотоку MPD с помощью mpv, vlc, ffplay, браузера и т. д. Например: mpv http://<ip_сервера>:8800

Если хочешь стримить MPD-аудио синхронно на нескольких клиентах, используй Snapcast: MPD выводит звук в FIFO (audio_output type «fifo»), а Snapserver забирает его и распространяет по сети. Snapclient на клиентах получает и воспроизводит. То есть в этой связке ncmpcpp управляет MPD, а Snapclient на клиенте играет.

posixbit ★★★
()
Последнее исправление: posixbit (всего исправлений: 2)
Ответ на: комментарий от Jefail

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

Понадобится промежуточный аудио-клиент, который будет отвечать за воспроизведение звука с сервера. Например, mpv:

nano ~/.config/systemd/user/mpd-stream.service

[Unit]
Description=MPD HTTP Stream Playback

[Service]
ExecStart=/usr/bin/mpv --no-video http://АЙПИ_ТВОЕГО_СЕРВЕРА:8800
Restart=always

[Install]
WantedBy=default.target

Затем активируй:

systemctl --user daemon-reexec
systemctl --user enable --now mpd-stream.service

Теперь демон аудио-клиента mpv будет запускаться автоматически при входе, и ты можешь просто использовать ncmpcpp. Но громкостью из ncmpcpp ты управлять не сможешь. Это надо будет посылать mpv (хотя это можно автоматизировать при желании, чтобы было удобно).

Если тебе нужен наилучший контроль громкости и простота, Snapcast + ncmpcpp — наиболее удобный способ, особенно при нескольких клиентах. Если у тебя один, демон аудио-клиента mpv в фоне — самый простой вариант.

posixbit ★★★
()
Последнее исправление: posixbit (всего исправлений: 1)
Ответ на: комментарий от mord0d

Воспроизведение полностью на удалённом клиенте, для этой топологии достаточно простейшего http сервера (да хоть python http.server), никаких перекодирований звукового потока, без проблем можно слушать как образы, так и отдельные треки.

Grapow ★★★
()
Последнее исправление: Grapow (всего исправлений: 1)
Ответ на: комментарий от Grapow

Воспроизведение полностью на удалённом клиенте, для этой топологии достаточно простейшего http сервера (да хоть python http.server), никаких перекодирований звукового потока, без проблем можно слушать как образы, так и отдельные треки.

И как это противоречит моему утверждению про клиенты mpd? В них нет http-клиента для прослушивания, только для управления сервером mpd.

Для прослушивания нужен любой http-клиент, умеющий в поток.

без проблем можно слушать как образы, так и отдельные треки

Если они были включены через клиент.

У mpd довольно упоротая архитектура. Он http-radio, потому все слушатели будут слушать одно. Для стриминга музыки больше подойдёт Jellyfin и Navidrome.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

У mpd довольно упоротая архитектура. Он , потому все слушатели будут слушать одно.

Для стриминга музыки больше подойдёт Jellyfin и Navidrome.

Противоречивые утверждения. Стриминг сам по себе подразумевает один источник потока и несколько приёмников, которые этим потоком не управляют, а только воспроизводят. Более того, http-radio по определению подразумевает стриминг.

Спутниковая конфигурация mpd требует:

  • 2 mpd сервера, по одному на хранилище файлов и на устройство воспроизведения;

  • 1 http сервер на стороне хранилища файлов;

  • 1 mpd клиент на стороне устройства воспроизведения.

Отвечая на твой вопрос, @Ololo_Trololo:

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

Grapow ★★★
()
Ответ на: комментарий от Grapow

Стриминг сам по себе подразумевает один источник потока и несколько приёмников

У mpd контроль (переключение треков, изменение очереди) и прослушивание это два разных сервера. Клиенты mpd это только контроль, нет в них функции прослушивания. Совсем.

И нет, стриминг не обязан быть единым источником, http-radio это лишь один из примеров стриминга, и один из немногих примеров единого потока (Subsonic позволяет слушать каждому клиенту своё, не переставая быть стримингом).

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

НО! Управление и воспроизведение потока могут быть на разных машинах (это, кстати, фундаментальное отличие mpd от любых других серверов для стриминга потокового медиа). Более того, клиент-слушатель может не иметь прав управления.

mord0d ★★★★★
()
Ответ на: комментарий от Ololo_Trololo

Я уже выше писал про браузер и mpv.

Посмотри внимательно зависимости ncmpcpp, там нет никаких зависимостей про звук/медиа, ни PulseAudio/ALSA/OSS, ни ffmpeg/lame/flac. Единственный taglib нужен только чтобы теги редактировать даже удалённо.

А где тогда слушаешь?

Я давно отказался от mpd в пользу Navidrome, LMS и Jellyfin.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

У mpd контроль (переключение треков, изменение очереди) и прослушивание это два разных сервера.

Клиенты mpd это только контроль, нет в них функции прослушивания. Совсем.

Снова противоречивые утверждения. Клиенты mpd, коих множество, действительно выполняют исключительно функцию пульта к серверу, который занимается воспризведением. При этом, клиенты не являются серверами. Совсем.

В спутниковой конфигурации 2 mpd сервера, один на стороне хранилища файлов, другой на стороне устройства воспроизведения.

Задача сервера mpd на стороне хранилища - индексация файлов и предоставление базы данных серверу mpd на стороне устройства воспроизведения, который к этой базе обращается и получает файлы от http сервера с хранилища.

Клиент mpd на стороне устройства воспроизведения общается исключительно с сервером mpd на том же устройстве.

Grapow ★★★
()
Ответ на: комментарий от Grapow

При этом, клиенты не являются серверами.

При использовании http-потока, mpd-сервер открывает один порт, а для управления используется другой порт. Это два разных порта, выполняющих две разные функции. И клиенты, цепляющиеся к каждому из них — две разные сущности. Так понятнее?

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Это ты мне рассказываешь? При чём тут http поток?

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

  • Адрес и порт этого сервера предоставляется реализации curl, встроенной в mpd сервер на стороне устройства воспроизведения, в качестве music directory.

  • Адрес и порт mpd сервера на стороне хранилища файлов указывается mpd серверу на стороне устройства воспроизведения для предоставления последнему базы данных проиндексированных файлов.

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

Так понятнее?

Grapow ★★★
()
Ответ на: комментарий от Grapow

Есть сервер, функция которого отдавать в сеть файлы.

mpd не отдаёт файлы, он отдаёт поток (причём не важно — в аудиокарту или http).

Я вообще не понимаю зачем ты притянул сюда “http/nfs/smb”.

mord0d ★★★★★
()
Ответ на: комментарий от Grapow

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

Нет, mpd-клиент может быть где угодно, не обязательно на стороне устройства воспроизведения (ведущий радио не обязан слушать то, что вещает, а слушатель не имеет права вмешиваться в трансляцию).

mord0d ★★★★★
()
Ответ на: комментарий от Ololo_Trololo

Ну так мы можем договориться до того, что плеер не воспроизводит музыку. Конечно, на стороне воспроизведения воспроизводит звук звуковая система. Но разве мы об этом беседуем?

Grapow ★★★
()
Ответ на: комментарий от mord0d

mpd не отдаёт файлы

А где я утвердал обратное?

он отдаёт поток (причём не важно — в аудиокарту или http).

Важно. В аудиокарту он отдаёт поток на устройстве воспроизведения, или, как правильно заметил @Ololo_Trololo, на принимающем устройстве. На локалхосте это тождественно.

Я вообще не понимаю зачем ты притянул сюда “http/nfs/smb”.

Мы же говорим о сетевом применении mpd. Без помощи файлового сервера ему трудно добраться до файлов.

Более того, зачем отдавать поток в http? Это ведь будет тем самым «дубовым» и неуправляемым на принимающей/воспроизводящей стороне потоком.

Grapow ★★★
()
Ответ на: комментарий от mord0d

mpd-клиент может быть где угодно, не обязательно на стороне устройства воспроизведения

Так и знал, что ты к этому придерёшься. Я хотел как проще. Да, mpd клиент действительно может быть где угодно. Важно только то, к какому из двух mpd серверов в спутниковой топологии он обращается.

Grapow ★★★
()
Ответ на: комментарий от Ololo_Trololo

Зачем всё сваливать в кучу и передёргивать контексты?

Предлагаю для дальнейшего взаимопонимания условиться о следующих абстракциях, безотносительно их реализации:

  • Плеер воспроизводит музыку

  • Плеер находится непосредственно на устройстве воспроизведения

  • Понятие сервера само по себе абстрактно.

  • Конкретно в нашем случае есть файловый http/nfs/smb сервер для предоставления плееру доступа к файлам, находящимся на удалённом сетевом устройстве.

  • mpd сервер - частный случай абстрактного сервера и не занимается ни приёмом, ни передачей звукового потока/стрима.

  • mpd клиент - всего лишь пульт управления воспроизведением. Не имеет значения, где он находится.

Grapow ★★★
()
Последнее исправление: Grapow (всего исправлений: 2)
Ответ на: комментарий от Ololo_Trololo

mpd на стороне файлового хранилища только индексирует файлы и актуализирует базу данных.

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

Grapow ★★★
()
Последнее исправление: Grapow (всего исправлений: 1)
Ответ на: комментарий от Grapow

подскажите, а как именно по http? тот же арчвики пишет про необходимость smb или nfs в режиме satellite. может есть возможность конфиги показать? хочется режим satellite, чтобы на сервере индексировалась и хранилась библиотека, а на клиентах с помощью ncmpcpp каждый своё слушали/управляли

being_a_cyborg
()
Ответ на: комментарий от being_a_cyborg

Да, пожалуйста:

# Database #######################################################################

music_directory "http://address:port2"
database {
       plugin "proxy"
       host "address"
       port "6600"
       keepalive "no"
}

# Input #######################################################################
#
input {
        plugin "curl"
        tcp_keepalive "yes"
}

input_cache {
        size "100 MB"
}

Где в music_directory address и port2 относятся к серверу с файлами, базой данных и mpd, который эту базу обрабатывает.

Grapow ★★★
()
Последнее исправление: Grapow (всего исправлений: 2)
Ответ на: комментарий от Grapow

спасибо большое, дошли вот руки, поковырял немного, стало понятнее.

уже вот так :) :

exception: Failed to decode http://192.168.50.106:6600/_classics/Bach%20-%20Piano%20Music%20%28Shaun%29/Bach%20-%20Schiff%20-%20BWV%200988%20-%20Goldberg%20Variations%20-%20Aria.mp3; CURL failed: Received HTTP/0.9 when not allowed

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

being_a_cyborg
()
Ответ на: комментарий от being_a_cyborg

Ты ломанулся на порт 6600, а этот порт исключительно для запроса в базу данных. Запили себе на сервере для медиа порт, допустим, 8000 и тогда у тебя будет так:


music_directory "http://address:8000"
database {
       plugin "proxy"
       host "address"
       port "6600"
       keepalive "no"
}
Grapow ★★★
()
 ← 1 2
← UID вместо имени
Desktop
KDE + i3 →