Mopidy: Erwägen Sie das Hinzufügen einer Gstreamer-Fifo-Spüle

Wo ist das geblieben? Wird dies dem Hauptpaket hinzugefügt?

Daran wird nicht gearbeitet, da wir es in GStreamer 1.0 konvertieren müssten, und alle meine bisherigen Experimente damit haben Probleme beim Ausführen benutzerdefinierter Elemente in Python aufgedeckt. Es gibt andere Möglichkeiten, das vielleicht alles zu lösen, aber ich habe keine Zeit, daran zu arbeiten.

Ich würde gerne FIFO-Unterstützung hinzugefügt sehen :)

Ich habe dies gerade auf der Suche nach einer Möglichkeit gefunden, den Musikvisualisierer von ncmpcpp mit Mopidy zusammenzuarbeiten. Ich bin dafür.

Ja, das ist der gleiche Grund, warum ich das gefunden habe. Das wäre echt toll
in der Lage sein, gestreamte Musik zu visualisieren,

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

Ich habe das gerade auf der Suche nach einer Möglichkeit gefunden, den Musikvisualisierer von ncmpcpp dazu zu bringen,
mit mopidy arbeiten. Ich bin dafür.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

Es gibt gstreamer-Visualisierungs-Plugins, können Sie diese nicht einfach verwenden?
Am 6. November 2014, 08:35 Uhr schrieb "Diego Berrocal" [email protected] :

Ja, das ist der gleiche Grund, warum ich das gefunden habe. Das wäre echt toll
in der Lage sein, gestreamte Musik zu visualisieren,

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

Ich habe das gerade auf der Suche nach einer Möglichkeit gefunden, den Musikvisualisierer von ncmpcpp zu erhalten
zu
mit mopidy arbeiten. Ich bin dafür.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mopidy/mopidy/issues/775#issuecomment -62007426.

Beachten Sie, dass diese in der nächsten Version auf dem Weg sind.

Arbeitet jemand daran? Wäre wirklich schön, den ncmpcpp Visualizer mit mopidy verwenden zu können.

Nicht, dass ich wüsste, und wir möchten dies wahrscheinlich nicht als GStreamer-Element tun, da es unsere Migration zu GStreamer 1.x blockieren würde.

Dies ist IMO auch blockiert, wenn die richtige Unterstützung für Ausgaben wieder hinzugefügt wird.

Ich fügte nur hinzu, dass ich auch auf dieses Problem gestoßen bin, als ich versuchte, Mopidy/ncmpcpp Visualizer-Unterstützung hinzuzufügen. Würde es gerne in Zukunft haben, auch wenn es derzeit nicht bearbeitet wird. Ich möchte auch meinen größten Respekt für diejenigen aussprechen, die ihre Zeit in Open-Source-Projekte investieren. :Lächeln:

Im Idealfall würde dies aus der Ferne funktionieren. Die Stärke von Mopidy liegt wirklich darin, eine Lösung zu sein, die sich in Ihrer privaten Cloud befinden kann.

Im Allgemeinen sind FIFOs keine sehr tragbare Methode der Interprozesskommunikation und sollten IMO vermieden werden. Sie haben auch einige unangenehme Nebenwirkungen, die in diesem Thread bereits erwähnt wurden. Ich denke, es ist besser, wenn Sie Ihre Pakete persönlich mit einer UDP-Senke auswerfen .... das ist eine allgemeinere Lösung und kann leicht an etwas angepasst werden, das (falls erforderlich) in ein FIFO außerhalb von Mopidy schreibt .... es ist eine einzige Shell-Skript-Zeile, um Daten von einem UDP-Port (mit netcat) zu lesen und in ein FIFO zu schreiben.

Das klingt gut. Möglicherweise liegen Clients, die ncmpcpp auch als Eingabe verwenden würde.

Eine andere Idee besteht darin, PulseAudio direkt zu verwenden, da dies keine zusätzliche Implementierung auf der Seite von Mopidy erfordert. Der von mir erstellte Docker-Container verwendet TCP, um über das Netzwerk auf PulseAudio zuzugreifen. ncmpcpp könnte das tatsächlich direkt verwenden.

Von dem, was ich gelesen habe, führt der Visualizer nur eine FFT auf Blöcken von Samples aus, die aus einer FIFO-Datei gelesen werden. Der Punkt, den ich anspreche, ist, dass Sie ein FIFO außerhalb von Mopidy mit mkfifo erstellen und dann die UDP-Daten von Mopidy mit netcat lesen und die Ausgabe von netcat an die . umleiten können FIFO-Datei. Es muss sich also nichts an ncmpcpp ändern, es liest nur die FIFO-Datei.

Um das zu erreichen, was Sie mit Mopidy anstreben, ist kein Implementierungsaufwand erforderlich, da Sie die Audioausgabeeigenschaft so ändern können, dass sie in ein udpsink-GStreamer-Element ausgegeben wird. Es ist wahrscheinlicher, dass Sie es als Teil eines "T-Stücks" anordnen möchten, das sowohl an Ihre ALSA/Pulse-Senke als auch an den udpsink ausgegeben wird.

Folgendes sollte funktionieren.... nicht getestet, daher möglicherweise einige Anpassungen erforderlich.

In der Mopidy-Audiokonfiguration:

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

Starten Sie auf Ihrem Linux-Host netcat, um auf dem localhost auf Port 5555 nach UDP-Daten zu lauschen und die Samples an das FIFO auszugeben:

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

In deiner mpd.conf:

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

Hinweis: Wenn Sie einen PulseAudio-Ausgang verwenden, ist es möglicherweise möglich, mit seinem TCP-Richtungsverbindungsmodul etwas Ähnliches zu tun. Möglicherweise müssen Sie jedoch jedes Protokoll, das über der TCP-Verbindung ausgeführt wird, zurückentwickeln, z. B. ist es möglicherweise nicht möglich, es als reine Senke zu behandeln.

Danke @liamw9534 fürs Teilen. Ich hätte eine Weile gebraucht, um die Konfiguration genug zu verstehen oder sogar zu wissen, dass ich es könnte. Ich werde versuchen, das zum Docker-Container hinzuzufügen, um zu sehen, ob es funktioniert.

Dies kann jedoch zu Problemen führen, wenn Sie das Fifo nicht leeren. Da netcat den Kernel-Puffer füllt und dann fehlschlägt. Und je nachdem, wie das FIFO geöffnet wird, können Sie auch auf Probleme stoßen, da FIFOs die Anwesenheit eines Lesers erfordern können, um beschreibbar zu sein :/

Aber Sie könnten meinen FifoStreamer-Code anpassen, um die UDP-Daten zu akzeptieren und dies für Sie zu erledigen, da ich hoffentlich bereits die meisten Fehlerfälle behandelt habe, auf die Sie dort stoßen können.

@adamcik Wenn Sie ein funktionierendes Skript haben, docker-ncmpcpp ein, damit die Leute es verwenden können. Ich würde docker-mopidy auch so ändern, dass es standardmäßig auf UDP sendet, indem ich den obigen Ausgabetrick verwende.

Ich habe einige grundlegende Experimente auf der Befehlszeile durchgeführt und alles funktioniert gut, vorausgesetzt, Sie verwenden ein Verbindungs-Timeout, z. B. nc -kluw 1 127.0.0.1 5555 > /tmp/mopidy.fifo . Dies zwingt netcat, immer auf eine neue Quellportverbindung zu warten, nachdem die letzte Verbindung unterbrochen wurde (1s Timeout).

Der obige Befehl funktioniert unabhängig davon, ob etwas aus der FIFO-Datei gelesen wird oder nicht und funktioniert auch, wenn das Lesen des Prozesses aus der FIFO-Datei stoppt und die Datei schließt.

@wernight siehe die Beschreibung dieses Fehlers, das ist der gesamte Code, den ich habe.

Und nur für Gürtel und Hosenträger würde ich den Befehl in eine while-Schleife einfügen, zB while :; do nc -kluw 1 127.0.0.1 5555> /tmp/mopidy.fifo; sleep 1; done - wenn er beendet wird, wird er nach 1 Sekunde Verzögerung einfach wieder gestartet.

@liamw9534 Du hast dort eine mpd.conf. Ich bin dadurch verwirrt. Sie betreiben neben mopidy-mpd einen eigenständigen MPD-Server?

@lrvick ja, mein Fehler, ich dachte natürlich an die Konfiguration, die zu ~/.ncmpcpp/config hinzugefügt werden muss

.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

(hier -p hinzugefügt).

~/.ncmpcpp/config

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

(auch gemacht in wernight/docker-mopidy und wernight/docker-ncmpcpp )

Es scheint jedoch, dass es keine Verbindung zu 5555 herstellen kann, obwohl das Protokoll von Mopidy zeigt, dass es die output Konfiguration verstanden hat. netstat zeigt auch kein offenes UDP auf 5555. Ich verstehe die output Zeile nicht ganz: tee ist ein Bash-Befehl, der Rest sieht aus wie Mopidy-Zeug.

Ich habe jedoch udp6 [::]:51307 beim Abspielen von Musik gefunden.

Das output wird als GstBin Element interpretiert, das als Teil von Mopidy an playbin2 übergeben wird - unter der Haube ist dies nur eine Gstreamer-Pipeline, nichts Besonderes. Das tee ist also eigentlich ein Gstreamer-Element. Es hat nichts mit dem Shell-Befehl tee zu tun.

Sie können sich also ungefähr annähern, was in Mopidy auf der Befehlszeile passiert, indem Sie etwa Folgendes tun:

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

Dadurch wird ein Sinuston wiedergegeben. Führen Sie dann den folgenden Befehl aus:

nc -kluw 1 127.0.0.1 5555

Ich kann dann viele seltsame Zeichen auf meinem Display sehen ... dies ist der Testaudiostream, der von nc auf stdout ausgegeben wird. Dies beweist effektiv, dass der zugrunde liegende Ansatz funktioniert. Können Sie bestätigen, dass Sie das gleiche Verhalten replizieren können?

Sie können dann versuchen, das FIFO als zweiten Schritt hinzuzufügen und bestätigen, dass Sie das FIFO cat auf Standard setzen können und die gleichen seltsamen Zeichen sehen.

Ich würde auch das Konfigurationsformat überprüfen, das von ncmpcpp . Ich habe einen kurzen Blick auf https://wiki.archlinux.org/index.php/Ncmpcpp#Enabling_visualization geworfen und kann sehen, dass das erforderliche Konfigurationsformat möglicherweise anders ist, z.

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

Ich verwende nicht ncmpcpp , also könnte das Problem auch hier liegen...

$ 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

(mit nc ... -p sonst bekomme ich eine Fehlermeldung)

Ich höre den Ton jedoch spielen.

Welche Distribution benutzt du? Auch wenn Sie nc -h eingeben, was ist die Ausgabe?

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

Die Option -p wird mit nc nicht benötigt, die ich unter Ubuntu verwende. Die Manpage impliziert auch, dass es ein Fehler sein sollte, -p in Verbindung mit -l anzugeben:

     -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.

Verwendung von Debian Wheezy.

Hier sind die vollständigen Schritte für Ubuntu, beginnend mit der Installation von Docker :

1. Docker installieren :

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

1. Remote-PulseAudio aktivieren
2. Auf Debian ausführen:

$ 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

Versucht mit netcat-openbsd Paket, das gibt:

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

Jetzt zeigt nc einfach nichts mehr an, während der Ton gespielt wird (was etwas besser erscheint):

$ nc -kluw 1 127.0.0.1 5555
(nothing here)

Ok, zwei Terminals öffnen und im ersten Terminal ausführen:

nc -kluw 1 127.0.0.1 5555

Dann im zweiten Terminallauf:

nc -u 127.0.0.1 5555

Geben Sie einige Zeichen auf stdin in das zweite Terminal ein und drücken Sie die EINGABETASTE. Sehen Sie die gleichen Zeichen im ersten Terminal auf stdout?

Ja das funktioniert. Hat es sogar Cross Dockers zum Laufen gebracht:

$ 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

Das erklärt also nicht, warum nc mit gst-launch nichts host=SOMETHING festlegen muss, damit es containerübergreifend funktioniert. Dies wird problematisch. Scheint nicht gesendet zu werden. Aber das ist etwas, das ich lösen kann, sobald es zumindest auf einem einzelnen Container funktioniert.

Aha! Wenn ich host=0.0.0.0 einstelle, funktioniert es!

Müssen Sie die Daten über ein Netzwerk senden? Ich war davon ausgegangen, dass Sie die Pakete nur auf dem lokalen Computer benötigen. Wenn Sie udpsink host=0.0.0.0 port=5555 werden Pakete überall in Ihrem Netzwerk gesendet. Vermutlich nicht das was du willst...

Sie sollten stattdessen host=127.0.0.1 sagen können, um Pakete auf lokales Loopback zu beschränken.

Ich vermute, dass das eigentliche Problem daher an der Standard-Routing-Konfiguration liegt. Standardmäßig werden auf Ihrem System die ausgehenden Pakete an eine andere Schnittstelle geleitet. Möglicherweise unterschiedliche Versionen des gstreamer-Elements oder Unterschiede im IP-Routing-Setup.

Aus dem Container musste ich 0.0.0.0 oder evtl. die IP der Maschine verwenden. Die Standardeinstellung funktionierte nicht einmal auf einem einzelnen Computer/Container.

Aber ja, ich muss jetzt Netzwerk verwenden, weil es sich bewährt, ncmpcpp und mopidy in separaten Docker-Containern zu speichern, was bedeutet, dass sie sich in verschiedenen Netzwerken befinden. Das ist wirklich gut für die Sicherheit und Isolation und so, aber es verursacht ein bisschen Ärger:

Der ncmpcpp-Client verbindet sich mit dem MPD-Server, um nach Musikstreaming zu fragen, und erst danach ist die IP von ncmpcpp bekannt und das UDP-Paket sollte an seine IP gesendet werden; aber derzeit ist die IP in der Mopidy-Konfiguration fest codiert.

Ich habe gerade keine Lösung. Ich denke an Lösungen:

• Das FIFO in Mopidy erstellen und mit ncmpcpp teilen, aber ich fürchte, nichts wird das FIFO löschen und das ist ein großes Problem. Auch das Teilen von Dateien ist nicht so sauber wie Netzwerk-Sockets.
• Lokaler Daemon überwacht Verbindungen und leitet UDP-Datenverkehr an die gefundene Client-IP weiter; hacken.
• UDP SSH Tunnel , aber das ist komplex, fügt nutzlose Verschlüsselung hinzu, fügt einen weiteren Daemon hinzu... schlecht!
• Sehen Sie sich den Code an, um zu sehen, ob der standardmäßig auf die IP des ersten Clients oder noch besser auf die IPs aller verbundenen Clients eingestellt werden kann
• Sagen Sie Docker, dass es den Host über --net=container:NAME_or_ID freigeben soll, wodurch ein weiterer Parameter für die Benutzer hinzugefügt wird, aber das würde vieles vereinfachen!

Für diese zirkuläre Abhängigkeit gibt es Lösungen. Fühlt sich immer noch wie ein schrecklicher Hack an, aber es sollte für Benutzer am Ende einfach genug sein, ihn zu verwenden. Danke liamw9534 für die Hilfe, besonders bei den nc Befehlen, mit denen ich fremd war.

Das FIFO funktioniert, außer dass There is no output named "my_fifo"! . Es scheint, dass der Name mit dem in mdp.conf übereinstimmen muss:

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

Ich kann versuchen, die FIFO-Datei freizugeben, wenn ich weiß, wie ich diese Audioausgabe zu Mopidy hinzufüge. Übelkeit (ein einfaches Visualizer-Ony) scheinen die gleichen Anforderungen zu haben.

Ich habe diese Dokumentation von visualizer_output_name :

• Der folgende Parameter wird für ncmpcpp benötigt, um zu bestimmen, welcher Ausgang Daten für den Visualizer bereitstellt und somit die Synchronisierung zwischen Visualisierung und Ton ermöglicht, da es derzeit einige Probleme damit gibt.
• fifo-Ausgabe, deren Formatparameter auf 44100:16:1 für Mono-Visualisierung oder 44100:16:2 für Stereo-Visualisierung eingestellt werden muss

Ich bin mir nicht sicher, was Sie mit "in verschiedenen Netzwerken" meinen. Wenn Sie den Audioverkehr zum lokalen Computer isolieren möchten, sollten Sie 127.0.0.1 für udpsink . Wenn Sie 0.0.0.0 wählen, werden Pakete über die Standardroute geleitet, was wahrscheinlich bedeutet, dass UDP-Pakete über das Netzwerk gesendet werden viel Bandbreite, dh 2 x 16 x 44100 = 1,41 Mbps.

Theoretisch sollte es möglich sein, nc mit 0.0.0.0 zu konfigurieren, unabhängig davon, welche Netzwerkschnittstelle von udpsink . Dadurch werden alle Netzwerkschnittstellen überwacht. Das ist in Ordnung, solange Sie nicht dieselbe IP-Portnummer für andere Dienste auf verschiedenen Netzwerkschnittstellen verwenden.

Ich habe meinen letzten Vorschlag verwendet und beide in dasselbe Netzwerk gesteckt. Diese Netzwerke sind sowieso lokal, es ist nur eine logische Trennung. Das funktioniert, um das FIFO zu erstellen, nur ncmpcpp will es nicht (siehe meine vorherige Antwort, 2 oben).

Irgendeine Idee zu diesem Kanalnamen? Oder gibt es einen anderen Weg zu einem FIFO wie mpd.conf ? Ohne scheint es gar nicht zu gehen.

Ich dachte, mpd.conf nur für die MPD-Daemon-Konfiguration verwendet. In diesem Fall sollte dies überflüssig sein, da mopidy der MPD-Daemon ist und Ihr Docker die FIFO-Datei erstellt. In diesem Fall sollte nur sichergestellt werden, dass .ncmpcpp/config mit dem Client übereinstimmt, oder?

So'ne Art. Was es genau macht, weiß ich nicht. Aber wie Sie sehen, muss visualizer_output_name = "my_fifo" mit audio_output { name "my_fifo" } übereinstimmen. Derzeit zeigt ncmpcpp There is no output named "my_fifo" . Beschreibung von visualizer_output_name ist nur 5 Posts weiter oben. Es sieht so aus, als ob es tatsächlich irgendwie direkt mit dem Ausgang verbunden ist, um zu synchronisieren.

Ich benutze nichts davon, aber es sieht so aus, als ob visualizer_output_name mit einer Ihrer MPD-Ausgaben (Protokoll, nicht Programm) übereinstimmen sollte (dh etwas in mpc outputs ). Mopidy lässt derzeit keine konfigurierbaren Ausgänge zu und hat nur einen MPD-Ausgang: "Mute".

Wenn möglich, möchten Sie wahrscheinlich visualizer_output_name aufheben.

Habe versucht es nicht einzustellen. Immer noch kein Visualizer sichtbar. Ich frage mich über das Ausgabeformat von udpsink : Sollte 44100:16:2 damit Visualizer funktionieren ( ncmpcpp oder nausea ).

Habe Mute nur für alle Fälle ausprobiert, habe eine sehr lustige Erfahrung gemacht: Es hat nur den Ton stummgeschaltet, ohne einen Fehler anzuzeigen, aber auch ohne Visualizer anzuzeigen. Genauer gesagt hat es die Ausgabe von Mute deaktiviert.

Ich frage mich, wo die FFT-Funktion für den Visualizer ausgeführt wird.
Wird sie am Ausgang des FIFO oder am Eingang des FIFO durchgeführt? Sie
müsste den MPD-Client-Code überprüfen, um zu sehen, wie er mit den FIFO-Daten umgeht.

Gibt es eine Möglichkeit, beides zu unterstützen, nur zum Testen, auch wenn es normalerweise eine monströs riesige Datei erstellen würde.

Sie müssen auch nicht unterstützen. Sie müssen herausfinden, wo die FFT ist
getan werden soll, und wählen Sie dann den richtigen Ansatz. Wenn die FFT . ist
im Visualizer gemacht, dann wäre es nur eine reine Zeitverschwendung, dies zu tun
es wieder umsetzen.

Am 13. Mai 2015 um 15:09 Uhr schrieb Werner Beroux [email protected] :

Gibt es eine Möglichkeit, beides zu unterstützen, nur zum Testen, selbst wenn es so wäre?
normalerweise eine ungeheuer große Datei erstellen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mopidy/mopidy/issues/775#issuecomment -101676033.

FFT wird vom Visualizer durchgeführt und erfordert das spezifische Audioformat im FIFO, um dafür zu funktionieren. Referenz: http://git.2f30.org/nausea/about/

Gut - dann gibt es keinen Grund, nicht zu funktionieren! Hast du getan?
Side-by-Side-Vergleich eines Systems, auf dem ein Standard-MPD-Daemon ausgeführt wird, mit a
lokaler ncmpcpp-Client? Was passiert, wenn Sie den FIFO-Dateinamen in beiden umbenennen?
die Konfigurationsdateien? Funktioniert es noch? Ich versuche nur zu sehen, ob a
Irgendwo existiert ein fest codierter Pfad...

Am 13. Mai 2015 um 15:57 Uhr schrieb Werner Beroux [email protected] :

FFT wird vom Visualizer durchgeführt und erfordert das spezifische Audioformat
im FIFO, um dafür zu arbeiten. Referenz: http://git.2f30.org/nausea/about/

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mopidy/mopidy/issues/775#issuecomment -101702624.

Mein Kommentar basierte auf der ncmpcpp-Quelle .

Der Mute-Ausgang von Mopidy ist standardmäßig deaktiviert, dh der Ton ist nicht stummgeschaltet. Der ncmpcpp-Visualizer nimmt die Ausgabe, die Sie ihm gegeben haben, deaktiviert sie (kein Effekt) und aktiviert sie dann, wodurch das Audio stummgeschaltet wird. Wahrscheinlich sollten sie es einfach zweimal umschalten.

Das Audio im falschen Format ist eine gute Möglichkeit. Sie haben nichts in Ihrer gstreamer-Pipeline, um sicherzustellen, dass sie korrekt ist, im Gegensatz zu @adamcik in seinem obigen Code.

Schwer zu erkennen, dass das Format ein Problem sein könnte ... es ist 16-Bit-signiert
ganze Zahlen. Das Schlimmste, was passieren kann, ist, dass Sie die L/R-Kanäle vertauschen?

Am 13. Mai 2015 um 16:33 Uhr schrieb Nick Steel [email protected] :

Mein Kommentar basierte auf der ncmpcpp-Quelle
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.

Der Mute-Ausgang von Mopidy ist standardmäßig deaktiviert, dh der Ton ist nicht stummgeschaltet.
Der ncmpcpp-Visualizer nimmt die Ausgabe, die Sie ihm gegeben haben, und deaktiviert sie (nein
Effekt) und aktivieren Sie ihn, um den Ton stumm zu schalten. Sie sollten wohl
schalten Sie es einfach zweimal um.

Das Audio im falschen Format ist eine gute Möglichkeit. Du hast
nichts in Ihrer gstreamer-Pipeline, um sicherzustellen, dass es im Gegensatz zu @adamcik korrekt ist
https://github.com/adamcik hatte in seinem Code oben.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

Und selbst wenn die Byte-Reihenfolge falsch war, erwarten Sie vielleicht nur die FFT
Ausgabe, um den falschen Frequenzgang zu erzeugen ...... aber Sie würden immer noch sehen
etwas.

Am 13. Mai 2015 um 16:37 Uhr schrieb Liam Wickins [email protected] :

Schwer zu erkennen, dass das Format ein Problem sein könnte ... es ist 16-Bit-signiert
ganze Zahlen. Das Schlimmste, was passieren kann, ist, dass Sie die L/R-Kanäle vertauschen?

Am 13. Mai 2015 um 16:33 Uhr schrieb Nick Steel [email protected] :

Mein Kommentar basierte auf der ncmpcpp-Quelle
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.

Der Mute-Ausgang von Mopidy ist standardmäßig deaktiviert, dh der Ton ist nicht stummgeschaltet.
Der ncmpcpp-Visualizer nimmt die Ausgabe, die Sie ihm gegeben haben, und deaktiviert sie (nein
Effekt) und aktivieren Sie ihn, um den Ton stumm zu schalten. Sie sollten wohl
schalten Sie es einfach zweimal um.

Das Audio im falschen Format ist eine gute Möglichkeit. Du hast
nichts in Ihrer gstreamer-Pipeline, um sicherzustellen, dass es korrekt ist, anders als
@adamcik hatte https://github.com/adamcik in seinem Code oben.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

Ja, vielleicht liegt es daran, dass die Mute-Ausgabe von Mopidy aktiviert ist, was bedeutet, dass der udpsink keine Daten sendet.

cat /tmp/mdp.fifo (wie oben aus UDP erstellt) zeigt korrekt einen konstanten Datenstrom an.

Ich habe mir den ncmpcpp-Code des Visualizers angesehen:

1. öffnet die Datei als O_RDONLY | O_NONBLOCK
2. liest von oben ; Da es in meiner Mopidy-Konfiguration auf Stereo eingestellt ist, sollte es 44100:16:2 sein.

Jeder kann es auch von meinem Branch aus versuchen (nachdem er Docker installiert hat):

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

Musste einige Zeit damit verbringen, mit Netcat zu ringen, da -k bei mir nicht funktioniert hat, aber Folgendes habe ich mir ausgedacht, um es bei Songwechseln automatisch neu zu starten:

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

andere Optionen wie oben grundsätzlich.

@S0lll0s @wernight netcat -k hat bei mir auch nicht funktioniert und musste nach

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

Für Arch-Linux-Benutzer:

Um nc mit -k Unterstützung zu erhalten, müssen Sie das openbsd-netcat Paket installieren, aber es hat bei mir auch nicht funktioniert, also versuchen Sie es mit dem Skript von socat Paket, um es auszuführen.

@johnhamelink (Ich Hatten Sie Probleme mit dem Visualizer, der versuchte, "aufzuholen", nachdem Sie einen Song mit der Lösung socat angehalten haben?

@theos-space Ich kann nicht sagen, dass mir das selbst aufgefallen ist

Ich bin auf Arch und konnte es weder mit nc (sowohl gnu als auch openbsd ) oder socat . Außerdem kann ich nicht von gst-launch-1.0 ... udpsink port=5555 mit nc -kluw 1 127.0.0.1 5555 lesen, da es nichts auf dem Bildschirm ausgibt.

Kann bestätigen, dass dies auf 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 funktioniert:

starte socat im Systemstart:

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 (beachte, dass host für udpsink definiert werden musste):

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

ranisalt für Arch müssen Sie ncmpcpp mit Fifo-Unterstützung kompilieren, überprüfen Sie hier: https://bbs.archlinux.org/viewtopic.php?id=99915

Hier ist mein funktionierendes Arch-Setup, nachdem ich den Rest des Threads + Dokumente + Manpages + verschiedene Blogs gelesen habe. Ich führe Mopidy als Systemdienst aus und sende das Audio über TCP an den Benutzerdienst PulseAudio. Ich habe einige zusätzliche Anmerkungen beigefügt, die hoffentlich den weniger Erfahrenen helfen werden.

Pakete

All dies stammt aus den offiziellen Arch-Repos:

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

Konfiguration

Aktivieren Sie den mopidy-Systemdienst:

sudo systemctl enable mopidy.service

Ersetzen Sie die Systemkonfiguration von mopidy durch einen Symlink zur Benutzerkonfiguration, um die Bearbeitung zu erleichtern (optional):

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

Erstellen Sie die Fifo-Datei:

mkfifo "/tmp/mpd.fifo"

Konfigurationen

in ~/.config/mopidy/mopidy.conf (oder /etc/mopidy/mopidy.conf wenn Sie den Symlink nicht erstellt haben): Sagen Sie mopidy, dass es Audio an einen Pulsaudio-Server senden soll, der auf localhost lauscht, und an eine UDP-Senke unter localhost:5555

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

in ~/.ncmpcpp/config : Sagen Sie ncmpcpp, wo es die Fifo-Datei findet, die es anhören muss, und einige andere verschiedene Einstellungen

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

in ~/.config/pulse/default.pa : Pulsaudio anweisen, Audio über TCP von localhost zu akzeptieren (die Einstellung ist wahrscheinlich bereits vorhanden und kann einfach auskommentiert werden)

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

in ~/.zshrc (sollte auch in ~/.bashrc funktionieren): Erstellen Sie eine Wrapper-Funktion "nplayer", um das Starten und Stoppen von netcat mit ncmpcpp zu handhaben:

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

Was dies bewirkt:

• Definiere eine Funktion mit einer Subshell, die ihren gesamten Inhalt umschließt
• Starten Sie im Hintergrund einen netcat Prozess, um die an die UDP-Senke gesendeten Audiodaten abzuhören und sie an das zuvor erstellte Fifo umzuleiten. Flaggen:
  
  
  
  • -k Hören Sie weiter, nachdem die aktuelle Verbindung hergestellt wurde
  
  
  • -l Hörmodus aktivieren
  
  
  • -u UDP-Modus aktivieren
  
  
  • -w NUM Timeout inaktive Verbindungen nach NUM Sekunden (in diesem Fall 1 Sek.)
  
  
• Setzen Sie einen EXIT-Trap, um den netcat Prozess zu beenden, wenn der ncmpcpp Prozess beendet wird und bewirkt, dass die Funktions-Subshell beendet wird
• einen ncmpcpp Prozess im Vordergrund starten

Ich laufe Mopidy auf Manjaro (arch distro). Ich hatte Probleme, eine Ausgabe über socat oder netcat zu erhalten. Ich konnte jedoch die mit tcpdump eingehenden Pakete beobachten:
sudo tcpdump -i lo -n udp port 5555 -XX

Ich habe lange gebraucht und ohne
Das Problem war, dass nach udpsink nicht host=127.0.0.1 vorhanden war. Warum das bei anderen Leuten funktioniert und nicht bei mir, weiß ich nicht. Wenn Sie jedoch keine Ausgabe erhalten, ist dies möglicherweise der Fall. Diese 2 haben bei mir funktioniert:

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

oder

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

Nebenbei bemerkt: Ich konnte pulsesink zum Laufen bringen, also musste ich es bei autoaudiosink , was ich auch vorher eingestellt hatte. Allerdings scheint der Visualizer aus irgendeinem Grund wirklich sehr langsam zu sein, ich bin mir nicht sicher, ob das an autoaudiosink Funktioniert perfekt nach einem Neustart .. immer noch etwas langsam. Bei pulselink beschwerte es sich immer wieder über gstreamer-Plugins. Sogar nachdem ich (ich nehme an) jedes Plugin-Paket für gst auf den offiziellen Arch-Repos installiert habe. Beachten Sie flump3dec und mad

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

Ich habe ein Problem damit, udpsink mit Mopidy und allen Remote-ncmpcpp-Clients zum Laufen zu bringen. Mopidy wird mit MacVLAN in einer Docker-Umgebung eingerichtet. Ich kann den Port auf dem Container erfolgreich sehen.

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!

Derzeit verwendet Mopidy die folgende Konfiguration:

[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

Irgendwelche Gedanken, wie ich Netcat verwenden kann, um die Rohdaten erfolgreich in mpd.fifo zu bekommen? Die Verwendung des Folgenden funktioniert nicht, denke ich, weil ich netcat falsch verwende. Einige Recherchen haben keine Antworten geliefert, also kann mir hoffentlich jemand in die richtige Richtung weisen.

#!/bin/bash

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

Ich bekomme folgenden Fehler:

nc: Can't assign requested address

Irgendeine Idee, wie ich das zum Laufen bekomme?

Beifall!

Zu Ihrer Information Ich habe ncmpcpp Unterstützung für udpsink von gstreamer hinzugefügt, sodass es jetzt ohne Fifo-Hacks direkt verwendet werden kann.

Weitere Informationen finden Sie unter https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 .

Unten ein Teaser. Dies ist mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

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

@arybczak Genial ! Sie sollten dies auf https://discourse.mopidy.com/c/show-and-tell/9 posten

@adamcik Bedeutet dies nicht, dass dieses fast 7-jährige Problem zugunsten einer besseren Lösung des realen Problems, das es ausgelöst hat (Unterstützung von Visualisierungen in ncmpcpp) "veraltet" wird?

@pspeder , was meinst du genau? Gibt es ein Problem bei der Verwendung von https://github.com/mopidy/mopidy/issues/775#issuecomment -747725806 ?

@kingosticks Hat nur vorgeschlagen, dass dieses Problem geschlossen wird 🙂

Dem stimme ich zu.