Software Experimente mit Linux

[Daihedz]

Hallo Jürgen

Eine Beobachtung zu den delayed loops von playhrt:

...
playhrt: number of delayed loops: 5 (67151 sec 30786486 nsec)

Sie treten bei play_simple und bei play_writecatloop auf. (Wenn ich allerdings in play_writecatloop die Priorität von playhrt mit ``chrt -f 99'' erhöhe, entfallen diese Zeilen bei der Wiedergabe.) Normalerweise steigt die Anzahl der verspäteten Loops langsam an (wenn man einen vernünftigen Wert für EXTRABYTESPLAY gefunden hat.) Darf das passieren, oder sollte es vermieden werden?

Ich bin wieder einmal daran, neue Skript-Varianten durchzuprobieren und habe dabei folgendes beobachtet: Bei mir kommen die "delayed loops" nur dann vor, wenn ich playhrt mit dem Parameter --verbose --verbose aufstarte. Damit gibt playhrt während des Abspielens laufend auf der Console den Stand der Dinge aus, dies mit hoher Priorität, da playhrt ja mit hoher (RT-) Priorität läuft und whs. entsprechende Interrupts zur Videoausgabe verursacht. Wenn ich hingegen bloss den Parameter --verbose schalte, um eine Video-Ausgabe nur noch nach dem Ende des Abspielens zu erhalten, dann habe ich 0 delayed loops.

Damit ist für mich klar: Bei mir sind die delayed loops durch den Parameter --verbose --verbose und die konsekutive Videoausgabe verursacht. Deshalb sollte --verbose --verbose wirklich nur für Abstimmungszwecke (z.B. zur Feinabstimmung des Werts von --hw-buffer) geschaltet werden, danach besser nicht mehr. Steht ja auch so in den Empfehlungen von Frank.

Ab-sofort-non-delayed-Grüsse
Simon

[koslowj]

Hallo Simon,

Danke für den Tipp, das hört sich sehr plausibel an.

An die anderen Nutzer von Franks Frogrammen (und an Frank):

Ich habe inzwischen eine von Frank auf Seite 5 dieses Threads beschreibene Skript-Lösung umsetzen können, bei der die Dateien in wav umgewandelt und dann konkateniert werden. Funktioniert recht gut für gerippte CDs, braucht aber eine lange Vorlaufzeit und viel shared Memory. Mein Voyage-Rechner hat 2 GB, davon habe ich nur die Hälfte gewagt zu nutzen. Bei 24/96 Material reicht 1 GB oft nicht aus. Prinzipiell sollte es auch möglich sein, flac-Dateien aneinanderzuhängen, aber leider hat das beim ersten Versuch nicht funktioniert. Muß nochmal forschen, woran es gelegen hat.

Noch eine Anmerkung zum Thema DSD. Jemand hat Sox um DSD-Funktionalität erweitert

http://www.computeraudiophile.com/f11-s ... ndex2.html

Auf meinem Hauptrechner ist es mir sogar gelungen, ein so modifiziertes Sox zu kompilieren (unter Gentoo Linux), aber auf der Voyage-Box hat das leider nicht funktioniert. Bisher kann ich DSD-Dateien nur unter MPD auf dem Voyage-Rechner abspielen. Dann ist wiederum problematisch, die Dateien zu finden, da der MPD-Client Theremin auf dem MacBook anscheinen gemäß der Tags sortiert, und nicht gemäß der Verzeichnisse...

Die andere Baustelle besteht darin, Daphile (kann inzwischen auch brutefir) auf die Voyage-Box zu bekommen. Leider komme ich mit konventionell bootfähigen USB-Sticks nicht weiter. Und eine Portierung von Rune auf x86, die mal erwähnt wurde, läßt noch immer auf sich warten.

Familienfreundlich ist das alles noch nicht, aber die Qualität von Franks Programmen macht das zum großen Teil wieder wett!

-- Jürgen

[frankl]

Ich bin wieder einmal daran, neue Skript-Varianten durchzuprobieren und habe dabei folgendes beobachtet: Bei mir kommen die "delayed loops" nur dann vor, wenn ich playhrt mit dem Parameter --verbose --verbose aufstarte. Damit gibt playhrt während des Abspielens laufend auf der Console den Stand der Dinge aus, dies mit hoher Priorität, da playhrt ja mit hoher (RT-) Priorität läuft und whs. entsprechende Interrupts zur Videoausgabe verursacht. Wenn ich hingegen bloss den Parameter --verbose schalte, um eine Video-Ausgabe nur noch nach dem Ende des Abspielens zu erhalten, dann habe ich 0 delayed loops.

Hallo Simon,

das klingt für mich plausibel. Das Doppel "--verbose" ist ja wirklich nur dafür gedacht, leichter die passenden Parameter zu finden. Da dadurch ständig Ausgaben auf das Terminal geschickt werden, können durchaus einige zusätzliche delayed loops vorkommen. Das ist auf meinem Rechner, der den DAC füttert, auch so (200 delayed loops in 2 Minuten mit doppeltem --verbose und nur noch 35 in 2 Minuten mit einfachem --verbose, beide Zahlen sind aber wohl vernachlässigbar).

Viele Grüße,
Frank

[frankl]

An die anderen Nutzer von Franks Frogrammen (und an Frank):

Ich habe inzwischen eine von Frank auf Seite 5 dieses Threads beschreibene Skript-Lösung umsetzen können, bei der die Dateien in wav umgewandelt und dann konkateniert werden. Funktioniert recht gut für gerippte CDs, braucht aber eine lange Vorlaufzeit und viel shared Memory. Mein Voyage-Rechner hat 2 GB, davon habe ich nur die Hälfte gewagt zu nutzen. Bei 24/96 Material reicht 1 GB oft nicht aus. Prinzipiell sollte es auch möglich sein, flac-Dateien aneinanderzuhängen, aber leider hat das beim ersten Versuch nicht funktioniert. Muß nochmal forschen, woran es gelegen hat.

Hallo Jürgen,

Wenn man wav-Dateien hintereinander hängt, müsste es eigentlich immer einen kleinen Knackser zwischen den Stücken geben, weil diese einen Kopf (typischerweise 88 Bytes) mit Informationen über die Datei haben. Die auf den Kopf folgenden raw-Daten sind ja unkomprimiert und können abgespielt werden.

Bei flac gibt es auch einen Kopf, der benötigt wird, um die folgenden komprimierten Daten überhaupt zu dekodieren. Wenn man flac-Dateien hintereinanderhängt, kann man nur die erste abspielen. Man muss schon die Dateien alle dekodieren und den hintereinandergehängten Stream wieder als flac kodieren.

Mein Odroid-Rechner hat auch 2 GB Arbeitsspeicher. Dort benutze ich einen headless Kernel und nutze 1.75 GB für die RAM-Disk, in die ich meine Musik als flac vor dem Abspielen kopiere. Das reicht für alles, außer 192/24 Dateien mit mehr als etwa 35 Minuten.

Noch eine Anmerkung zum Thema DSD. Jemand hat Sox um DSD-Funktionalität erweitert

Zum DSD Abspielen kann ich nicht viel sagen. Für meine Raumkorrektur konvertiere ich ja alles zu 192/32 PCM.

Viele Grüße,
Frank

[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!)

[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ß

[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

[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

[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:



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

Viele Gruesse,
Tobias

[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

[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

[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

[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

[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:

# 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

[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.