DIY Audioplayer

FoLLgoTT · Beitrag von **FoLLgoTT** » 31.08.2015, 22:16

Hallo Simon,

Daihedz hat geschrieben:1. Könntest Du mehr davon preisgeben?
2. Könntest Du ggf. mit den Entwicklern von MDP schauen, ob die Deinen Code einpflegen möchten?

zu 1. klar.

Vor dem Öffnen der Pipe wird nach bestimmten Variablennamen in dem Kommando gesucht. Ich habe z.B. $samplerate und $bits gewählt. Aber das ist ja im Grunde beliebig. Diese werden dann durch die realen Werte des Streams ersetzt, also z.B. 44100 und 16. Mehr ist das nicht.

Das Script muss anschließend selbst dafür sorgen, dass es die Parameter korrekt auswertet. In meinem Fall wird damit direkt SOX gefüttert, dass auf 192.000 kHz und FLOAT_64 konvertiert. Somit kann die Signalkette praktisch alles annehmen, was man sich vorstellen kann.

zu 2.
Ich habe die Datei mal in das MPD-Forum gestellt mit der Bitte, dass es jemand einpflegt. Ich bin kein Linux-Open-Source-Entwickler und kenne das ganze Drumherum nicht. Und es ist immer gut, wenn jemand von den MPD-Entwicklern einmal rüberschaut und die Änderung an die Code-Konventionen anpasst usw.

Gruß
Nils

RS.schanksaudio · Beitrag von **RS.schanksaudio** » 01.09.2015, 12:13

Hallo zusammen,

Ich habe seit knapp 2 Wochen den neu erschienen ODROID C+ mit 16GB eMMC Karte, USB-SPDF Interface, WLAN-Stick, Fernbedienung und dem einfachen Stecker-Schaltnetzteil (5V/2A) in Betrieb (alles von Hardkernel via pollin.de) – summiert sich dann doch auf ca 150 €.

Volumio 1.55 läuft problemlos (es gibt ein eigenes Image), nur die Anbindung des NAS war etwas hakelig. Volumio ist insgesamt doch etwas spartanisch, daher werde ich wohl auch Runeaudio probieren, auch hier gibt es seit kurzem eine eigene Version für den Odroid.

Mal schauen wohin es führt, ich werde ab und zu hier berichten.

Viele Grüße
Roland

--
Weiterführende Links:

http://www.hardkernel.com/main/products ... 3703355573
http://odroid.com/dokuwiki/doku.php?id=en:odroid-c1
http://www.hardkernel.com/main/products ... 0081048224
http://sourceforge.net/projects/volumio ... roid%20C1/
http://www.runeaudio.com/forum/odroid-c ... t1343.html
http://www.pollin.de/shop/suchergebnis. ... g=internal

Daihedz · Beitrag von **Daihedz** » 01.09.2015, 19:40

Hallo Martin

Martin hat geschrieben:... Brutefir lasse ich auch mit der Samplerate 44100 laufen, weil damit die Frequenzauflösung im Tieftonbereich am besten ist. ...

Warum soll denn dem so sein? Meinst Du vielleicht implizit "... bei gleichbleibender Filterlänge ...", dann würde dies nach m.E. stimmen. Aber dann könnten, um gleich Abhilfe zu schaffen, auch entsprechend längere Filter einsetzt werden. Ich jedenfalls werde bis zum Auftauchen eines wirklich triftigen Gegenarguments so lange Filter und so hohe SR wie nur möglich von Brutefir rechnen lassen.

Aktuell falte ich mittels Brutefir 8 Kanäle mit 128k Filterlänge, 192khz SR bei 64Bit und lasse dies per sox vor der Ausgabe auf 32Bit/96kHz zurückrechnen (weil meine derzeitig produktive Soundkarte 192kHz nicht "kann"). Experimentell werkelt aber auch schon eine Xonar STX II 7.1 bei mir sporadisch vor sich hin, mit welcher dann 8 Kanäle mit 192kHz möglich sein sollten. Bei DA@192kHz müssten dann Befürchtungen wegen Filterartefakten in der Passband endgültig vom Tisch sein.

Grüsse
Simon

FoLLgoTT · Beitrag von **FoLLgoTT** » 01.09.2015, 20:19

Hallo,

Daihedz hat geschrieben:Warum soll denn dem so sein? Meinst Du vielleicht implizit "... bei gleichbleibender Filterlänge ...", dann würde dies nach m.E. stimmen.

So ist es. Ich habe den Entwickler von Brutefir schon gefragt, ob er unterschiedliche Sampleraten für die einzelnen Kanäle unterstützen wird, aber er macht leider nur noch Fehlerbehebung. Man könnte dann den Basskanal z.B. mit 8 kHz laufen lassen, was Taps und Rechenzeit spart. K+H und Four Audio machen das bei ihren FIR-Controllern auch so.

Aber naja, Rechenleistung ist ja heutzutage kein Thema mehr. Zumindest nicht für diese Anwendung.

Gruß
Nils

Tinitus · Beitrag von **Tinitus** » 01.09.2015, 22:00

Hallo Roland,

viel Spaß mit dem C1+. Gab es als Du bestellt hast auch schon das HIFI Shield? Ich hatte Probleme mit meinem Odroid Standard Wifi Dongle eine stabile Verbindung zwischen WebUI und Odroid aufzubauen. Das lag daran, dass das RuneAudio zugrundeliegende ArchLinux zwei verschiedene Treiber für den im Dongle verwendeten Chipsatz laden wollte Lösung des Problems (falls es immer noch existiert) findest Du hier:

http://www.runeaudio.com/forum/port-run ... 02-40.html

Meiner Meinung nach ist RuneAudio Volumio von der Bedieneroberfläche um Längen voraus. Die Jungs von RuneAudio haben ja auch die WebUI von Volumio programmiert, seit die sich getrennt haben, scheint sich bei Volumio hinsichtlich der WebUI nichts mehr zu tun.

Gruß

Uwe

frankl · Beitrag von **frankl** » 04.09.2015, 00:56

Hallo Roland,

freut mich, dass so ein Odroid C1+ bei Dir jetzt gute Dienste tut. Weißt Du, ob es Pläne gibt, die verschiedenen DAC Ergänzungsboards für den Raspy auch für den Odroid anzubieten?

RS.schanksaudio hat geschrieben: Volumio 1.55 läuft problemlos (es gibt ein eigenes Image), nur die Anbindung des NAS war etwas hakelig. Volumio ist insgesamt doch etwas spartanisch, daher werde ich wohl auch Runeaudio probieren, auch hier gibt es seit kurzem eine eigene Version für den Odroid.

Bezieht sich das "spartanisch" auf die Oberfläche (dann kann ich nichts dazu sagen) oder auf die darauf installierte Software (Volumio ist ja unter anderem ein Debian Wheezy, man kann also via apt-get im Nu Unmengen von zusätzlicher Software installieren)?

Viele Grüße,
Frank

RS.schanksaudio · Beitrag von **RS.schanksaudio** » 04.09.2015, 09:04

Hallo zusammen,

Tinitus hat geschrieben: Gab es als Du bestellt hast auch schon das HIFI Shield?

Der HiFi Shield war vor zwei Wochen hier bei uns noch nicht verfügbar, Pollin scheint es jetzt aber im Sortiment zu haben. Es war aber auch nie mein Plan analog zu wandeln, sondern entweder via USB oder SPDIF digital raus in einen dedizierten DAC, bzw Aktivbox. Die kleine Box (Odroid USB-SPDIF mit CMedia CM108AH Chip) die ich jetzt dazu habe scheint sowohl unter Volumio als auch Runeaudio als USB-Device erkannt und auch der GUI direkt auswählbar. Gehört habe ich noch nicht, weil ich für den Moment boxenlos bin

Tinitus hat geschrieben: Ich hatte Probleme mit meinem Odroid Standard Wifi Dongle eine stabile Verbindung zwischen WebUI und Odroid aufzubauen. Das lag daran, dass das RuneAudio zugrundeliegende ArchLinux zwei verschiedene Treiber für den im Dongle verwendeten Chipsatz laden wollte Lösung des Problems (falls es immer noch existiert) findest Du hier:
http://www.runeaudio.com/forum/port-run ... 02-40.html

Mein WLAN Stick (Odroid WiFi Module 4 mit MediaTek RT5572N Chip, Dualband 300Mbps) funktionierte plug'n'play und war ohne reboot direkt in Volumio und Runeaudio nutzbar. Mittelfristig werde ich aber kabelgebunden an eine WLAN bridge gegen, die in der Nähe steht.

Tinitus hat geschrieben: Meiner Meinung nach ist RuneAudio Volumio von der Bedieneroberfläche um Längen voraus. Die Jungs von RuneAudio haben ja auch die WebUI von Volumio programmiert, seit die sich getrennt haben, scheint sich bei Volumio hinsichtlich der WebUI nichts mehr zu tun.

Ich nutze seit gestern Runeaudio, das beta-Image funktioniert soweit. Man sieht schon die gemeinsame Codebasis, es ist alles sehr ähnlich mit leichten Vorteilen für Runeaudio. Die Einrichtung bei Runeaudio ging mir etwas einfacher von der Hand und insgesamt scheint dort die Entwicklung schneller voranzuschreiten.

frankl hat geschrieben: Weißt Du, ob es Pläne gibt, die verschiedenen DAC Ergänzungsboards für den Raspy auch für den Odroid anzubieten?

Dazu kann ich nicht viel sagen. Aber insgesamt wird es bei Raspi immer viel mehr Auswahl geben, weil er deutlich mehr verbreitet ist – Odroid ist da eher der Underdog. Der Odroid-Hersteller Hardkernel wird sicherlich noch einige Boards bringen, das ist mit dem HiFi-Shield DAC auch schon passiert. Über I2S sollten zumindest elektrisch alle Raspi Erweiterungsboards passen, aber eben nicht physisch, weil die Platine anders ist.

frankl hat geschrieben: Bezieht sich das "spartanisch" auf die Oberfläche (dann kann ich nichts dazu sagen) oder auf die darauf installierte Software (Volumio ist ja unter anderem ein Debian Wheezy, man kann also via apt-get im Nu Unmengen von zusätzlicher Software installieren)?

Ja, das meint nur die GUI und das Handling. Wenn man mal die nativen Apps von Sonos, Auralic Aries, Linn etc gesehen hat, dann mutet die Web-Gui der Open-Source Projekte sehr minimalistisch – das ist kein Vorwurf oder Abwertung, aber dessen sollte man sich bewusst sein.

Viele Grüße
Roland

Tinitus · Beitrag von **Tinitus** » 04.09.2015, 23:24

Hallo Roland,

kleiner Geizhals der ich bin habe ich das Wifi Modul 3 mit dem Realtek8192cu gekauft, mit dem kann es in ArchLinux probleme geben. Mit dem Media Tek chip gibt es anscheinend keine Probleme. Ich habe mir jetzt noch einen TP-Link mit Ateros chip bestellt, der blinkt auch nicht die ganze Zeit.

Gruß

Uwe

Tinitus · Beitrag von **Tinitus** » 25.01.2016, 20:42

Hallo,

nach dem ich eine ganze Zeit lang einfach nur zufrieden Musik gehört habe, hat mich der Thread um den Soekris DAC aufgerüttelt. Ich habe meine personalisierte RuneAudio Installion geklont und damit meinen zweiten C1 aufgesetzt, jetzt kann ich gleichzeitig Musik hören und Experimente mit einer Pipe machen. Da ich ein fauler Hund bin, möchte ich nicht endlos viele Filter für brutefir machen müssen. Das heißt meine Idee ist es, in brutefir mit einer festen Samplerate rein zu gehen, wie ich in Martins Beispiel gesehen habe, kann man die pipe zu brutefir ausgeben und dann an sox weiterleiten. Für mich stellt sich die Frage, ob ich mpd das sampling auf eine feste Rate machen lassen soll. Wenn ich es richtig verstehe ist der Algorythmus den mpd dafür verwendet nicht der beste. Ich kann aber anscheinend mpd auch mitteilen, es solle sich bitte der soxr Bibliothek bedienen. Die scheint ja besser beleumundet. Frage dies hier:

Code: Alles auswählen

resampler {
  plugin "soxr"
  quality "very high"
}

kann ich einfach irgendwo in der mpdconf Datei einflicken oder muss ich da eine bestimmte Reihenfolge einhalten?

Hat jemand die Erfahrung, was das an Ressourcen braucht? Nicht dass sich der C1 "verschluckt" zumal anschließend dann gefaltet werden soll (24/196) und dann nochmal hochgesampelt auf 32/192 mit denen ich dann in den DAC reingehe. Idee wäre also mpd mit soxr Bibliothek auf 24/192 sampeln zu lassen, Übergabe an brutefir Faltung online und dann samplen auf 32/196 und in den DAC. Wäre mpd --->sox--->brutfir--->sox besser (klanglich)? Was wäre ressourcenschonender? Eventuell könnte man hintendran ja noch Volrace zur Lautstärkeregelung dran hängen. Könnte man das in der mpd conf noch hinter die Kette brutefir sox direkt hintendran hängen? Kann man Volrace per IR Fernbedienung steuern? IR Empfänger ist beim Odroid ja an Board.

Fragen über Fragen

Gruß

Uwe

Daihedz · Beitrag von **Daihedz** » 25.01.2016, 23:18

Hallo Uwe

MPD macht bei mir keinerlei Konvertierungen. Ich experimentiere derzeit mit mpd und der Pipe-Ausgabe, welche mit dem Patch von Nils (FoLLgoTT) versehen ist. Die MPD-Pipe fragt dank des hübschen Patches das Audio-Format ($channels, $samplerate und $bits) des aktuellen Streams ab und hinterlegt die Werte in provisorische Dateien. Danach wird der Stream an frankl's writeloop weitergegeben. Und catloop liest das Ganze in eine weitere, MPD-externe Audiopipe mit allen Nachbearbeitungsschritten ein. Fertig. Das heisst, immer, wenn MPD eine Audioausgabe macht, ist das Format in Dateien hinterlegt, und die Audiodaten sind dank writeloop nach einer beliebigen Pause im shm abholbar.

Dann wird eine zweite Pipe gestartet. Catloop holt die Daten aus dem shm, gibt sie zuerst dann an zweimal Sox zur Konvertierung weiter. Die Parameter von Sox können zuerst entsprechend aus den zuvor in der Pipe generierten Dateien eingelesen werden. Dann geht das Ganze, von Sox einheitlich für Volrace und Brutefir formatiert, an diese Programme weiter. Dann wird für den Audio-Ausgang mittels zweimal Sox nochmals zurückgewandelt und es geht weiter an aplay oder playhrt. Klappt im Protostadium ganz gut.

Die MPD-Pipe sieht in etwa so aus:
echo $bits > /home/xyz/_mpd/bits ; echo $samplerate > /home/xyz/_mpd/samplerate ; ... writeloop

Dann erfolgt im Startscript sowas wie:
...
... starten von MPD:
mpd config_xy
...
... Auslesen des Audio-Formats
mpd_bits=$(cat /home/xyz/_mpd/bits)
mpd_samplerate=$(cat /home/xyz/_mpd/samplerate)
...
... und dann die Audiopipe prinzipiell à la
catloop | sox ($mpd_bits -> 64 /signed-integer -> floating-point) | sox ($mpd_samplerate -> 192000) | volrace | brutefir | sox (192000 -> 96000) | sox (64 -> 32 / float -> signed-integer ) | aplay / playhrt

Ich konvertiere mit separaten Sox-Instanzen je für die SR und das übrige Format, d.h. es laufen in der voll funktionalen Pipe 4 Sox-Instanzen. Natürlich frisst sox die Parameter nicht so, wie oben angegeben. Das ist bloss eine Prinzip-Darstellung.

Zu Bedenken ist noch: Die Pipe gibt eine 24-Bit-Datei genau gleich wie eine 32-Bit-Datei 32-bittig aus, jedoch 8 Bit leiser. D.h., in der sox-Formatumwandlung muss bei 24-Bit-Dateien noch eine entsprechende Kompensation mittels "sox -b 24 ... - -b 64 ... - vol 48dB" vogesehen werden. Sonst wird es sehr leise.

Ob dies die beste Lösung sei, bleibt dahingestellt ... Aber es funktioniert bei sämtlichen Audiodateien und mit bloss einer einzigen Samplerate in Brutefir. Und ausgegeben wird auch immer gleich, im obigen Prinzipbeispiel im S32_LE Format bei 96K SR.

Brutefir generiert dabei die grösste Prozessorlast.

Experimentierende Grüsse
Simon

frankl · Beitrag von **frankl** » 26.01.2016, 01:08

Tinitus hat geschrieben: Hat jemand die Erfahrung, was das an Ressourcen braucht? Nicht dass sich der C1 "verschluckt" zumal anschließend dann gefaltet werden soll (24/196) und dann nochmal hochgesampelt auf 32/192 mit denen ich dann in den DAC reingehe. Idee wäre also mpd mit soxr Bibliothek auf 24/192 sampeln zu lassen, Übergabe an brutefir Faltung online und dann samplen auf 32/196 und in den DAC. Wäre mpd --->sox--->brutfir--->sox besser (klanglich)? Was wäre ressourcenschonender?

Hallo Uwe,

zur genauen mpd-Konfiguration kann ich nichts sagen. Aber eine Einstellung zu finden, die sox zum resamplen benutzt, ist sicher sinnvoll.

Ich nehme mal an, Du meinst oben immer "192" statt "196". Wieso willst Du die Daten zuerst auf 24/192 vor dem Falten samplen? brutefir benutzt ohnehin intern 32 oder 64 bit floating point. Ich würde daher gleich auf 32/192 resamplen und dann in brutefir für die Ein- und Ausgabe 32/192 verwenden.

Die Resourcen für das Resampling sind eher gering im Vergleich zum Falten (kommt natürlich auf die Filterlängen an).

Tinitus hat geschrieben: Kann man Volrace per IR Fernbedienung steuern? IR Empfänger ist beim Odroid ja an Board.

Weiter oben hat Nils schon berichtet, dass er das macht.
Wenn Du die Fernbedienung in Gang gebracht hast, kannst Du doch beliebige Skripte auf die Tasten legen, oder? Dann ist es kein Problem, etwa volrace oder brutefir damit zu steuern.

Viele Grüße,
Frank

Sire · Beitrag von **Sire** » 26.01.2016, 07:38

Hallo Uwe,

um IR zu nutzen, brauchst Du "lirc". Im Rune-Forum gibt es Hinweise zur Installation und Konfiguration. Du kannst dann auch eine bereits vorhandene Fernbedienung nutzen. Im entsprechenden Konfig-File "lircrc" definierst Du die auszuführenden Aktionen. Die richtigen volrace-Parameter dafür kannst Du per "volrace -h" in Erfahrung bringen.
Falls Du dazu noch Fragen hast, könnte ich versuchen Dir zu helfen.

Viele Grüße

Klaus

Daihedz · Beitrag von **Daihedz** » 26.01.2016, 18:27

Hallo MPD-Interessenten

Mit diesen Pipes spielt MPD alle möglichen Formate (von 44/16 bis 96/32) über eine einzige Brutefir-Config mit einem einzigen Filtersatz.

Voraussetzung ist, dass ein aktueller Patch von Nils (FoLLgoTT) statt der regulären PipeOutputPlugin.cxx compliert wird. Denn mit diesem Patch ist es möglich, das Format des Audiostreams auszulesen. Leider hat der Patch noch nicht Eingang in die Standard-Sources von MPD gefunden.

MPD-Config Pipe-Version mit Aplay:

Code: Alles auswählen

    command "if [ $bits = 16 ] ; then inbits=16 && vol24bits='' ; elif [ $bits = 24 ] ; then inbits=32 && vol24bits='vol 48dB' ; elif [ $bits = 32 ] ; then inbits=32 && vol24bits='' ; fi ; chrt -r 93 taskset -c 1 sox --buffer 1024 -b $inbits -c $channels -D -e signed -r $samplerate -t raw - -b 64 -c 2 -e floating-point -r $samplerate -t raw - $vol24bits | chrt -r 93 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r $samplerate -t raw - -t raw - vol 0.8 rate -v -I 192000 | chrt -r 94 taskset -c 1 volrace --buffer-length=8192 --param-file=/home/privat/_frankl/volrace.tmp --verbose | chrt -r 95 taskset -c 1 brutefir /home/privat/_brutefir/lr-ms/brutefir_config_lr-ms | chrt -r 96 taskset -c 1 sox --buffer 32768 -b 64 -c 2 -D -e floating-point -r 192000 -t raw - -t raw - vol 0.8 rate -v -I 96000 | chrt -r 96 taskset -c 1 sox --buffer 16384 -b 64 -c 2 -D -e floating-point -r 96000 -t raw - -b 32 -c 2 -e signed -r 96000 -t raw - dither -f high-shibata | chrt -r 99 taskset -c 1 aplay --buffer-size=65536 --channels=2 --device=hw:0,0 --disable-channels --disable-format --disable-resample --disable-softvol --format=S32_LE --mmap --quiet --rate=96000 -t raw --verbose "

MPD-Config Pipe-Version mit Playhrt:

Code: Alles auswählen

    command "if [ $bits = 16 ] ; then inbits=16 && vol24bits='' ; elif [ $bits = 24 ] ; then inbits=32 && vol24bits='vol 48dB' ; elif [ $bits = 32 ] ; then inbits=32 && vol24bits='' ; fi ; chrt -r 93 taskset -c 1 sox --buffer 1024 -b $inbits -c $channels -D -e signed -r $samplerate -t raw - -b 64 -c 2 -e floating-point -r $samplerate -t raw - $vol24bits | chrt -r 93 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r $samplerate -t raw - -t raw - vol 0.8 rate -v -I 192000 | chrt -r 94 taskset -c 1 volrace --buffer-length=8192 --param-file=/home/privat/_frankl/volrace.tmp --verbose | chrt -r 95 taskset -c 1 brutefir /home/privat/_brutefir/lr-ms/brutefir_config_lr-ms | chrt -r 96 taskset -c 1 sox --buffer 32768 -b 64 -c 2 -D -e floating-point -r 192000 -t raw - -t raw - vol 0.8 rate -v -I 96000 | chrt -r 96 taskset -c 1 sox --buffer 16384 -b 64 -c 2 -D -e floating-point -r 96000 -t raw - -b 32 -c 2 -e signed -r 96000 -t raw - dither -f high-shibata | chrt -r 99 taskset -c 1 playhrt --buffer-size=65536 --device=hw:0,0 --extra-bytes-per-second=0 --extra-frames-out=24 --hw-buffer=2048 --loops-per-second=1000 --mmap --non-blocking-write --number-channels=2 --sample-format=S32_LE --sample-rate=96000 --sleep=500000 --stdin "

Noch etwas: Der mir zur Verfügung stehende (vielleicht frühe) Original-Patch von Nils unterscheidet bei 24-Bit und 32-Bit Dateien (noch) nicht. In beiden Fällen wird für $bits der Wert=32 ausgegeben. Ich habe deshalb für meine Zwecke den Patch gepatcht ...

Original-Nils-Gepatchte PipeOutputPlugin.cxx (Ausschnitt):

Code: Alles auswählen

 
...
       switch(audio_format.format)
        {
        case SampleFormat::S8: bits = "8"; break;
        case SampleFormat::S16: bits = "16"; break;
        case SampleFormat::S24_P32:
        case SampleFormat::S32: bits = "32"; break;
        case SampleFormat::FLOAT: bits = "FLOAT_32"; break;
        case SampleFormat::DSD: bits = "DSD"; break;
        default: break;
        }
...

24-Bit-Patch:

Code: Alles auswählen

 
...
       switch(audio_format.format)
        {
        case SampleFormat::S8: bits = "8"; break;
        case SampleFormat::S16: bits = "16"; break;
        case SampleFormat::S24_P32: bits = "24"; break;
        case SampleFormat::S32: bits = "32"; break;
        case SampleFormat::FLOAT: bits = "FLOAT_32"; break;
        case SampleFormat::DSD: bits = "DSD"; break;
        default: break;
        }
...

Thatsit. Vollautomatisch (t)switsche(r)nd.
Simon

Sire · Beitrag von **Sire** » 27.01.2016, 20:01

Hallo Simon,

jetzt müsste ich nur noch mein MPD patchen.

Herzlichen Dank fürs Veröffentlichen Deiner Pipe.

Viele Grüße

Klaus

Tinitus · Beitrag von **Tinitus** » 28.01.2016, 20:21

Hallo Jungs,

allen die etwas zu meiner Fragestellung geschrieben haben, erst mal vielen Dank. Das muss ich erst mal verarbeiten. Leider habe ich im Moment nur wenig Zeit, melde mich aber bestimmt demnächst (mit neuen Fragen).

LG

Uwe