Software-Experimente mit Linux

Musikwiedergabe über PC und Mac
Buellerich
Aktiver Hörer
Beiträge: 212
Registriert: 31.01.2015, 23:08

Beitrag von Buellerich »

Moin Us

also ganz so stark wie Du habe ich die Unterschiede nicht feststellen können, eher subtiler.

Ich selber bin zu Windows basiertem Computer Audio zurückgekehrt, weil es m.E. zumindest mit JPLAY klanglich überlegen war. Ich muss allerdings dazu sagen, dass ich über Linux nur Daphile und WTF getestet habe. Beide gehen allerdings über den Alsa Treiber. Interessant wäre vielleicht noch audiophile Linux oder snakeoil.
Welche Registryeinträge wurden denn von Windows ignoriert?
Bist Du mit Admin Rechten unterwegs?
Bild
ZZTop
Aktiver Hörer
Beiträge: 150
Registriert: 15.03.2012, 14:27

Beitrag von ZZTop »

Windows 10 ignoriert so ziemlich alle wesentlichen Settings, bzw. überschreibt diese nach Lust und Laune.
Updates, search-Indexer, Cortana, Superfetch... um nur ein paar zu nennen. Selbst wenn in der Registry deaktviert, nach ein paar Neustarts sind sie alle wieder da.
Ob ich Admin bin? Ich dachte schon, aber werde immer wieder aufgefordert für gewisse Vorgänge Admin Rechte zu verwenden. Da klicke ich halt auf "ja"

Vielleicht habe ich ja bei der Installation etwas verkehrt gemacht. Hat hier noch jemand JRiver unter Linux am laufen?

greetz
Uwe
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4021
Registriert: 23.03.2009, 15:58
Wohnort: 33442
Kontaktdaten:

Beitrag von uli.brueggemann »

ZZTop hat geschrieben:Windows 10 ignoriert so ziemlich alle wesentlichen Settings, bzw. überschreibt diese nach Lust und Laune.
Updates, search-Indexer, Cortana, Superfetch... um nur ein paar zu nennen. Selbst wenn in der Registry deaktviert, nach ein paar Neustarts sind sie alle wieder da.
Schau Dir doch mal das ShutUp10 von O&O an. Das funktioniert ziemlich gut.

Grüsse
Uli
Bild
ZZTop
Aktiver Hörer
Beiträge: 150
Registriert: 15.03.2012, 14:27

Beitrag von ZZTop »

Scheisse! jetzt habe ich mir mein Linux Mint zerschossen.
Ich wollte mit der disk utility einstellen, dass die Partition mit den Musikdaten automatisch beim Start geladen wird.
Jetzt fährt Linux nicht mehr hoch sondern bringt Meldungen wie:
[ 95.722897 ]nouveau 0000:03........ bus MMIO write of00000002 FAULT at4188ac [ IBUS ]

wobei alle paar Minuten der erste Block in [ ] um ca. 25.000000 gröger wird, der Rest bleibt gelch. Das geht stundenlang, bis ich abschalte.

hat jemand nen Tipp?
Bild
Sire
Aktiver Hörer
Beiträge: 294
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Hallo Uwe,

mit der Arbeitsweise des "disk utility" kenne ich mich zwar nicht aus, ich vermute aber, dass die /etc/fstab verändert wurde.

Kannst Du Deinen Rechner mit einem Live-System booten? Falls ja, dann finde auf Deiner Festplatte die Datei /etc/fstab der LInux-Mint-Installation und poste sie hier.

Viele Grüße

Klaus

PS: Ich hatte mir eben die Fehlermeldung nicht richtig angeschaut, vermutlich ist es doch was anderes. Lässt eher auf ein Problem mit den noveau-Modulen der Nvidia-Grafikkarte schließen.
Bild
frankl
Aktiver Hörer
Beiträge: 418
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

ZZTop hat geschrieben: Jetzt fährt Linux nicht mehr hoch sondern bringt Meldungen wie:
[ 95.722897 ]nouveau 0000:03........ bus MMIO write of00000002 FAULT at4188ac [ IBUS ]
Hallo Uwe,

bei solchen Problemen hilft meist die Lieblingssuchmaschine schnell weiter. In diesem Fall würde ich mal "nouveau MMIO write FAULT" oder ähnliches eingeben.

Bitte an die Moderation: Dieser Thread ist nicht für den Austausch über Konfiguratiionsprobleme von Windows 10 oder die Installation spezifischer Linux Varianten gedacht. Vielleicht kann dieser Beitrag und die vorhergehenden zu Win 10 ins Archiv verschoben werden?

Viele Grüße,
Frank
Bild
frankl
Aktiver Hörer
Beiträge: 418
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Hallo Daniel,
vielen Dank für Deinen Bericht über den Einsatz von 'playhrt'. Du beschreibst ganz richtig, dass man zu Anfang ein bisschen mit den vielen Parametern herumprobieren muss. Aber es freut mich, dass Du dann eine befriedigende Einstellung finden konntest.

Deinen Vergleich verschiedener Timer finde ich auch sehr interessant. Auf den Rechnern, auf denen ich die Programme selbst probiert habe, gab es allerdings immer nur einen hochauflösenden Timer, so dass sich die Frage nach einem Vergleich nie ergeben hat.

In Deinem Skript wird zum Schluss 'playshm' aufgerufen. Ist das ein Tippfehler und es ist 'playhrt' gemeint?

Zu den 'taskset' Kommandos: Ich sorge in meinem Abspielskript auf meinem Convolver-Rechner auch dafür, dass keine ungewollten Prozesse auf dem CPU-Kern laufen, auf dem der wichtigste Prozess (in meinem Fall 'bufhrt', bei Dir 'playhrt') gestartet wird. Das mache ich so, wie von Simon vorgeschlagen, also zuerst
wird die CPU ausgeschaltet:

Code: Alles auswählen

echo 0 > /sys/devices/system/cpu/cpu1/online
und dann wieder eingeschaltet und die gewünschten Prozesse darauf mit 'taskset' gestartet.

Ich finde es bei mir übrigens am besten, das 'writeloop' (ohne realtime Priorität) und das 'bufhrt' (mit hoher realtime Priorität) auf dem gleichen CPU-Kern laufen zu lassen. Das könnte damit zu tun haben, dass unter Umständen nicht jede CPU jeden Speicherbereich gleich schnell ansprechen kann. Das muss nicht auf jeder Architektur gleich sein, aber wäre vielleicht einen Versuch wert.
Koala887 hat geschrieben: Der einzige Nachteil dabei ist, das Ganze spielt nicht gapless und bei Pause startet das Lied von vorne, was mich aber nicht besonders stört. Für den guten Klang macht man gerne ein paar Abstriche. 8)
Verstehe ich es richtig, dass Dein Skript durch 'mpd' für jedes ausgewählte Stück gestartet wird? Wenn ja, dann lässt sich in Bezug auf gapless wohl nichts verbessern.

In Deinem Skript könntest Du allerdings durchaus mehrere Stücke per 'wget' holen und dann hinterher alle diese Stücke als input-Dateien für 'sox' verwenden. Das sollte dann alle Stücke hintereinander gapless spielen. Könnte man 'mpd' dazu bringen, eine '.m3u' zu übergeben (die in jeder Zeile die URL zu einem Stück enthält)?

Viele Grüße,
Frank
Bild
Koala887
Aktiver Hörer
Beiträge: 534
Registriert: 27.12.2010, 17:23
Wohnort: Eltmann, Unterfranken

Beitrag von Koala887 »

Hallo Frank,
frankl hat geschrieben:In Deinem Skript wird zum Schluss 'playshm' aufgerufen. Ist das ein Tippfehler und es ist 'playhrt' gemeint?
über 1000 Zugriffe und du bist der Erste dem es auffällt. :wink:
Bei playhrt hatte ich die Möglichkeit vermisst, wie bei bufhrt, die shared Memory Dateien von writeloop direkt einzulesen. Also habe ich mir kurzerhand selbst ein Programm zusammen kopiert, welches die shm-Dateien per memcpy und mmap direkt in den Speicherbereich der Soundkarte kopiert. Wenn jemand Interesse hat, kann ich es gerne zur Verfügung stellen.
Davon habe ich dann auch noch eine 2. Version erstellt, bei der der komplette Fehlerauswertungs- und Statistikcode entfernt ist, was mMn noch einen Tick besser klingt :D
frankl hat geschrieben:Das mache ich so, wie von Simon vorgeschlagen, also zuerst
wird die CPU ausgeschaltet:
echo 0 > /sys/devices/system/cpu/cpu1/online
und dann wieder eingeschaltet und die gewünschten Prozesse darauf mit 'taskset' gestartet.
Hier ist es aber möglich, dass Linux neue Prozesse trotzdem auf dem Kern startet, oder laufende Prozesse dorthin verschiebt. Mit isolcpus wird das unterbunden.
frankl hat geschrieben:Könnte man 'mpd' dazu bringen, eine '.m3u' zu übergeben (die in jeder Zeile die URL zu einem Stück enthält)?
Ich bin mir jetzt nicht ganz sicher, aber ich glaube man kann auch die komplette Playlist abrufen. Da es mich bis jetzt nicht gestört hat, habe ich das aber noch nicht weiter verfolgt.

Schöne Grüße
Daniel
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 3570
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo Daniel,
über 1000 Zugriffe und du bist der Erste dem es auffällt.
mir ist das auch sofort aufgefallen, richtig heißt es ja playmate, oder?

Gruß

Bernd Peter
Bild
frankl
Aktiver Hörer
Beiträge: 418
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Koala887 hat geschrieben:Hallo Frank,
frankl hat geschrieben:In Deinem Skript wird zum Schluss 'playshm' aufgerufen. Ist das ein Tippfehler und es ist 'playhrt' gemeint?
über 1000 Zugriffe und du bist der Erste dem es auffällt. :wink:
Bei playhrt hatte ich die Möglichkeit vermisst, wie bei bufhrt, die shared Memory Dateien von writeloop direkt einzulesen. Also habe ich mir kurzerhand selbst ein Programm zusammen kopiert, welches die shm-Dateien per memcpy und mmap direkt in den Speicherbereich der Soundkarte kopiert. Wenn jemand Interesse hat, kann ich es gerne zur Verfügung stellen.
Hallo Daniel,

danke für Deine Erklärungen. Ich gebe zu, dass mir bei meiner Frage gar nicht bewusst war, dass ich in 'playhrt' noch gar nicht die Input-Variante aus dem shared memory implementiert hatte. Ich habe das mal auf meine TODO Liste geschrieben.
Koala887 hat geschrieben: Davon habe ich dann auch noch eine 2. Version erstellt, bei der der komplette Fehlerauswertungs- und Statistikcode entfernt ist, was mMn noch einen Tick besser klingt :D
Gute Idee. Das habe ich gleich mal probiert und das macht bei mir auch den Klang einen hörbaren Tick besser. Es spielt hier vielleicht eine Rolle, dass der Code der zentralen Schleife möglichst kompakt ist, denn für die Rechenzeit sind die paar 'if'-Abfragen, durch die Code übersprungen wird, irrelevant.

Ich werde mir überlegen, ob ich so eine über einen Schalter wählbare Kompaktversion des Codes in das Programm einbaue.
Koala887 hat geschrieben:
frankl hat geschrieben:Das mache ich so, wie von Simon vorgeschlagen, also zuerst
wird die CPU ausgeschaltet:
echo 0 > /sys/devices/system/cpu/cpu1/online
und dann wieder eingeschaltet und die gewünschten Prozesse darauf mit 'taskset' gestartet.
Hier ist es aber möglich, dass Linux neue Prozesse trotzdem auf dem Kern startet, oder laufende Prozesse dorthin verschiebt. Mit isolcpus wird das unterbunden.
Das habe ich jetzt auf meinem 4-Core Odroid Convolver-Rechner auch mal probiert (dazu muss man die Kernel-Parameter-Zeile in der 'uboot.ini' suchen und editieren). Es ist sehr hübsch anzusehen, dass jetzt auf den CPUs 1 bis 3 nur noch die zugehörigen Scheduler-Kernel-Prozesse und die Programme meiner Abspiel-Pipe laufen. Die vorher da herumlungernden Prozesse (die allerdings auch nach Wochen keine CPU-Zeit verbraucht hatten) sind nun alle auf die CPU 0 verbannt. Klanglich konnte ich gegen mein vorheriges Setup aber hier keinen Unterschied ausmachen.

Viele Grüße,
Frank
Bild
Daihedz
Aktiver Hörer
Beiträge: 737
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo in die Runde
frankl hat geschrieben: ... zum Beispiel mit 'arecord' das Eingangssignal lesen, eventuell per sox upsamplen und/oder mit brutefir falten und dann mit 'aplay' oder vielleicht besser mit meinem 'playhrt' wieder abspielen. ...

Das mache ich in meinen bisherigen Experimenten genauso, resp. mit Frank's Programmsammlung (z.B. zwischenzeitlich mit resample-soxr statt mit sox) noch etwas besser, und es funktioniert in der Regel ganz prima.

Frage: Gibt es allenfalls (noch) schlankere Alternativen zu arecord, um ein Signal, welches an der Soundkarte ansteht, in eine Pipe einzulesen? In meinem Falle würde es sich um Analog-In und/oder Spdif-In handeln.

Abspeckenwollende Grüsse
Simon
Bild
Buschel
Aktiver Hörer
Beiträge: 799
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo zusammen,

seit ein paar Tagen beschäftige ich mit Frank´s Tools und stoße derzeit auf ein Problem, für das ich eine saubere Lösung suche. Sobald ich am Ende der pipe playhrt mit "--mmap" aufrufe bekomme ich Abbrüche. Dies geschieht nur, wenn ich brutefir ebenfalls in der pipe benutze. Als workaround hilft es, wenn ich playhrt mit "--sleep=1000000" aufrufe, was ja einer Verzögerung von 1 Sekunde entspricht. Ich vermute das liegt an noch nicht von brutefir gefüllten Puffern. Gibt es elegantere Lösungen, um diesen Fehler zu vermeiden? Ich denke da an Warteskripte, die in die pipe eingefügt werden können...

Funktioniert (mmap mit sleep notwendig):

Code: Alles auswählen

pcm.pipe_src96k_brutefir_dither24 {
	type file
	file "| sox -D -v 0.8 -r 44.1k -b 32 -c 2 -e signed -t raw - --buffer 8192 -b 64 -c 2 -e float -t raw - \
	      | resample_soxr -c 2 -B 93 -P 50 -i 44100 -o 96000 \
	      | brutefir /home/buschel/Convolver/DRC_96k_eq_stdin_stdout.conf \
	      | sox -t raw -r 96k -b 64 -c 2 -e float - --buffer 8192 -b 32 -c 2 -e signed -t raw - dither -p 24 \
	      | playhrt --verbose --verbose --stdin -k 2 -s 96000 -f S32_LE -d usbaudio --mmap --sleep=1000000"
	format "raw"
	slave.pcm null
}
Funktioniert (mmap läuft ohne sleep, wenn brutefir nicht in der pipe ist):

Code: Alles auswählen

pcm.pipe_src96k_brutefir_dither24 {
	type file
	file "| sox -D -v 0.8 -r 44.1k -b 32 -c 2 -e signed -t raw - --buffer 8192 -b 64 -c 2 -e float -t raw - \
	      | resample_soxr -c 2 -B 93 -P 50 -i 44100 -o 96000 \
	      | sox -t raw -r 96k -b 64 -c 2 -e float - --buffer 8192 -b 32 -c 2 -e signed -t raw - dither -p 24 \
	      | playhrt --verbose --verbose --stdin -k 2 -s 96000 -f S32_LE -d usbaudio --mmap"
	format "raw"
	slave.pcm null
}
Funktioniert (ohne mmap):

Code: Alles auswählen

pcm.pipe_src96k_brutefir_dither24 {
	type file
	file "| sox -D -v 0.8 -r 44.1k -b 32 -c 2 -e signed -t raw - --buffer 8192 -b 64 -c 2 -e float -t raw - \
	      | resample_soxr -c 2 -B 93 -P 50 -i 44100 -o 96000 \
	      | brutefir /home/buschel/Convolver/DRC_96k_eq_stdin_stdout.conf \
	      | sox -t raw -r 96k -b 64 -c 2 -e float - --buffer 8192 -b 32 -c 2 -e signed -t raw - dither -p 24 \
	      | playhrt --verbose --verbose --stdin -k 2 -s 96000 -f S32_LE -d usbaudio"
	format "raw"
	slave.pcm null
}
playhrt bricht ab (mmap mit brutefir):

Code: Alles auswählen

pcm.pipe_src96k_brutefir_dither24 {
	type file
	file "| sox -D -v 0.8 -r 44.1k -b 32 -c 2 -e signed -t raw - --buffer 8192 -b 64 -c 2 -e float -t raw - \
	      | resample_soxr -c 2 -B 93 -P 50 -i 44100 -o 96000 \
	      | brutefir /home/buschel/Convolver/DRC_96k_eq_stdin_stdout.conf \
	      | sox -t raw -r 96k -b 64 -c 2 -e float - --buffer 8192 -b 32 -c 2 -e signed -t raw - dither -p 24 \
	      | playhrt --verbose --verbose --stdin -k 2 -s 96000 -f S32_LE -d usbaudio --mmap"
	format "raw"
	slave.pcm null
}
Viele Grüße,
Andree
Bild
frankl
Aktiver Hörer
Beiträge: 418
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Hallo Andree,

was gefällt Dir denn nicht an der --sleep Option von playhrt? Die ist genau für den Zweck, den Du hier beschreibst, eingeführt worden.

Alternativ könntest Du wohl ein ' ... | (sleep 0.2; cat) | ...' in Deine Pipe einbauen. Aber ist das besser?

In meinen Abspielskripten nutze ich auch nicht diese Option, sondern entkopple die Pipes zur Aufbereitung und zum eigentlichen Abspielen mit Hilfe von 'writeloop' und 'catloop', siehe etwa dieses Skript als Beispiel (da steht auch ein 'sleep 0.5' vor starten der Abspiel-Schleife).

Viele Grüße,
Frank
Bild
Buschel
Aktiver Hörer
Beiträge: 799
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Frank, hallo zusammen,

was ich mir besser vorstellen könnte, wäre evtl. über eine Abfrage des Pufferstatus loszulegen, und nicht über eine pures sleep. die von dir beschriebene sleep-Lösung innerhalb der pipe hilft mir auf jeden Fall auch, wenn ich nicht playhrt, sondern anderen Tools benutzen würde. Deswegen schon einmal vielen Dank dafür. Ich bin noch recht neu in der der Welt der pipes und deren Eigenschaften...

Bzgl. deiner Tools schaue ich mir gerade wie ich schon per PN geschrieben hatte das Verhalten von resample_soxr und playhrt genauer an. Bei resample_soxr beschäftigt mich vor allem wie sich die Parameter auf die berechneten SRC-Filter auswirken -- die Bandbreite führt bei sox und soxr zu anderen Ergebnissen. Und auch das Setzen von precision=33 führt auf den ersten Blick (ich habe nur die Impulsantwort als float64 ausgeben lassen) zu diskussionswürdigen Ergebnissen. Ich sehe z.B. nicht, dass die Sperrdämpfung höher ist als mit precision=28. Filter mit precision=33 sind aber steiler und damit länger, weil sie die höhere Dämpfung erreichen wollen. Prinzipiell sind die resaple_soxr-Filter steiler und deswegen auch länger als die über sox berechneten.

Bild
Gleiche Sperrdämpfung bei soxr prec=28 und soxr prec=33 im Vergleich zu sox -v

Bild
Ähnliches Verhalten von "resample_soxr -B 89" und "sox -rate b 93. prec=33 erzeigt steilere und damit längere Filter."

Bei playhrt suche ich nach einer anderen Implementierung der extra-bps-Nachführung, die das Sonderverhalten meines HTPC abdeckt. Problem dabei: Bei meinem HTPC läuft die interne Clock ungenau und interessanterweise als eine Art tri-state während der ersten 500-1000 Sekunden. In diesen ersten Sekunden läuft die Clock mit einer Abweichung von entweder +0.4% oder -0.4% oder +0.02%. Nach 500-1000 Sekunden fällt die Clock dann auf stabile +0.02% zurück und verbleibt dort. Die derzeitige playhrt-Implementierung macht einmalig eine Messung und Anpassung. Wenn dies in den ersten 500-100 Sekunden erfolgt, werden in meinem Fall zu hohe extra-bps angenommen, die kurz nach Einrasten der Clock auf +0.02% zu Under- oder Overflow führen.

Als generischen Lösungsansatz habe ich einen PID-Regler eingebaut. Dieser führt extra-bps immer nach und passt den Wert für extra-bps fortlaufend an die Gegebenheiten an. PID-Kern:

Code: Alles auswählen

ab_err = avgav/16 - hwbufsize/2;
ab_err_i = ab_err_i + ab_err;
ab_err_d = ab_err - ab_err_alt;
ab_err_alt = ab_err;

extrabps = (double)(ab_err*0.4 + ab_err_d*0.1 + ab_err_i*0.01);

extraerr = 1.0*bytesperframe*rate;
extraerr = extraerr/(extraerr+extrabps);
nsec = (int) (1000000000*extraerr/loopspersec);

fprintf(stderr, "playhrt: target: %ld ist: %ld e: %d ei: %d ed: %d extra: %d\n", 
  hwbufsize/2, avgav/16, ab_err, ab_err_i, ab_err_d, (int)extrabps);
Frage: Soll ich die playhrt und resample_soxr Themen hier weiter posten, oder lieber in einen eigenen Thread bringen?

Viele Grüße,
Andree
Bild
Buschel
Aktiver Hörer
Beiträge: 799
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo nochmal,

ich konnte bei soxr das unterschiedliche Verhalten leider nicht weiter eingrenzen. Die andere Parameter sehe alle ok aus. Möglicherweise liegt das an der soxr-Version? Bei mir ist noch 0.1.1-1 installiert. Um die neueren zu installieren, müsste ich entweder eine VM mit einer neuen Linux-Version anlegen oder meinen HTPC updated. Das ist mir zu aufwändig. Ich lebe erst einmal damit, dass ich resample_soxr mit precision=28 kompiliere und "-B 89" anwende, um in etwa die gewünschten Ergebnisse zu bekommen.

Bei playhrt habe ich den Regler etwas vereinfacht und verzichte auf den I-Anteil. Damit bleibt zwar ein kleiner Fehler übrig, aber das stört nicht wirklich. Jetzt beobachte ich erst einmal wieder die Stabilität.

Viele Grüße,
Andree
Bild
Antworten