Klangunterschied Win 10 / Linux

Melomane · Beitrag von **Melomane** » 30.10.2019, 14:07

Hallo Uwe,

dann haben wir eine andere Situation, als ich ursprünglich angenommen hatte. Denn Pulseaudio und dessen etwaige Unarten wären dann aus dem Spiel. Und JRiver für deinen eingangs beschriebenen Klangeindruck unter Linux verantwortlich. Da ließe sich schrauben über die Einstellmöglichkeiten bei JRiver. Aber derartigen Konfigurationsmaßnahmen wolltest du ja eigentlich aus dem Weg gehen.

Und da JRiver unter Windows via asio-Treiber mit dem Wandler kommuniziert, wäre mein Verdächtiger eben dieser Treiber und dessen Konfiguration, der den anderen Eindruck unter Linux hervorruft, ggf. noch andere Einstellungen in JRIver.

Aber die betriebssystemeigenen "Soundengines" müssten bei derartiger Konstellation eigentlich aus dem Spiel sein. Bei beiden Betriebssystemen. Eigentlich.

Gruß

Jochen

Buellerich · Beitrag von **Buellerich** » 30.10.2019, 18:34

Ich sehe nach ausführlichen Tests keinen klanglichen Vorteil von Linux gegenüber Windows. Ich habe Daphile und WTFPlay ausführlich getestet und konnte den klanglichen Vorteil nicht sehen, selbst nach Rumspielen mit den Parametern (Frames, Periods...) nicht.
Innerhalb Windows klingen die Player z.T. so unterschiedlich, dass ich an einen betriebssystembedingten Klangeindruck nicht glaube.
Selbst an den klanglichen Vorteil minimalistischer Setups glaube ich nicht, solange das Signal ohne überlastungsbedingte Dropouts übertragen werden kann. Meines Erachtens liegen die Unterschiede in der Tat tief verwurzelt in der Programmierung der Playersoftware. Ist dies gut gelöst, spielen auch Manipulationen über Parameter wie DAC-Link, Frames oder Periodsize nur noch eine untergeordnete Rolle. Dies fasst in etwa meine Erfahrung mit zahlreichen Playern in den letzten Jahren zusammen.

Koala887 · Beitrag von **Koala887** » 31.10.2019, 08:21

Hallo,

also für mich war Christoph´s AudioPE (Win PE + JPlay in Ramdisk) lange Zeit die Referenz unter den Windowssystemen (wobei ich auch hier mit den unzähligen Einstellmöglichkeiten von JPlay nie 100 prozentig zufrieden war). Da kamen auch die diversen Linuxdistros wie Daphile, WTFPlay usw. nicht ran. Geändert hat sich das erst, als ich die playhrt Programme und Skripte von Frankl testete. Das klang schon mit einem Standard Debian System richtig gut.
Danach fing ich an, mir ein Minimal Linux zu bauen, mit RT-Kernel, nur die nötigsten Prozesse und selbst Frankl´s Programme hab ich noch abgespeckt. Das Ergebnis konnte man ja beim letzten Forentreffen im kleinen Hörraum hören.

Schöne Grüße
Daniel

bastelixx · Beitrag von **bastelixx** » 31.10.2019, 09:08

Koala887 hat geschrieben: ↑31.10.2019, 08:21
Danach fing ich an, mir ein Minimal Linux zu bauen, mit RT-Kernel, nur die nötigsten Prozesse und selbst Frankl´s Programme hab ich noch abgespeckt. Das Ergebnis konnte man ja beim letzten Forentreffen im kleinen Hörraum hören.

Daniel

Hallo Daniel,

hast du Minix oder eine andere Distribution mit RT-Kernel von Linux? Hast du schon Arch Linux ausprobiert? Hast du schon mal MPD getestet? Kannst du etwas ausführlicher darüber schreiben.

Danke
Stanislaw

Koala887 · Beitrag von **Koala887** » 31.10.2019, 10:19

Hallo Stanislaw,

mein System basiert auf einer Debian Strech Minimal Installation. Der Kernel ist selbst kompiliert und hat nur die nötigen Treiber und RT-Einstellungen. Mit Make localyesconfig oder localmodconfig kann man beim kompilieren nur die aktuell geladenen Treiber in den Kernel einbinden, was diesen deutlich schlanker macht.
Die meisten Dienste und Scripts beim Starten kann man auch deaktivieren, aus dem Kopf weiß ich allerdings nicht mehr, was bei mir noch läuft.
Beim Starten werden auch 2 Prozessorkerne isoliert auf denen dann nur Sox und Playhrt mit RT-Priorität laufen, die anderen 2 Kerne sind fürs restliche System.
Gesteuert wird der PC über MPD mit upnp-Plugin. Allerdings ist MPD nicht der eigentliche Player, sondern es wird beim Starten eines Songs nur der Dateipfad mit einem Script ausgelesen, die Datei wird dann in den Ram kopiert und anschließend mit Playhrt abgespielt. Dieser Umweg war leider nötig, da eine direkte Wiedergabe mit MPD und Pipe an Playhrt immer schlechter klang, als die Wiedergabe nur mit Playhrt.
Eigentlich wollte ich noch einen eigenen Upnp-Renderer programmieren, der mir ohne Umwege den Pfad ausgibt und das Playscript startet, aber dazu fehlte mir bis jetzt die Zeit und etwas Hintergrundwissen. Vielleicht liest ja hier jemand mit und könnte das für mich übernehmen?

Schöne Grüße
Daniel

hkampen · Beitrag von **hkampen** » 10.11.2019, 13:53

Hallo Uwe,

hast du mal JRiver als Einfluss ausgeschlossen? Ich würde eine WAV-Datei erstellen und diese dann auf beiden Systemen ohne JRiver vergleichen. Z.B. unter Linux mit WTFPlay oder playhrt und unter Windows mit der JPLAY-Konsole. Damit kannst du JRiver als Einfluss für die Unterschiede entweder identifizieren oder ausschließen.

Grüße
Harald

frankl · Beitrag von **frankl** » 13.11.2019, 00:38

Hallo Forenten,

ich finde den Ansatz mit Linux reizvoll, weil es nicht so schwer ist, ein sehr abgespecktes System ohne unnötige und potentiell störende Prozesse aufzusetzen.

Der Extremfall ist wohl mein Musikrechner, der nur Musikdaten über Ethernet liest und über USB abspielt. Der hat 256 MB RAM, das System läuft im RAM, und es laufen nur ca. 20 Kernelthreads für Hardware und Scheduler (nur 6 davon haben nach 4 Wochen mehr als 1 Sekunde CPU Zeit benötigt) und nur 2 User Prozesse: ein bash-Skript, das in einer Unendlichschleife bei Bedarf playhrt aufruft.

Koala887 hat geschrieben: ↑31.10.2019, 10:19 mein System basiert auf einer Debian Strech Minimal Installation. Der Kernel ist selbst kompiliert und hat nur die nötigen Treiber und RT-Einstellungen. Mit Make localyesconfig oder localmodconfig kann man beim kompilieren nur die aktuell geladenen Treiber in den Kernel einbinden, was diesen deutlich imschlanker macht.

Hallo Daniel,

ja, 'localyesconfig' ist eine nette Möglichkeit, einen kleinen Kernel herzustellen (obwohl natürlich kompilierte Module, die gar nicht genutzt werden, auch kaum stören). Kannst Du etwas zu den 'RT-Einstellungen' sagen, die Du konfigurierst?

Viele Grüße,
Frank

Grauwacke · Beitrag von **Grauwacke** » 13.11.2019, 13:38

Melomane hat geschrieben: ↑30.10.2019, 13:38 JRiver gibt es doch auch für Linux. Und wenn ich mich recht erinnere, kann JRiver als Ausgabedevice ein Gerät wählen an Pulseaudio vorbei (falls Mint bei dir noch läuft).

Hallo, Uwe und Jochen,

JRiver kann ALSA-Geräte direkt auswählen. In meinem Debian-Rechner, der die Dante-PCIe-Karte drin hat, ist selbige mit mehreren Optionen auswählbar, ohne das Pulseaudio da beteiligt wäre.

viele Grüße
Helge

bastelixx · Beitrag von **bastelixx** » 01.02.2020, 10:04

frankl hat geschrieben: ↑13.11.2019, 00:38 Hallo Forenten,

ich finde den Ansatz mit Linux reizvoll, weil es nicht so schwer ist, ein sehr abgespecktes System ohne unnötige und potentiell störende Prozesse aufzusetzen.

Der Extremfall ist wohl mein Musikrechner, der nur Musikdaten über Ethernet liest und über USB abspielt. Der hat 256 MB RAM, das System läuft im RAM, und es laufen nur ca. 20 Kernelthreads für Hardware und Scheduler (nur 6 davon haben nach 4 Wochen mehr als 1 Sekunde CPU Zeit benötigt) und nur 2 User Prozesse: ein bash-Skript, das in einer Unendlichschleife bei Bedarf playhrt aufruft.

Koala887 hat geschrieben: ↑31.10.2019, 10:19 mein System basiert auf einer Debian Strech Minimal Installation. Der Kernel ist selbst kompiliert und hat nur die nötigen Treiber und RT-Einstellungen. Mit Make localyesconfig oder localmodconfig kann man beim kompilieren nur die aktuell geladenen Treiber in den Kernel einbinden, was diesen deutlich imschlanker macht.
Hallo Daniel,

ja, 'localyesconfig' ist eine nette Möglichkeit, einen kleinen Kernel herzustellen (obwohl natürlich kompilierte Module, die gar nicht genutzt werden, auch kaum stören). Kannst Du etwas zu den 'RT-Einstellungen' sagen, die Du konfigurierst?

Viele Grüße,
Frank

Hallo Frank,

ich habe eine andere Frage an Dich. Ich benutze für Crossover und für die Raumkorrektur einen Rechner mit Ubuntu Server und brutefir. Nun will ich auf ein stromsparsameren PC umsteigen. Ich habe Ubuntu Server installiert, habe auf lowlatency Kernel upgegratet. Nun habe ich auf ein unlösbares Problem gestossen - die neue Server von Ubuntu will mein sh-Starter für brutefir-Start nicht unterstützen und brutefir lässt sich nur manuell starten. Mit dem Weg über rc.local bin ich auch nicht weiter gekommen. Die rc.local existierte im neuen Ubuntu server nicht mehr, ich musste sie selber erstellen, aber von mir erstellte funktioniert nicht, wird vom System ignoriert. Dazu habe ich di Anleitung genutzt https://www.itechlounge.net/2017/10/lin ... -debian-9/
Hast du für mich vielleicht ein Tipp?

Gruß
Stanislaw

Buschel · Beitrag von **Buschel** » 01.02.2020, 11:31

Hallo Stanislaw,

wie sieht denn dein Skript aus und welchen Fehler bekommst du derzeit? Ist das Skript ausführbar oder wird es über "sh my_script.sh" gestartet?

Und: Hast du beim Start von brutefir root-Rechte? Das erlaubt höhere Prios der threads und lässt brutefir robuster bei Lastsituationen laufen.

Grüße,
Andree

bastelixx · Beitrag von **bastelixx** » 01.02.2020, 13:40

Buschel hat geschrieben: ↑01.02.2020, 11:31 Hallo Stanislaw,

wie sieht denn dein Skript aus und welchen Fehler bekommst du derzeit? Ist das Skript ausführbar oder wird es über "sh my_script.sh" gestartet?

Und: Hast du beim Start von brutefir root-Rechte? Das erlaubt höhere Prios der threads und lässt brutefir robuster bei Lastsituationen laufen.

Grüße,
Andree

Hollo Andree,

ich bekome keine Fehlermeldung beim eingeben "systemctl start rc-local.service", aber brutefir wird nicht gestartet.
Bei autologin bekome ich user- und keine rootrechte. Hat aber mit der frühere Version von Unbuntu server gut funktioniert. Ich bekome mehrere brutefir-Prozesse mit Prio "-5" und "-6"

Mein rc.local sieht so aus:
----------------------------------
#!/bin/sh -e
#
# rc.local
/usr/bin/brutefir
exit 0

-------------------------------

die Datei in /usr/bin/ sieht so aus:
--------------------------------------------------
#!/bin/sh

BIN=/usr/lib/brutefir/brutefir.real
CONFIG=/home/lynx/.brutefir_config
if ! [ -e $CONFIG ]; then
touch $CONFIG
fi

$HOME $LYNX $@
-------------------------------------------------

Leider startet service das brutefir nicht.
Manuel ob User oder root kein Problem.

Hast eine Idee, woran es liegt?

Gruß
Stanislaw

Buschel · Beitrag von **Buschel** » 01.02.2020, 18:44

Hallo Stanislaw,

ich hätte etwa so etwas erwartet:

Code: Alles auswählen

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/home/user/start_brutefir.sh

exit 0

und als ausführbares ("chmod +x /home/user/start_brutefir.sh") script:

Code: Alles auswählen

#!/bin/bash

/usr/lib/brutefir /home/user/stanislaws_brutefir.config

Der Aufruf von "/home/user/start_brutefir.sh" sollte brutefir mit deiner config starten. Diesen call setzt du in die rc.local ein.

Grüße,
Andree

bastelixx · Beitrag von **bastelixx** » 02.02.2020, 00:50

Buschel hat geschrieben: ↑01.02.2020, 18:44 Hallo Stanislaw,

ich hätte etwa so etwas erwartet:
Code: Alles auswählen
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/home/user/start_brutefir.sh

exit 0
und als ausführbares ("chmod +x /home/user/start_brutefir.sh") script:
Code: Alles auswählen
#!/bin/bash

/usr/lib/brutefir /home/user/stanislaws_brutefir.config
Der Aufruf von "/home/user/start_brutefir.sh" sollte brutefir mit deiner config starten. Diesen call setzt du in die rc.local ein.

Grüße,
Andree

Danke Andree für Deine Unterstützung.
Habe mit meiner start-brutefir.sh und nach deinerm Vorschlag geänderter start-brutefir.sh brutefir immer starten können mit dem Befehl: sh /home/stanislaw-usermame/start-brutefir.sh
Das Problem ist folgendes, wenn ich die start-brutefir.sh mit dem rc-local.service anzuspreche, erstmal alles OK, brutefir startet bis
"BruteFir v.1.0m....Internal resolution is 64 bit floating points.
SSE2 capability detected -- optimisation enabled.
Creating 4 FFTW plans osf size 128...fineshed.
Loading 8 coefficient sets...Could not open "TT..(meine Crossover-datei).....txt" for reading."

rc-local.servis gibt die Meldung: "Job for rc-local.service failed because the control process exited with error code."

Ich habe versucht das Problem zu umgehen, indem ich zum Testen eiene solche Datei in /etc/ kopiert habe - hat nix gebracht. Es scheint mir so, dass rc-local.service aus irgend-welchen Sichrheitsgründen die .txt-Dareien nicht lesen will? darf?
Die .brutefir_config Datei im /home/userordner/ stelt für rc-local.servis kein Problem dar.
Ich werde noch morgen anstatt .txt die .dbl Dateien erzeugen. Mal schauen, wie rc-local.service darauf reagiert.

Gruß
Stanislaw

Buschel · Beitrag von **Buschel** » 02.02.2020, 08:21

Guten Morgen Stanislaw,

aus der Ferne sieht das so aus, als ob du in der brutefir config eventuell relative Pfadnamen für die Koeffizientendateien benutzt (z.B. "mycoef.dbl" oder "./myfolder/mycoef.dbl"). Falls das so ist, ersetze die mal durch den kompleeten Pfadnamen (z.B. "/home/user/myfolder/mycoef.dbl"). Falls das nicht der Fall ist, kannst mir gerne mal deine config per PN senden.

Grüße,
Andree

bastelixx · Beitrag von **bastelixx** » 02.02.2020, 09:57

Buschel hat geschrieben: ↑02.02.2020, 08:21 Guten Morgen Stanislaw,

aus der Ferne sieht das so aus, als ob du in der brutefir config eventuell relative Pfadnamen für die Koeffizientendateien benutzt (z.B. "mycoef.dbl" oder "./myfolder/mycoef.dbl"). Falls das so ist, ersetze die mal durch den kompleeten Pfadnamen (z.B. "/home/user/myfolder/mycoef.dbl"). Falls das nicht der Fall ist, kannst mir gerne mal deine config per PN senden.

Grüße,
Andree

Guten Morgen Andree,

Danke für Dein Hinweis, ich habe mit den .txt-Dateien schon mit dem Pfadnamen versucht, leider ohne Erfolg. Jetzt, wo du mich nochmal daran erinnerst, habe ich es für mycoef.dbl-s umgesetzt mit Erfolg.

Nun muss ich in meiner start-brutefir.sh sleep einbauen, da die rc-local.service schon während des Bootvorgangs die SH und damit brutefir startet, wo das Systen noch nicht zum Ende gestartet hat und bleibt hängen.

Gruß
Stanislaw