Seite 7 von 21

Verfasst: 09.12.2015, 09:57
von koslowj
Hallo Frank,

Danke fuer die Klarstellung und den Hinweis auf die moegliche Groesse der RAM-Disc! Werde ich nachher gleich ausprobieren.

Was DSD angeht, so koennte die erweiterte Sox-Version evtl. diese Konvertierung besser hinbekommen, falls direktes Abspielen nicht erwuensscht/moeglich ist. DSD-over-PCM (DoP) beherrscht sie auch. Die Hauptarbeit meiner Raumkorrektur macht ja bereits der Verstaerker (Lyngdorf TDAI 2170 mit RoomPerfect).

Eine Anmerkung zur Hardware (hoffentlich in diesem Thread erlaubt): nachdem der vor knapp einem Jahr bei Heise vorgestellte Mini-Rechner fitlet-B in Deutschland nie in den Handel gekommen zu sein scheint (man kann ihn in England zu einem wesentlich hoeheren Preis erwerben), war ich ja auf einen Voyage Starter Kit ausgewichen. Ein Odroid C1+ kommt mit 1 GB Speicher wegen der RAM-Disc-Problematik nicht in Frage, ein Odroid XU4 mit 2 GB hat leider von Hause aus einen Luefter, wenn es auch Bastelloesungen mit passiver Kuehlung gibt. Ein potentieller Konkurrent ist jetzt aufgetaucht: LattePanda. Seltsamerweise fuer Windows 10 gedacht, aber hoffentlich auch bald mit Linux einsetzbar.

Vorteile gegenueber dem XU4: luefterlos und mit 4 GB lieferbar, vielleicht Daphile-geeignet
Nachteile: langsameres Ethernet

Bisher verwende ich ja ueber ein HUB angeschlossene Festplatten. 100Mbit Ethernet sollten doch kein Hindernis fuer einen etwaigen kuenftigen NAS-Betrieb sein, oder?

Beste Gruesse,

-- Juergen (dem mal wieder seine Umlaute abhanden gekommen sind, tut mir Leid!)

Verfasst: 09.12.2015, 22:14
von Tinitus
Hallo Jürgen,

als Linux Analphabet habe ich es irgendwann mal aufgegeben mir eine Lösun selbst zu stricken (so sehr mich das reizt mir bleibt keine Zeit dazu). Deshalb nutze ich inzwischen RuneAudio. Ich habe zunächst auch mit einer RAM-disk experimentiert, ging natürlich nur bis 640 MB. Für ein red book album reichte es meist, HiRes habe ich dann auf die eMMc kopiert und von dort gespielt. Seit ich aber meine Musik auf einer SSD habe, nutze ich den Puffer 512 kB und lasse ihn vor dem Start zu 30 % füllen. Dann spielt RuneAudio die Musik aus dem RAM. Wenn ich mich nicht irre gibt es in Franks Sammlung auch ein Script, welches das gleiche macht. Langer rede kurzer Sinn, meiner meinung nach muss nicht das komplette Album auf einmal ins RAM geladen werden, um die Musik aus dem RAM spielen zu können. Dann braucht es auch keine 2 GB RAM. Ich bin mit dem C1 sehr zufrieden, der C1+ kann ja zusäzlich I2S ausgeben und hat nicht die unsägliche Busteilung wie sie der RPi hat. Für mich ist der C1+ somit dem RPi deutlich überlegen. Rechenauslastung bei mir wenn 24/176 gespielt wird wahnsinnige 5 %. Fehlt nur noch, dass ich mich mal mit DRC beschäftige, aber auch dazu fehlt mir die Zeit. Mein Traum mpd in sox alles auf 24/96 wandeln (USB1.0 kompatibel) dann mit brutefir online falten und durch einen Adum zwecks galvanischer Trennung und dann in den DAC. Wie wichtig die galvanische Trennung ist, scheint ja die Wirksamkeit des afis unter Beweis zu stellen.

Gruß

Uwe

Gruß

Verfasst: 10.12.2015, 17:04
von koslowj
Hallo Uwe,

Danke für die Anregungen! RuneAudio habe ich eine Zeitlang verwendet, von einem Raspberry Pi aus mit HifiBerry Digi+ Board, via Coax an den Verstärker angeschlossen. Das hörte sich auch gar nicht schlecht an und war sehr komfortabel in der Bedienung (vor allem an meiner Verzeichnisstruktur orientiert, statt an irgendwelchen obskuren Tags). Allerdings war mir ein Denkfehler unterlaufen, da der beste (und DSD-fähige) Eingang meines Verstärkers so brach lag (USB-Ausgabe ist ja keine Stärke des RasPis).

Dann fand ich Franks Vorschläge hier im Forum und seine Programme, und die wollte ich unbedingt ausprobieren. Im Vergleich (Rune via Coax, anderer Rechner via USB) höre ich inzwischen doch einen Unterschied (kann natürlich auch am Eingang liegen). In der Hoffnung, evtl. Daphile installieren zu können (was sich bisher als schwierig erwies), war der 2. Rechner x86-basiert, ein Rune-Port darauf existiert noch nicht. Voyage Linux verwendet zwar auch MPD (und kann somit DSD abspielen), ist aber bei weitem nicht so komfortabel wie Rune (oder Daphile).

Ich habe einfach Franks Skripte im bin-Verzeichnis von Voyage Linux installiert und kann sie per ssh vom Notebook oder Handy aus aufrufen. Das müßte bei Rune doch auch möglich sein (momentan ist der RasPi nicht angeschlossen). Noch macht das Basteln ja auch Spaß... ;-)

Beste Grüße,

-- Jürgen

Verfasst: 10.12.2015, 19:52
von Sire
Hallo Jürgen,

Franks Programme laufen auch in RuneAudio und lassen sich per ssh starten. Etwas komfortabler ist es (Bastelarbeit vorausgesetzt), die Scripte dann mit einer Fernbedienung zu starten (via lirc).

Ich könnte mir vorstellen, dass es für jemanden mit php-Programmierkenntnissen sogar möglich ist, das WebUI so anzupassen, dass die Steuerung der Scripte auch darüber geht...

Gruß

Klaus

Verfasst: 10.12.2015, 21:42
von Pittiplatsch
Hallo @all,

eine kurze Frage an die Linux und vor allem sox Experten. Wenn ich raw in wav umwandle mit komplett gleichen Daten (bittiefe, sample rate etc. ) scheint dennoch ein resampling stattzufinden:

sox -traw -c1 -r41100 -efloat -b32 /tmp/channel_0.pcm -twav /tmp/test1c.wav

das erhaltene test1c.wav ist sage und schreibe 0,1 s laenger wenn ich es in audacity anschaue:

Bild

Bei Rueckumwandlung in ein raw file passt es wieder - ist also umkehrbar. Oder ist es ein Audacity - Darstellungsproblem?

Viele Gruesse,
Tobias

Verfasst: 20.12.2015, 01:16
von koslowj
Hallo und einen schönen 4. Advent ;-)

Wie schon erwähnt gibt es eine SoX-Variante die zwischen DSD und PCM konvertieren kann und die auch dop beherrscht: https://github.com/mansr/sox
Beim zweiten Versuch habe ich diese nun auch auf dem Debian-basierten Voyage Linux kompilieren können.
Die Beispiele in der Diskussion http://www.computeraudiophile.com/f11-s ... sox-25556/ befassen sich mit der Konvertierung PCM --> DSD, bzw. mit dem Umsampeln von DSD, leider fehlt ein Beispiel für die Konversion DSD --> PCM bzw. für die korrekte Anwendung von dop. Und nun merke ich, wie unschön die SoX-Syntax ist...; habe bisher nichts Brauchbares hinbekommen.

"play file.dff" liefert zwar eine Ausgabe, aber mit starkem Rauschen unterlegt
"play file.dff dop" liefert die Fehlermeldung "play FAIL dop: incorrect output rate, should be 176.4k"
"play file.dff rate -v 176400" rauscht wie oben
"play file.dff rate -v 176400 dop" liefert die Fehlermeldung "play FAIL dop: 1-bit input required"

In der man-Datei findet man nur

dop: DSD over PCM. 1-bit DSD data is packed into 24-bit samples for
transport over non-DSD-aware links.
^^^^^^^^^^^^^^^^^
das sollte für meinen Verstärker zutreffen

Vielleicht hat jemand eine Idee?

-- Jürgen

Verfasst: 26.04.2016, 09:53
von koslowj
Hallo nach einer langen Pause,

Nach dem Umstieg auf neue Hardware (Zotac Zbox CI 323 nano mit kleiner SSD und hinreichend RAM) kann ich nun sowohl Daphile als auch Franks Programme auf derselben Hardware nutzen. Letzteres erforderte die parallele Installation einer weiteren Linux Distribution, die alternativ zu Daphile gebootet werden kann (Daphile ist der Default, ist sehr nutzerfreundlich, wird aktiv weiterentwickelt und kann auch dsd abspielen, in meinem Fall mittels dop (dsd over pcm)). Hörtests stehen allerdings noch aus, ich freue mich erstmal, dass es überhaupt so geklappt hat, wie ich mir das vorgestellt habe. Auch als langjähriger Linux Nutzer (wenn auch nicht wirklich Administrator) lernt man dabei eine Menge ;-)

Beste Grüße,

-- Jürgen

Verfasst: 26.04.2016, 13:06
von Sire
Hallo Jürgen,

erstmal Glückwunsch zur gelungenen Installation. Hoffentlich funktioniert alles so, wie Du es Dir wünschst. Jedenfalls bin ich auf Deine Hörvergleiche sehr gespannt.

Viele Grüße

Klaus

Verfasst: 05.12.2016, 00:40
von frankl
Hallo Forenten,

leider scheint die URL unter frankl.bitbucket.org, über die die Programme, über die ich in diesem und anderen Threads berichtet habe, sowie einige Erklärungen dazu zu finden waren, nicht mehr von bitbucket unterstützt zu werden. Das ist wirklich ärgerlich, da laut Forums-Suche in über 30 Beiträgen darauf verlinkt wurde, und diese Links nun alle nicht mehr funktionieren.

Ich habe mir nun eine nachhaltigere Lösung ausgedacht, von der ich hoffe, dass sie auf absehbare Zeit stabil funktionieren wird. Diese ist ab jetzt über
http://frankl.luebecknet.de/stereoutils/index.html
zu erreichen.
(Das git-Repository für den Code bleibt erstmal auf bitbucket.org.)

An dieser Stelle ganz herzlichen Dank an gleich drei Forenten, die mich auf das Problem aufmerksam gemacht haben!

Viele Grüße,
Frank

Verfasst: 14.12.2017, 22:25
von Daihedz
Hallo in die Streaming-Runde

Ich spiele im Moment mit einem server-client-setup. Der Server ist ein Laptop, der Client ist Teil eines Mehrwege-Lautsprechers. Laptop-Server und Lautsprecher-Client kommunizieren über das Netzwerk. Das ganze funktioniert einwandfrei dank der von frankl zur Verfügung gestellten Programme writeloop und catloop.

Serverseitig werden wie gewohnt die gewünschten Musikquellen ausgewählt und abgespielt, seien es Youtube-Inhalte, die Naxos Library, eine lokale *wav-Sammlung via MPD oder via Aplay. Die Wiedergabe erfolgt jedoch nicht lokal über die Soundkarte auf dem Server, sondern wird mittels einer spezifischen ALSA-Konfiguration in eine Pipe geleitet. Diese Pipe wird an einen Puffer weitergegeben, welcher mittels writeloop aufgesetzt wird. Writeloop stellt die erste Portion Audiodaten solange im shared memory /dev/shm bereit, bis sie abgerufen werden. Diese Files werden in der Folge von catloop gelesen und an sox (Formatkonvertierung), dann an brutefir (loco & drc), weiter an volrace (volume control & race) und schliesslich an netcat weitergegeben.

1. Audioquelle -> writeloop
2. catloop -> sox -> brutefir -> volrace -> ncat.

Clientseitig wird mittels ncat der Port des Servers abgefragt. Sobald Daten anstehen, gibt ncat die information an brutefir (x_over), dann an sox, weiter an playhrt zur Mehrkanalsoundkarte weiter.

ncat -> brutefir -> sox -> playhrt -> [Soundkarte]

Damit lässt sich ein System aufbauen, welches im ersten Rechner, z.B. einem Laptop mit Browser, alles beinhaltet, um zunächst einen 2-Kanal-Audiostream ans Netz bereitzustellen. Der zweite Rechner ist lautsprecherseitig, resp. gehört zum aktiven Lautsprecher, lauscht ständig am Netz und verarbeitet die Audio-Informationen, sobald welche zur Verfügung stehen.

Um eine möglichst sorgfältige Bearbeitung der Audioinformationen zu gewährleisten, arbeiten beide Brutefirs und Volrace mit dem Format 192000/64. Das ist denn auch das Format des 2-Kanal-Datenstroms, welcher über das Netz geht.

Kernstück für das Ganze ist die Datei .asoundrc, welche im Heimverzeichnis des users im Server zu stehen kommt. Damit wird die Audio-Standardausgabe nicht an die lokale Soundkarte geführt, sondern als Pipe writeloop zugeführt:

Code: Alles auswählen

# Alsa stdout-to-pipe

pcm.!default {
   type file
   slave {
      pcm null
   }   
   file " | sudo chrt -r 90 taskset -c 1 writeloop --block-size=2000 --file-size=65536 --force-shm --shared /wlp.1 /wlp.2 /wlp.3"
   format "raw"
}

pcm.null {
   type null
}

That's it. Ich bin vorerst einmal völlig happy damit.

Streamkonfigurierte Grüsse
Simon

Verfasst: 14.12.2017, 23:26
von dietert
Hallo Simon,

benutzt du für Stereo eine besondere Leitung zwischen den beiden Lautsprechern, oder ist in jedem Lautsprecher so ein Slave, also mit dem Master und den zwei Slaves im selben Subnet?

Bei mir ist gestern so ein AVB-Testkit von MiniDSP eingetroffen, aber wenn ich das hier lese, und die Sachen bei "frankl's stereo pages", vielleicht geht das ja auch mit Ethernet ohne die AVB Echtzeit-Erweiterung.

Grüße,
Dieter T.

Verfasst: 15.12.2017, 07:16
von Daihedz
dietert hat geschrieben: ...Bei mir ist gestern so ein AVB-Testkit von MiniDSP eingetroffen, aber wenn ich das hier lese, und die Sachen bei "frankl's stereo pages", vielleicht geht das ja auch mit Ethernet ohne die AVB Echtzeit-Erweiterung.
Aktuell:
Server <-> Slave -> Soundkarte -> Von dort Audio Stereo Standard über NF-Koax weiterverteilt.

AVB wird wohl die Zukunft sein, mit garantierten, niedrigen Laufzeiten im Falle von
Server <-> Slave1 -> Soundkarte1
Server <-> Slave2 -> Soundkarte2
Server <-> Slave_n <-> Soundkarte_n

Mir geht es hier vor allem darum, die prinzipielle Lösung mit der .asoundrc zu zeigen. D.h., dass das gesamte Audio, welches in einem PC (=Server) produziert werden kann, an zentraler Stelle in einen Netzwerkstream geführt werden kann. Ob es dann auch Stereo mittels Standard-Ethernet weitergehen kann, muss sich dann noch weisen.

Es würde mich sehr interessieren zu einem späteren Zeitpunkt zu lesen, was Du mit Deinem DSP-AVB-Kit für Erfahrungen gemacht hast.

Beste Grüsse.
Simon

Verfasst: 31.12.2017, 15:15
von Daihedz
Ein Hallo in die Runde der experimentierwilligen und -freudigen Audio-Linuxer

Eine ALSA-Konfigurationsdatei /home/xyz-user/.asoundrc machts möglich: Laustärkeeinstellung, RACE, LoCo und DRC einfach und standardmässig für sämtliche Audio-Inhalte eines Linux-Rechners ... dies, ohne Pulseaudio und/oder Jackd, sondern ausschliesslich innerhalb des (untersten) ALSA-Layers mittels einer Pipe und, in den folgenden Beispielen mittels brutefir sowie volrace hübsch aufbereitet.

Zwischenzeitlich habe ich denn etwas weiter mit dem "file"-plugin der ALSA-Konfigurationsdateien http://www.alsa-project.org/alsa-doc/al ... ugins.html experimentiert und zwei Varianten ausprobiert, welche sämtliche Audioinhalte eines Linux-Rechners, welchen Formats (an dieser Stelle nochmals ein Danke an Frank(l) für die entsprechenden Tips) und welcher Herkunft auch immer ganz nach meinem Gusto defaultmässig weiterverarbeiten.

In einer ersten Variante für meine Zweit-Stereoanlage (2-Kanal mit passiven Cabasse Sampan Lautsprechern Bild "cabasseqws4s.jpg" anzeigen.) erfolgt die Ausgabe mit 96kHz über eine nach wie vor sehr brauchbare RME HDSP Multiface I (im Bild unterhalb der Logitech Touch) und deren SPDIF-Schnittstelle an ein Wolfson WM8741-Evalboard als DA-Wandler (im Bild das 19"-Gehäuse über dem Verstärker).

Code: Alles auswählen

pcm.!default {
	type file
	file "| chrt -f 92 taskset -c 1 sox --buffer 1024 -b %b -c 2 -D -e signed-integer -r %r -t raw - -b 64 -c 2 -e floating-point -t raw - \
		| chrt -f 93 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r 44100 -t raw - -t raw - vol -2dB \
		| chrt -f 94 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r 44100 -t raw - -t raw - rate -v -I 192000 \
		| chrt -f 95 taskset -c 1 brutefir -nodefault /home/privat/_brutefir/Cabasse/brutefir_config_cabasse \
		| chrt -f 96 taskset -c 1 volrace --buffer-length=8192 --fading-length=24000 --param-file=/home/privat/_frankl/volrace.save --verbose \
		| chrt -f 97 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r 192000 -t raw - -t raw - rate -v -I 96000 \
		| chrt -f 98 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r 96000 -t raw - -b 32 -c 2 -e signed-integer -t raw - \
		| chrt -f 99 taskset -c 1 playhrt --buffer-size=4096 --device=hdsp_analog --extra-bytes-per-second=-10 --extra-frames-out=24 --hw-buffer=8192 --loops-per-second=1000 --max-bad-reads=100000  --non-blocking-write --number-channels=2 --sample-format=S32_LE --sample-rate=96000 --sleep=1000000 --stdin --verbose --verbose"
	format "raw"
	slave {
		pcm null
	}
}

pcm.hdsp {
#	HDSP: No --mmap option in case of multiface!
#	HDSP: Set soundcard to correct sample frequency, otherwise no hardware access possible
    type hw
    card 1
}

ctl.hdsp {
    type hw
    card 1
}

pcm.hdsp_analog {
	type plug
    slave { 
		pcm hdsp
	}
}

pcm.null {
	type null
}
Audio wird zunächst über 3x Sox nach 192kHz/64Bit/Float hochtransformiert und als Clipping-Schutz um 2dB heruntergerechnet. Danach passiert es Brutefir, wo mittels einer geeigneten Config LoCo und die Hörplatz-Korrektur gerechnet wird. Danach kommt Volrace, wo die gleitende Lautstärkeeinstellung und RACE erfolgen kann. Danach wird es mit 2x Sox Soundkarten- und DA-Wandlertauglich nach 96kHz/32Bit/SignedInteger (S32_LE) zurückgerechnet. Und von der Multiface in den DA-Wandler eingespiesen.

Eine zeite, etwas einfachere "All-In-One"-Lösung für den dergestalt audiophil aufgehübschten Laptop im Solo-Betrieb ohne die RME Multiface sieht folgendermassen aus (merci nochmals an Frank(l) für die Tips mit seiner eigenen Laptop-Version):

Code: Alles auswählen

pcm.!default {
	type file
	file "| chrt -f 92 taskset -c 1 sox --buffer 1024 -b %b -c 2 -D -e signed-integer -r %r -t raw - -b 64 -c 2 -e floating-point -t raw - \
		| chrt -f 93 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r 44100 -t raw - -t raw - vol -2dB \
		| chrt -f 94 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r 44100 -t raw - -t raw - rate -v -I 192000 \
		| chrt -f 95 taskset -c 1 brutefir -nodefault /home/privat/_brutefir/Cabasse/brutefir_config_W500 \
		| chrt -f 96 taskset -c 1 volrace --buffer-length=8192 --fading-length=24000 --param-file=/home/privat/_frankl/volrace.save --verbose \
		| chrt -f 97 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r 192000 -t raw - -t raw - rate -v -I 96000 \
		| chrt -f 98 taskset -c 1 sox --buffer 4096 -b 64 -c 2 -D -e floating-point -r 96000 -t raw - -b 32 -c 2 -e signed-integer -t raw - \
		| chrt -f 99 taskset -c 1 playhrt --buffer-size=4096 --device=hw:0,0 --extra-bytes-per-second=-10 --extra-frames-out=24 --hw-buffer=8192 --loops-per-second=1000 --max-bad-reads=100000  --non-blocking-write --number-channels=2 --sample-format=S32_LE --sample-rate=96000 --sleep=1000000 --stdin --verbose --verbose"
	format "raw"
	slave {
		pcm null
	}
}

pcm.null {
   type null
}
In beiden Beispielen ist die Pipe mit
<Audioquelle> -> sox | sox | sox | brutefir | volrace | sox | sox | playhrt
etwas langfädig, aber für meine Experimentierzwecke absichtlich so gewählt.

Einfacher wäre
<Audioquelle> -> sox | brutefir | volrace | sox | playhrt
in welcher pro eine Instanz sox sämtliche Transformationen in einem Rutsch gerechnet würden

Ich möchte hiermit keine Lösungen anpreisen, sondern vor allem auf die fantastischen Möglichkeiten hinweisen, innerhalb des ALSA-Layers mittels einer geeigneten Konfigurationsdatei praktisch beliebige Dinge mit Audiomaterial anstellen zu können, dies ganz nach Bedarf und/oder defaultmässig automatisiert.

Altjahresgrüsse
Simon

Verfasst: 11.02.2018, 11:37
von Martin
Hallo Frank,
Bisher verwendete ich mpd auf dem Raspi 3. Über die Pipe-Ausgabe von mpd ging es an brutefir, sox und bufhrt. Dann übers Ethernet zum Aria G25, auf dem playhrt läuft. So weit so gut. Nun habe ich mal aus Neugier mpd ersetzt durch ein etwas modifiziertes play_remote Script mit deinem neuen resample_soxr befehl. Obwohl mir auf dem rechten Ohr ein Tinnitus zu schaffen macht, ist vor allem bei klassischer Musik ein so deutlicher Unterschied zu hören, dass ich jetzt nicht mehr mit mpd hören mag. Mpd nutze ich jetzt nur noch gelegentlich für Internet-Streams (Youtube, Qobuz, Radio), aber nicht zum ernsthaften Musik hören.

Nun stellt sich die Frage der Bedienbarkeit. Ich verwende einen Laptop für die Bedienung. Der Laptop ist über WLAN mit dem Raspi 3 verbunden. Es ist mir gelungen, das play_remote Script in den Dateimanager Nemo (Linux Mint) zu integrieren. Meine Musiksammlung liegt auf einer Netzwerkplatte (SMB) und ist nach Genre, Künstler bzw. Komponist sortiert. Die CDs sind trackweise als Flac-Dateien abgespeichert. Wenn ich mit der Maus einen Rechtsklick auf einen Track mache, kann ich das play_remote Script starten. Das klappt auch mit mehreren markierten Tracks, die dann nacheinander abgespielt werden, aber leider nicht gapless. Die Lautstärke kann über die Tastatur gesteuert werden. Wenn das ganze gapless funktionieren würde, könnte ich damit leben.

Du hast mal erwähnt, dass du eine CD in einer einzigen Flac-Datei abspeicherst und mit einem Cue-Sheet arbeitest. Kannst du dazu etwas sagen, wie funktioniert das bei dir?

Viele Grüße
Martin

PS. Ich bin wirklich begeistert von "Frante" (Franks Audio Network Through Ethernet)

Verfasst: 11.02.2018, 23:34
von frankl
Hallo Martin,

danke für Deinen Bericht.
Martin hat geschrieben: Nun habe ich mal aus Neugier mpd ersetzt durch ein etwas modifiziertes play_remote Script mit deinem neuen resample_soxr befehl. Obwohl mir auf dem rechten Ohr ein Tinnitus zu schaffen macht, ist vor allem bei klassischer Musik ein so deutlicher Unterschied zu hören, dass ich jetzt nicht mehr mit mpd hören mag. Mpd nutze ich jetzt nur noch gelegentlich für Internet-Streams (Youtube, Qobuz, Radio), aber nicht zum ernsthaften Musik hören.
Das kann ich verstehen. Leider besteht mpd darauf, die eigentlichen Musikdaten selbst zu verarbeiten und die pipe Ausgabe ist nur eine Krücke, die vom Maintainer als nicht wichtig betrachtet wird. Das ist klanglich nicht optimal.
Martin hat geschrieben: Nun stellt sich die Frage der Bedienbarkeit.
[...]

Du hast mal erwähnt, dass du eine CD in einer einzigen Flac-Datei abspeicherst und mit einem Cue-Sheet arbeitest. Kannst du dazu etwas sagen, wie funktioniert das bei dir?
Ich wurde die letzte Zeit mehrfach zu meinem Setup und meinem Abspielskript gefragt. Es steht auf meiner TODO Liste, dass mal genauer zu dokumentieren und (aufgeräumte) Versionen meiner Skripte hochzuladen. Ich muss aber um ein wenig Geduld bitten, da ich gerade dabei bin, meine Anlage für 6 Wochen abzuschalten (bei interessanter Arbeit in fernen Landen halten sich die Entzugserscheinungen hoffentlich in Grenzen).

Ich denke aber, dass man mit den existierenden Programmen auch ein Skript hinbekommen sollte, das zumindest die Tracks eines Albums gapless abspielen kann. Ich werde mal überlegen.


Auf die Dauer schwebt mir vor, mal ein Webinterface zu programmieren mit ein paar grundlegenden Funktionen zur Musikauswahl, Lautstärke- und Filter-Regelung. Das sollte sich leicht auf individuelle Wünsche konfigurieren lassen, und darüber werden die Skripte gestartet, die ich jetzt auf der Kommandozeile starte. Damit könnte man dann jedes Gerät mit Webbrowser zur Bedienung verwenden.

Viele Grüße,
Frank