Software-Experimente mit Linux

frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Software-Experimente mit Linux

Beitrag von frankl »

Hallo Forenten,

in einem anderen Thread (http://aktives-hoeren.de/viewtopic.php?f=30&t=4510) habe ich von einem Hardware-Projekt berichtet, das einen sehr guten Audio-Rechner hervorgebracht hat, der meinen USB DAC beliefert (asynchron, USB 2.0). Hier möchte ich kurz ein paar Ideen beschreiben, mit denen ich die Wiedergabe durch Software weiter verbessern konnte; einiges davon ist vielleicht auch bei anderem Hardware-Setup interessant. Alle Experimente wurden ausschließlich auf Linux-Rechnern gemacht.

Beim Abspielen eines digitalen Audiosignals gibt es diverse "Jitter"-Probleme, was bedeutet, dass das digitale Signal nicht zum optimalen Zeitpunkt beim DAC ankommt. Die digitale Information wird ja mittels analoger Signale übertragen. Der Vorteil ist, dass es eine große Bandbreite gibt, wie dieses analoge Signal aussehen kann, um die digitale Information noch "bit-genau" rekonstruieren zu können. Aber "bit-genau" ist im Hinblick auf Klangqualität nicht gut genug.


Vielleicht kann man zwei Hauptprobleme so beschreiben:

(a) Durch diverse Hardware-Komponenten eines Rechners, Kabel, und nicht-optimale Stromversorgung wird das digitale Signal durch zufällige Störungen überlagert.

(b) Es gibt zeitliche Variationen im Digitalsignal, die eher systematisch beim Abspielen entstehen durch die Abspielsoftware.

Das Problem (a) konnte ich durch das oben zitierte Hardware-Projekt ganz erfolgreich verringern.

Hier wollte ich ein paar Experimente aufzählen, mit denen ich versucht habe Problem (b) zu verringern, teilweise auch mit klar hörbarem Erfolg.

Bei mir sind beim Musikabspielen immer mindestens 2 Rechner beteiligt, ein Zuspielrechner und der Audio-Rechner, an dem der USB DAC hängt. Beim Zuspielrechner gibt es die Variante, bei dem die originalen Musikdateien beim Abspielen noch durch einen Raum-/Systemkorrektur- und andere Filter geschickt werden. Oder es gibt die Variante eines schwächeren Rechners, der bereits vorgefilterte Daten zum Audio-Rechner schickt.

(1) Es ist unter Linux sehr leicht, alle nicht benötigten Prozesse abzuschalten und Kernel-Module zu entfernen (Kommandos "service ... stop", "pkill ..." und "rmmod ..."). Damit wird die Chance erhöht, dass mein eigentliches Abspielprogramm auch "dran" ist, wenn es soll.

Zum Beispiel laufen auf meinem Audio-Rechner neben meinem eigentlichen Abspielprogramm nur noch etwa 25 Kernel-Prozesse für den Zugriff auf die benötigte Hardware und das Prozessmanagement. Nur 5 davon haben in den 3 Monaten seit dem letzten Booten mehr als 1 Sekunde Rechenzeit benötigt.

Dies alleine bringt keine dramatische Klangverbesserung - aber es ist immer gut, potenzielle Störquellen ganz auszuschalten.

(2) Man kann unter Linux leicht wichtigen Prozessen eine hohe Priorität im "Realtime Scheduler" geben (Kommando 'chrt'). Das ist gut für das eigentliche Abspielprogramm, das die Daten zu DAC/Soundkarte oder ins Netzwerk schickt.

(3) Wenn in Linux Daten durch mehrere Programme geschickt werden (Pipes) oder Daten vom Netzwerk oder aus einer Datei gelesen werden, dann legt das Betriebssytem Datenpuffer an, verwaltet diese und sorgt dafür, dass Prozesse angehalten werden, solange keine Daten vorliegen. Die Details sind hier nicht so leicht zu verstehen und zu beeinflussen. Man kann aber mit Buffergrößen experimentieren, die sich mit dem Programm 'stdbuf' beeinflussen lassen. Zum Beispiel kann es (kleine) klangliche Vorteile geben, wenn die Programme, die Daten ins Netzwerk schreiben oder von dort lesen, einen größeren Buffer bekommen.

(4) Ich habe etwas mit dem Abspielen aus dem Arbeitsspeicher (RAM) experimentiert. Zum Beispiel auf dem Audio-Rechner direkt eine im RAM gespeicherte Datei spielen statt einen Stream vom Netzwerk. Oder vorgefilterte Daten auf dem Zuspielrechner aus dem RAM statt von Festplatte lesen. In beiden Fällen konnte ich (allerdings eher geringfügige) Verbesserungen feststellen. Meine genannten Rechner haben aber nur 256 MB RAM, so dass Abspielen aus dem RAM nur für kurze Teststücke praktikabel ist.

Für eine praktikable Variante habe ich zwei kleine (C-)Programme geschrieben, die einen Datenstrom zyklisch in mehrere Dateien schreiben, beziehungsweise diese Dateien lesen und wieder als Datenstrom ausgeben. Wenn ich dies für die Datenpufferung im RAM verwende und die Dateien nicht zu klein wähle (etwa ein paar MB), dann ist diese Variante genauso gut, wie das Abspielen einer vorher in den RAM kopierten Datei (auf dem Audio-Rechner und auch auf dem Zuspielrechner bevor der Datenstrom ins Netzwerk geschrieben wird).

Eine deutliche Verbesserung ergibt sich, wenn die Hilfsdateien für die Datenpufferung so klein gewählt werden, dass sie in den Prozessorcache passen (etwa nur ein paar kB). (256 MB sind also unnötig viel Arbeitsspeicher!)

(5) Mit den in (1)-(4) genannten Ideen konnte ich bereits eine gute Verbesserung der Wiedergabe erreichen. Der wirklich große Schritt vorwärts wurde dann durch folgende Idee erreicht: Man kann den Linux Kernel mit "High Resolution Timer" kompilieren, was ich für meine Rechner getan habe. Die GNU C-library hat "realtime"-Funktionalität, die durch Funktionen 'clock_getres', 'clock_nanosleep' und ein paar mehr verfügbar ist. Hiermit kann man einen Prozess bis zu einem vorgegebenen Zeitpunkt anhalten (mit 'clock_nanosleep' im Modus 'TIMER_ABSTIME', siehe UNIX man-pages für weitere Details).

Dies benutze ich nun, um Datenströme mit sehr genauem Timing zu erzeugen. Ich habe einige kleine (C-)Programme geschrieben, die etwa so funktionieren: in einer Schleife (die zum Beispiel 2000 Mal pro Sekunde durchlaufen wird) werden Datenblöcke (aus einer Datei, von einer Pipe oder aus dem Netzwerk) gelesen und in einen Puffer geschrieben, die als nächstes herauszuschreibenden Daten werden vorbereitet, dann wird der Prozess bis zu einem vorgegebenen Zeitpunkt schlafen gelegt, und nach dem Aufwachen wird als allererstes ein Datenblock herausgeschrieben.
Zum Beispiel läuft jetzt auf meinem Audio-Rechner ein solches Programm. Es füllt einen Puffer, indem es Daten vom Netzwerk liest, legt sich schlafen und schreibt nach dem Aufwachen einen Datenblock direkt in den Puffer des USB-Audio Treibers, usw. Das ist so präzise, dass ich den Puffer des Treibers sehr klein wählen kann (8kB) und die Daten im non-blocking Modus dort hineinschreiben kann, ohne dass es in 80 Minuten (Daten im 192/32 Format, mehr als 7GB) zu einen Überlauf oder Unterlauf dieses Puffers kommt. Auch hat der Interrupt-Prozess des Kernels nichts mehr zu tun, weil ich auch auf dem Zuspielrechner mit einem kleinen Programm dafür sorge, dass der Audio-Rechner nur genau so viel Daten über das Netzwerk bekommt, wie er braucht; auf diese Weise werden die Puffer für die Netzwerkverbindung nie voll (oder leer).

(6) ... ich habe noch eine Reihe von Ideen, alle paar Wochen probiere ich mal was Neues und wenn ich meine, dass eine Änderung den Klang verbessert hat, teste ich das wieder für ein paar Wochen. Im Moment habe ich einen Raspberry Pi als Netzwerk-Zwischenpuffer zwischen meinem Zuspiel- und dem Audiorechner laufen; da ist fast kein Unterschied mehr zwischen Daten on-the-fly filtern und dem Abspielen von vorgefilterten Daten.

----

Klangbeschreibungen lasse ich jetzt mal. Ich könnte einige der begeisterten Beschreibungen aus den Windows-Optimierung Threads in diesem Forum hierher kopieren. Ich habe selbst nie ein optimiertes Windows Setup gehört, kann also nichts über einen Vergleich sagen (der sicher interessant wäre).

Falls jemand hierdurch angeregt wurde, selbst in dieser Richtung zu experimentieren, kann ich gerne weitere Details erklären. Umgekehrt sind natürlich auch Tipps für weitere Verbesserungen willkommen.

Viele Grüße,
Frank

PS: Gar nicht geredet habe ich hier über die Filter, durch die meine Musikdaten vor dem Abspielen geschickt werden, das ist eine andere Geschichte.
Bild
Martin
Aktiver Hörer
Beiträge: 116
Registriert: 15.03.2012, 14:23

Beitrag von Martin »

Hallo Frank,

ich finde Deine Variante höchst interessant. Zur Zeit nutze ich noch Voyage MPD auf einem Intel ATOM board und würde auch gerne auf etwas Kleineres umsteigen. Wie geht das bei Dir mit der Bedienung? Kann man auch über ein Tablet die Musik auswählen so ähnlich wie mit Mpdroid? Was macht der Raspberry Pi genau? Fragen über Fragen. Über weitere Einzelheiten würde ich mich sehr freuen.

Liebe Grüße
Martin
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Martin hat geschrieben:Hallo Frank,
ich finde Deine Variante höchst interessant. Zur Zeit nutze ich noch Voyage MPD auf einem Intel ATOM board und würde auch gerne auf etwas Kleineres umsteigen. Wie geht das bei Dir mit der Bedienung? Kann man auch über ein Tablet die Musik auswählen so ähnlich wie mit Mpdroid? Was macht der Raspberry Pi genau? Fragen über Fragen. Über weitere Einzelheiten würde ich mich sehr freuen.
Hallo Martin,

zur Software, die auf meinem Aria G25 Board läuft habe ich hier etwas geschrieben.

Zur Bedienung: Vermutlich will das hier niemand so genau wissen oder nachmachen. Ich ignoriere sämtliche verbreiteten Programme zum Speichern und Abspielen von Musik. Alle Programme, die ich mal angesehen habe, taten nicht, was ich wollte; da fand ich es einfacher (und viel flexibler zum Herumexperimentieren), alles mit eigenen kleinen Skripten zu machen. (Von Konzept und Flexibilität her, fand ich 'mpd' noch am interessantesten.)

Ich starte die Musik meist von einem Netbook aus (lautlos, mit Lüfter und Festplatte abgeschaltet),
es geht aber von jedem Gerät mit ssh und Terminalemulation. Ich logge mich per ssh auf dem Rechner mit den Musikdaten ein und benutze die Kommandozeile. Wenn es wirklich jemand wissen will, könnte ich mehr Details geben . . .

Sollte ich irgendwann mal ein graphisches Interface zum Abspielen haben wollen, würde ich dafür einen einfachen Webserver schreiben. Das wäre sehr flexibel, leicht an persönliche Wünsche anzupassen, und
könnte von jedem Gerät mit Webbrowser bedient werden.

Zum Raspberry Pi: Der schickt im Moment die Audiodaten über das Netzwerk zum Audiorechner.
Die Daten kommen entweder vorgefiltert von einer angehängten USB-Festplatte, oder sie kommen
über das Netzwerk von einem stärkeren Rechner, der die Musik on-the-fly filtert. Im zweiten Fall dient
der Raspberry Pi also als Puffer zwischen dem stärkeren Rechner und dem Audiorechner. In beiden Fällen
schickt der Raspberry Pi mit den am Anfang des Threads geschilderten Tricks die Daten in sehr regelmäßigen Häppchen in sehr regelmäßigen Zeitabständen an den Audiorechner (Aria G25).

Viele Grüße von
Frank
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 3997
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo Frank,

Du kommst zwar von der anderen Richtung - also nicht abspecken, sondern minimal beginnen und schauen, was man braucht - aber Deine Erfahrungen und Erkenntnisse decken sich mit großer Wahrscheinlichkeit mit dem, was Philipp oder Josef vorgefunden haben.

Für mich die Kernaussage:
um Datenströme mit sehr genauem Timing zu erzeugen
Entscheidend für die Verbreitung Deiner PC-Audio-Anwendung wird - neben dem Klang - die möglichst einfache Installation und spätere Bedienfreundlichkeit sein.

Weiterhin viel Erfolg und Spaß bei Deiner tollen Arbeit.


Gruß

Bernd Peter
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo Frank

Ich finde Deine Initiative hoch interessant und inhaltlich bereichernd für das Forum.
frankl hat geschrieben: ... Zur Bedienung: Vermutlich will das hier niemand so genau wissen oder nachmachen. Ich ignoriere sämtliche verbreiteten Programme zum Speichern und Abspielen von Musik. Alle Programme, die ich mal angesehen habe, taten nicht, was ich wollte; da fand ich es einfacher (und viel flexibler zum Herumexperimentieren), alles mit eigenen kleinen Skripten zu machen. (Von Konzept und Flexibilität her, fand ich 'mpd' noch am interessantesten.)...

Ich starte die Musik meist von einem Netbook aus (lautlos, mit Lüfter und Festplatte abgeschaltet),
es geht aber von jedem Gerät mit ssh und Terminalemulation. Ich logge mich per ssh auf dem Rechner mit den Musikdaten ein und benutze die Kommandozeile. Wenn es wirklich jemand wissen will, könnte ich mehr Details geben . . .
Doch, doch, bitte etwas mehr Details zu Deinen Skripten. Du hast mal etwas davon geschrieben, dass Du offenbar ausschliesslich sox verwendest. Ist somit auch SOX in Deinen Skripten eingebunden? Publiziere doch, falls Du magst, Deine Skripte. Wäre sehr gespannt darauf.

Grüsse
Simon
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Bernd Peter hat geschrieben: Du kommst zwar von der anderen Richtung - also nicht abspecken, sondern minimal beginnen und schauen, was man braucht - aber Deine Erfahrungen und Erkenntnisse decken sich mit großer Wahrscheinlichkeit mit dem, was Philipp oder Josef vorgefunden haben.

Für mich die Kernaussage:
um Datenströme mit sehr genauem Timing zu erzeugen
Hallo Bernd Peter,

klar, da muss es einige Überschneidungen mit den Überlegungen zu den optimierten Windows-Setups geben. Leider finde ich zu diesen Projekten aber keine praktischen Details, wie diese ihre Verbesserungen erreichen. Die Forendiskussionen drehen sich immer nur um Installation und Konfiguration. Hat jemand da einen interessanten Link? (Vielleicht sind die Interna in diesen Fällen auch Geschäftsgeheimnisse...)
Bernd Peter hat geschrieben: Entscheidend für die Verbreitung Deiner PC-Audio-Anwendung wird - neben dem Klang - die möglichst einfache Installation und spätere Bedienfreundlichkeit sein.
Zunächst mal wollte ich nur den hiesigen Diskussionen der Windows-Optimierer entgegensetzen, dass man die Sache auch anders angehen kann (und ein bisschen möglichen Diskussionsstoff für das Forumstreffen in die Runde werfen). Mein Ziel ist es erstmal nicht, ein Produkt zu erstellen, das möglichst viele Leute benutzen sollen. Eher einen Baukasten, aus dem sich Interessenten bedienen können.

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

Beitrag von frankl »

Daihedz hat geschrieben:Doch, doch, bitte etwas mehr Details zu Deinen Skripten. Du hast mal etwas
davon geschrieben, dass Du offenbar ausschliesslich sox verwendest. Ist
somit auch SOX in Deinen Skripten eingebunden? Publiziere doch, falls Du
magst, Deine Skripte. Wäre sehr gespannt darauf.
Hallo Simon und Forenten, die vielleicht mal selbst mit Linux experimentieren wollen,

die exakten Skripte, die ich meist benutze, dürften nicht so interessant sein, weil sie unter anderem darauf beruhen, wie ich meine Musik auf der Festplatte gespeichert habe. (Wer es wissen will: bei mir sind ganze Alben immer in einer .flac-Datei und die Metadaten stehen in Dateien im .toc und cddb Format.)

Meine Anmerkung zu 'sox' bezog sich auf eine lange verlinkte Liste von Audio-Software unter Linux, von der ich nur 'sox' benutze. Und zwar benutze ich es zur Änderung des Audioformates und zum Resamplen (es enthält den besten Resampler, den ich kenne).

Ich beschreibe aber mal meinen Ansatz anhand ein paar einfacher Kommandos und Skripte zum Abspielen einer Audiodatei auf einem anderen Rechner (beide mit Linux), für nähere Informationen zu den erwähnten Programmen bitte die man-Pages ansehen (zum Beispiel 'man flac'), oder http://ixquick.com bemühen. Wer Lust hat, kann das mal ausprobieren und variieren.

Wir zerlegen die Aufgabe erstmal in einige Teilaufgaben.

(1) Verwandeln der Datei, sagen wir "a.flac", "b.wav" oder "c.mp3" (brrrr) in einen Stream von Rohdaten. Das geht so:

Code: Alles auswählen

flac -d -c --force-raw-format --sign=signed --endian=little a.flac

Code: Alles auswählen

sox a.flac -t raw -

Code: Alles auswählen

sox b.wav -t raw -
(sorry, für c.mp3 bitte selbst rausfinden, je nach Konfiguration macht sox
das auch)

(2) Rohdaten von Rechner S (Server) zu Rechner A (Audiorechner) schicken. Zum Beispiel effizient und ohne Verschlüsselung mit 'nc' (falls nicht vorhanden, ein Paket 'netcat' installieren):

Auf S:

Code: Alles auswählen

nc -l -q 0 -p 3456
(die letzte Zahl ist irgendeine Portnummer, die größer 1024 sein sollte, -l heißt, dass auf eine Verbindung gewartet wird)

Auf A (wir brauchen einen Namen oder die IP-Adresse, mit der S angesprochen werden kann; eventuell mit 'ifconfig' auf S rausfinden, nehmen wir zum Beispiel an, dass S die IP-Adresse 10.0.0.100 hat):

Code: Alles auswählen

nc 10.0.0.100 3456
Jetzt kann man beliebige Zeilen auf S tippen und mit <RETURN> abschicken, die Zeilen erscheinen auf A. Und umgekehrt! Abbruch durch Tippen von <Ctrl-d> auf S.

(3) Rohdaten auf Audiorechner A abspielen. Wir können 'aplay' verwenden, das mit ALSA kommt. Wir müssen die ALSA-Bezeichnung der Soundkarte kennen. Dazu etwa 'aplay -l' auf Rechner A probieren. Wir brauchen die card- und die device-Nummer der gewünschten Soundkarte; bei nur einer Soundkarte vermutlich beides 0; dann ist der ALSA-Name "hw:0,0". Außerdem müssen wir das Audioformat der Rohdaten kennen, die aplay auf der Standardeingabe erhält; sagen wir a.flac, b.wav sind im CD Format.

Code: Alles auswählen

aplay -t raw -f cd -D "hw:0,0"
oder expliziter

Code: Alles auswählen

aplay -t raw -f S16_LE -c2 -r44100 -D "hw:0,0"
(4) Zusammensetzen.
Hierzu können wir 'Pipes' benutzen; das ist ein Standardmechanismus unter UNIX/Linux, notiert

Code: Alles auswählen

program1 | program2
bei dem die Ausgabe von program1 als Eingabe von program2 benutzt wird. Zum Beispiel auf Rechner S:

Code: Alles auswählen

sox a.flac -t raw - | nc -l -q 0 -p 3456
schickt unsere Rohdaten ins Netz;

auf Rechner A holen wir sie ab und spielen sie:

Code: Alles auswählen

nc 10.0.0.100 3456 | aplay -t raw -f S16_LE -c2 -r44100 -D "hw:0,0"
(5) In Skripte verpacken.
Wir wollen die Zeilen oben nicht immer wieder tippen, also kommen sie in
Skripte. Auf Rechner S wollen wir einfach nur tippen

Code: Alles auswählen

schicke4416 a.flac
Das Skript 'schicke4416' kann so aussehen:

Code: Alles auswählen

#!/bin/bash
# $1 ist das erste Argument
sox $1 -t raw - | nc -l -q 0 -p 3456
Auf Rechner A:

Code: Alles auswählen

spiele4416
wobei das Skript 'spiele4416' so aussieht:

Code: Alles auswählen

#!/bin/bash
nc 10.0.0.100 3456 | aplay -t raw -f S16_LE -c2 -r44100 -D "hw:0,0"
--------
Wenn man so etwas noch nie gesehen hat, sieht das alles vielleicht kompliziert aus. Aber wenn man die Grundideen verstanden hat, ist es nicht so schwierig, und der Ansatz ist enorm flexibel. Wir haben jetzt zwei 1-Zeilen Skripte zum Abspielen einer Musikdatei auf einem anderen Rechner, ohne kompliziertere Dinge 'jack', 'pulseaudio', 'ecasound', ... zu verwenden.

Die einzelnen Schritte lassen sich nun einzeln und nach und nach weiter verbessern. Zum Beispiel:

(6) Wir wollen nicht für jedes Stück erneut das Skript auf Rechner A starten, und wir wollen auch andere Sample-Raten spielen.

OK, ersetzen wir 'spiele4416' durch die folgende Variante, die nur einmal auf A aufgerufen werden muss:

Code: Alles auswählen

#!/bin/bash
while true; do
  # lesen Sample-Rate auf Port 4444
  rate=`nc -l -p 4444`
  sleep 0.1 # 0.1 Sekunden warten
  nc 10.0.0.100 3456 | aplay -t raw -f S16_LE -c2 -r $rate -D "hw:0,0"
done
Auf Rechner S ersetzen wir 'schicke4416' durch (nehmen wir an, dass A die IP-Adresse 10.0.0.101 hat):

Code: Alles auswählen

#!/bin/bash
# erstes Argument ist Dateiname, zweites die Samplerate
# schicke Sample-Rate und starte Abspielen auf A
echo $2 | nc -q 0 10.0.0.101 4444
# jetzt schicke Audio Daten
sox $1 -t raw - | nc -l -q 0 -p 3456
(7) In diesem Setup ist es nun ganz leicht, die Musikdaten durch beliebige weitere Programme zu 'pipen'. Zum Beispiel Upsampling und Falten per brutefir. Etwa statt der letzten Skript-Zeile (wir geben als 3. Argument die Bit-Tiefe):

Code: Alles auswählen

flac --totally-silent --force-raw-format --sign=signed --endian=little -d -c $1 | sox -t raw -r $2 -c 2 -e signed -b $3 - -t raw -e floating-point -b 64 - | sox -t raw -c2 -r $2 -e floating-point -b 64 - -t raw -e floating-point -b 64 - vol 0.4  rate -v -I 192000 | brutefir /pfad/zur/config | nc -l -q 0 -p 3456
Das Ausgabeformat von 'brutefir' muss dann dem Format entsprechen, das wir auf A abspielen wollen. Dies Beispiel demonstriert auch, wie man effizient 'sox' zum Upsamplen benutzen kann.

------

So, vielleicht sind das genug Beispiele, damit interessierte Leser selbst herumzuspielen und Varianten für das eigene Setup finden können.

Viele Grüße,
Frank

PS: Die von mir geschriebenen Programme, die ich im Eingangsbeitrag dieses Threads erwähne, könnte ich bei Interesse auch verfügbar machen. Ich bräuchte dann nur etwas Zeit, diese mit Copyright und Lizenzinformationen (GPL) sowie rudimentärer Dokumentation zu versehen. Sie sind noch nicht sehr elegant - eben work in progress.
Bild
Martin
Aktiver Hörer
Beiträge: 116
Registriert: 15.03.2012, 14:23

Beitrag von Martin »

Hallo Frank,
wirklich sehr schön gemacht! Ich konnte wieder einige wichtige Linux-Grundlagen lernen. Damit kann man etwas anfangen und eigene Versuche starten. Bitte ruhig noch mehr davon!

Viele Grüße
Martin
Bild
axxxxx

Beitrag von axxxxx »

Hallo Frank,

ich habe zwar keine Ahnung, aber davon reichlich. :mrgreen:

Wie bereits gesagt, finde ich, daß der Linux-Ansatz eigentlich viel sinnhafter ist, als den Weg über MS zu gehen. Insofern freue ich mich über jeden weiteren Schritt in diese Richtung.

Gruß,
Kai
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Grüssdich Frank

Danke für Deinen anregenden Input - Das animiert zum eigenen kreativen Experimentieren!

Eine Frage an Dich zu SOX und zur Samplerate Conversion: Auf http://sox.sourceforge.net/Docs/FAQ und http://sox.sourceforge.net/SoX/Resampling hat es einige Angaben dazu, und auch etwas Anschauung (z.B. http://sox.sourceforge.net/rate-96k-44k1.png). Hast Du eigene Erfahrungen mit den verschiedenen möglichen Einstellungen von SOX?

Beste Grüsse
Simon
Bild
dieter
Aktiver Hörer
Beiträge: 110
Registriert: 13.01.2009, 12:10
Wohnort: nahe Bonn

Beitrag von dieter »

Hallo,

Vielleicht ist in diesem Zusammenhang auch das hier interessant: http://www.tnt-audio.com/sorgenti/audio ... nux_e.html


Gruß,
Dieter
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Daihedz hat geschrieben: Eine Frage an Dich zu SOX und zur Samplerate Conversion: Auf http://sox.sourceforge.net/Docs/FAQ und http://sox.sourceforge.net/SoX/Resampling hat es einige Angaben dazu, und auch etwas Anschauung (z.B. http://sox.sourceforge.net/rate-96k-44k1.png). Hast Du eigene Erfahrungen mit den verschiedenen möglichen Einstellungen von SOX?
Hallo Simon,

ja, Du gibst genau die richtigen Links zur Dokumentation des Resampling mit sox an. Ich habe eine Weile 'ssrc' benutzt und als ich sox Version 14.irgendwas gesehen habe auch sox in verschiedenen Varianten ausprobiert.

Den Schritt von ssrc auf sox fand ich eine hörbare Verbesserung (nicht wie Tag und Nacht, aber es klingt anders). Die Unterschiede zwischen den Optionen für sox sind subtil, ich fand die Version am besten, die ich im Beispiel oben benutzt habe, also 'sox .... rate -v -I <rate>'. Meist ist es auch sinnvoll, die Lautstärke etwas zu senken, um Clipping beim Resamplen zu vermeiden.

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

Beitrag von frankl »

dieter hat geschrieben: Vielleicht ist in diesem Zusammenhang auch das hier interessant: http://www.tnt-audio.com/sorgenti/audio ... nux_e.html
Hallo Dieter,

ich bin ein Fan von tnt-audio, aber diesen Bericht finde ich nicht überzeugend. Es geht ja meistens nur um die Installation der getesteten Linux-Variante. Ob so ein Bericht irgend jemandem etwas nützt? Zum Schluss wird dann kommentiert, ob nun JPlay oder dieses AP-Linux besser klingen würden. Da werden aber dann Äpfel mit Birnen verglichen. Soweit ich das auf die Schnelle erkennen kann, wird in AP-Linux nichts gemacht, was man nicht leicht mit jedem Linux machen kann: Nicht benötigte Services abschalten, statt einer gnome- oder KDE-Umgebung was weniger Resourcen-hungriges starten, usw. Einen "Realtime" Kernel braucht man zum Abspielen von Musik nicht (und er ist in den meisten aktuellen Linux-Versionen leicht installiert). Am eigentlichen Abspielen wird da aber nichts optimiert, wie mir scheint. (Und trotzdem ist es laut dem Rezensenten klanglich nicht mehr weit von einem JPlay Setup entfernt.)

Viele Grüße,
Frank
Bild
Martin
Aktiver Hörer
Beiträge: 116
Registriert: 15.03.2012, 14:23

Beitrag von Martin »

Hallo Frank,

ich habe etwas mit Deinen Skripten experimentiert und das funktioniert sogar wider Erwarten auch mit mpd im Pipe-Betrieb schon ganz gut. Etwas störend empfinde ich die durch die Pipe entstehende Zeitverzögerung (ca. 3 Sekunden). Brutefir habe ich zunächst noch nicht eingebunden, außerdem dürfte Brutefir auch keine allzu große Verzögerung bringen, wenn man es so wie du es vorsiehst, vor dem Player als reinen Filter einsetzt. Versuche, mit stdbuf die Puffergröße der Pipes zu verringern erbrachten keine Verkürzung der Zeitverzögerung. Gibt es mit stdbuf noch irgend etwas zu beachten?

Die Zeitverzögerung habe ich auch ohne mpd, wenn ich nur mit sox und nc die Datei vom Server-PC zum Audio-PC sende. Hier liegt die Verzögerung bei etwa 2 Sekunden.

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

Beitrag von frankl »

Martin hat geschrieben:Hallo Frank,

ich habe etwas mit Deinen Skripten experimentiert und das funktioniert sogar wider Erwarten auch mit mpd im Pipe-Betrieb schon ganz gut. Etwas störend empfinde ich die durch die Pipe entstehende Zeitverzögerung (ca. 3 Sekunden). Brutefir habe ich zunächst noch nicht eingebunden, außerdem dürfte Brutefir auch keine allzu große Verzögerung bringen, wenn man es so wie du es vorsiehst, vor dem Player als reinen Filter einsetzt. Versuche, mit stdbuf die Puffergröße der Pipes zu verringern erbrachten keine Verkürzung der Zeitverzögerung. Gibt es mit stdbuf noch irgend etwas zu beachten?

Die Zeitverzögerung habe ich auch ohne mpd, wenn ich nur mit sox und nc die Datei vom Server-PC zum Audio-PC sende. Hier liegt die Verzögerung bei etwa 2 Sekunden.
Hallo Martin,

es freut mich, wenn meine Beispiele eine Anregung zum Experimentieren sind.

Auf Anhieb habe ich keine Idee, warum bei Dir so eine lange Zeitverzögerung entsteht. Das Aufstarten von Programmen dauert eigentlich nur wenige Millisekunden, auch das Anlegen von Pipes. Die typischen Buffergrößen sind 64kB und damit die Zeit zum Auffüllen auch vernachlässigbar.

Ich habe mal ein paar kleine Tests gemacht, vielleicht kannst Du auf ähnliche Weise herausfinden, wo die 2-3 Sekunden Verzögerung bei Dir entstehen.

Code: Alles auswählen

date +%N; date +%N
date +%N;  date +%N | cat |cat |cat |cat |cat;  date +%N
zeigt bei mir, dass das starten von 'date' und das Starten der 'cat's und der Pipes dazwischen jeweils
etwa 2 bis 3 Millisekunden braucht.
Wenn ich auf Rechner A mit IP 10.0.0.101 auf Daten warte:

Code: Alles auswählen

nc -l  33333
und auf Rechner S sage

Code: Alles auswählen

date +%N; date +%N | nc -q 0 10.0.0.101 33333 ; date +%N
dauert das mittlere Kommando mit dem Senden der Ausgabe von 'date' zum anderen Rechner auch nur etwa 4 Millisekunden.

Der Aufruf eines Programms, das viele oder große Dateien einlesen muss, kann natürlich etwas länger dauern, zum Beispiel zeigt

Code: Alles auswählen

date +%N; date +%N | brutefir /pfad/meine.conf  -quiet > /dev/null ; date +%N
dass 'brutefir' mit meiner Konfiguration (mehrere 500 kTap Filter) etwa 180 Millisekunden zum Starten braucht.

Das ist also alles weit unterhalb 2 bis 3 Sekunden.

Beim einmaligen Aufstarten ist eine Verzögerung ja eigentlich kein großes Problem (höchstens wenn Audio
und Video synchron laufen sollen). Geht es Dir hauptsächlich um das "gapless" abspielen mehrerer Stücke?

Eine Möglichkeit wäre es, Programme zum Dekodieren der Quelldateien durch Klammern zusammenzufassen. Zum Beispiel in

Code: Alles auswählen

(flac -d -c ... a.flac; flac -d -c ... b.flac) | brutefir /pfad/zur/bf.config -quiet | nc ....
werden die Ausgaben der ersten zwei Aufrufe von 'flac' aneinandergehängt und durch die Pipe an 'brutefir' geschickt.

Oder man benutzt als erstes Kommando für diese Pipes ein Skript, das in einer Schleife verschiedene Dateien dekodiert. Das macht ja vermutlich 'mpd' mit Pipe Ausgabe, oder?

Viele Grüße,
Frank
Bild
Antworten