Software-Experimente mit Linux

koslowj
Aktiver Hörer
Beiträge: 54
Registriert: 24.06.2015, 00:26

Beitrag von koslowj »

Das obige Problem mit play_upsample_convolve konnte mit Franks Hilfe gelöst werden: die Erhöhung des "sleep"-Wertes von 0.5 auf 2.5 brachte Abhilfe. Ob es auch mit kleineren Werten funktioniert, muss ich noch ausprobieren. Nun können jedenfalls weitere Experimente folgen!

-- Jürgen
Bild
FoLLgoTT
Aktiver Hörer
Beiträge: 554
Registriert: 20.01.2011, 14:05
Wohnort: Hannover
Kontaktdaten:

Beitrag von FoLLgoTT »

Hallo Frank,
ich spiele gerade mit deinen tollen Programmen rum und habe sowohl beim Durchschleifen als auch beim Abspielen mit MPD erfolgreich playhrt einsetzen können. Wenn ich das richtig verstehe, werden für die Befüllung der Soundkarte keine Interrupts mehr ausgelöst. Kann man das irgendwie messen (an der CPU-Zeit eines Kernel-Prozesses eventuell)? Ich würde das ganze sowieso gerne mal Messtechnisch erfassen. Mir ist im Moment allerdings nicht ganz klar, wie die Auswirkungen auf das Asgangssignal überhaupt sind (und warum?).

Aber zu meinem eigentlichen Anliegen: ich habe jetzt quasi eine 8-fach-Aktivweiche, die bis zu Brutefir 64 Bit Gleitkommazahlen verarbeitet (Resampling) und weiterreicht. Das ist schon mal gut und prädestiniert für eine sehr genaue Lautstärkeregelung. Volrace macht ja genau das. Allerdings hätte ich Volrace gerne hinter Brutefir. Zum einen, da ich möchte, dass Brutefir mit vollem Pegel faltet und zum anderen um die Ausgänge vor Fehlern von Brutefir zu schützen (was ja bei Falschkonfiguration schon mal vorkommt). Der ALSA-Mixer macht das bisher sehr zuverlässig, aber der ist sicherlich nicht so genau wie eine Umrechnung in Gleitkommazahlen. Hättest du eventuell Interesse daran, Volrace auf Multikanal zu erweitern? :)

Gruß
Nils
Bild
FoLLgoTT
Aktiver Hörer
Beiträge: 554
Registriert: 20.01.2011, 14:05
Wohnort: Hannover
Kontaktdaten:

Beitrag von FoLLgoTT »

Nachdem ich mir den Quellcode angeschaut habe, war mir klar, dass der Lautstärke regelnde Teil von VOLRACE bereits mehrkanalig funktioniert, da er ja einfach nur alle double-Werte skaliert, die ankommen. Also ausprobiert und es klappt. :cheers:

Jetzt muss ich mir nur noch mal genau überlegen, wie ich die Lautstärke steuern will und ggf. noch was programmieren. Ein schönes Poti oder eine App hätten z.B. was...

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

Beitrag von Daihedz »

Hallo Skripters und Pipers

Ich habe mir zum Ausprobieren der franklbin-goodies ein Skript geschrieben, welches ad hoc eine Pipe erstellt und dann eine Audiodatei, deren Name als Parameter übergeben wird, über diese Pipe abspielt. Das Ganze kann mittels einer Konfigurationsdatei praktisch beliebig zusammengestellt werden.

Beispiel, auf einem Lenovo T61-Laptop erstellt und alldorten bestens abspielend:

Code: Alles auswählen

cptoshm --buffer-size=4194312 --file=/var/tmp/privat/ramdisk/playlist_files/SilvertownBlues.wav --shmname=/inpipe_cpcat --verbose ;
sleep_pipe_programs_cptoshm ; 
shmcat --block-size=176 --shmname=/inpipe_cpcat --verbose | 
sox --buffer 1024 -b 16 -c 2 -e signed -r 44100 -t wav - -b 64 -c 2 -e floating-point -r 44100 -t raw - | 
sox --buffer 1024 -b 64 -c 2 -e floating-point -r 44100 -t raw - -b 64 -c 2 -e floating-point -t raw - vol 0.8 rate -v -I 192000 | 
volrace --verbose --param-file=/var/tmp/privat/ramdisk/volrace_runtime_parameters | 
brutefir /home/privat/_brutefir/lr-ms/brutefir_config_lr-ms | 
sox --buffer 1024 -b 64 -c 2 -e floating-point -r 192000 -t raw - -b 64 -c 2 -e floating-point -t raw - vol 0.8 rate -v -I 96000 | 
sox --buffer 1024 -b 64 -c 2 -e floating-point -r 96000 -t raw - -b 32 -c 2 -e signed -r 96000 -t raw - | 
writeloop --block-size=768 --file-size=4608 --verbose --shared /outpipe_wcl_1 outpipe_wcl_2 outpipe_wcl_3 & 
sleep_pipe_programs_brutefir ; 
sleep_pipe_programs_writeloop outbuffer ; 
catloop --block-size=768 --verbose --shared /outpipe_wcl_1 outpipe_wcl_2 outpipe_wcl_3 | 
chrt -r 99 taskset -c 0 playhrt --stdin --buffer-size=1536 --device=hw:0,0 --extra-bytes-per-second=0 --extra-frames-out=24 --hw-buffer=2048 --loops-per-second=1000 --mmap --non-blocking-write --number-channels=2 --sample-format=S32_LE --sample-rate=96000 --sleep=10 --verbose
1. cptoshm kopiert die Audiodatei ins shared memory.
2. sleep_pipe_programs_cptoshm ist ein kleines Script, welches die weitere Ausführung pausiert, bis der vorherige Vorgang (=cptoshm) ganz abgeschlossen ist.
3. shmcat liest dann die Informationen aus dem shared memory in die Pipe hinein
4./5. sox (zweimal) konvertiert das Format nach 64bit/192kHz
6. volrace
7. brutefir
8./9. sox (zweimal) konvertiert das Format ausgabebereit für die Soundkarte
10. writeloop schreibt dann häppchenweise ins shared memory ...
11./12. ... damit zwei weitere kleine sleep-skripte sicherstellen können, dass 1. brutefir operativ ist, und dass 2. aufgearbeitetes audiomaterial bereits im shared memory bereitsteht. Dann erst liest
13. catloop das Ganze aus dem shared memory zurück und gibt es weiter an ...
14. playhrt.

Diese Kaskade sichert eine einwandfreie Wiedergabe unter allen denkbaren Umständen mit minimalen Wartezeiten (d.h. mit --sleep=10 in playhrt)

Grüsse
Simon
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo Nils
FoLLgoTT hat geschrieben:Nachdem ich mir den Quellcode angeschaut habe, war mir klar, dass der Lautstärke
regelnde Teil von VOLRACE bereits mehrkanalig funktioniert
Und wie steht es bei 8-Kanal mit der Kanalzuweisung des RACE-Teils von Volrace?

Ich verwende deshalb volrace bis zur Klärung lieber vor brutefir, und überprüfe mit einem brutefir-wartescript, ob brutefir einwandfrei funktioniert, bevor Daten an den DAC weitergereicht werden.

Grüsse
Simon
Bild
FoLLgoTT
Aktiver Hörer
Beiträge: 554
Registriert: 20.01.2011, 14:05
Wohnort: Hannover
Kontaktdaten:

Beitrag von FoLLgoTT »

Hallo Simon,
Daihedz hat geschrieben:Und wie steht es bei 8-Kanal mit der Kanalzuweisung des RACE-Teils von Volrace?
Im Quellcode werden die Samples der beiden Kanäle paarweise verarbeitet. Wenn jetzt stattdessen 8 Kanäle interleaved ankommen, müssten nach meinem Verständnis jeweils zwei dieser Kanäle paarweise verarbeitet werden. Für die Lautstärke ist das egal, da können einfach alle Samples knallhart mit dem Faktor multipliziert werden.

Ich habe inzwischen auch ein kleines Script, das mit das CD-Format nach FLOAT64 konvertiert, dort verarbeitet und mit Dithering wieder an die Soundkarte ausgibt. Shared Memory habe ich bisher weggelassen, da ich von dem Nutzen nicht überzeugt bin und mir jegliche Erklärung fehlt, wie es vor playhrt überhaupt nutzen könnte. Außerdem habe ich MPD im Einsatz, was selbst von Netzwerk liest und ich den Komfort der App schätze.

Warum faltest du eigentlich mit 192 kHz und gibst dann mit 96 kHz aus? Hat das einen tieferen Sinn?

Ich bin noch am evaluieren, welche Samplerate für die Verarbeitung und Ausgabe überhaupt die sinnvollste ist, wenn zu 99,9 % nur CD-Material abgespielt wird. Im Moment bin ich bei 96 kHz, weil es den Tiefpass weit außerhalb des Nutzbereichs schiebt. 192 kHz könnte ich natürlich auch einstellen, aber welchen Nutzen bringt das noch? Arbeitet der DAC da eventuell besser? Ich weiß es nicht. Das wäre auf jeden Fall ein paar Messungen wert.

Ich fürchte, die ganze Kette an Signalverarbeitung muss mal gründlich analysiert werden. Als Entwickler weiß ich z.B. bei Performance-Verbesserungen, dass das Offensichtliche nicht immer das richtige ist und Nebeneffekte oft stärker wiegen als der Nutzen. Nur objektive Messungen bringen wirklich Klarheit. Davon kann ich inzwischen ein Lied singen. Alleine schon diese 48-kHz-Geschichte der Xonar erzeugt bei mir wieder so viel Skepsis, dass ich gar nichts mehr ungemessen glaube. ;)

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

Beitrag von frankl »

Daihedz hat geschrieben:Hallo Nils
FoLLgoTT hat geschrieben:Nachdem ich mir den Quellcode angeschaut habe, war mir klar, dass der Lautstärke
regelnde Teil von VOLRACE bereits mehrkanalig funktioniert
Und wie steht es bei 8-Kanal mit der Kanalzuweisung des RACE-Teils von Volrace?

Ich verwende deshalb volrace bis zur Klärung lieber vor brutefir, und überprüfe mit einem brutefir-wartescript, ob brutefir einwandfrei funktioniert, bevor Daten an den DAC weitergereicht werden.
Hallo Nils und Simon,

danke an Nils für zusätzliche Infos per PN. Darauf wollte ich bezüglich Lautstärkeregelung das Gleiche antworten, worauf Nils schon selbst gekommen ist (d.h., volrace funktioniert bei 8 Kanälen ohne Änderung).

Tatsächlich sollte auch das RACE (das Nils nicht nutzen will) ohne Änderung gehen,
vorausgesetzt, dass die 8 Ausgabekanäle so sortiert sind, dass die zusammen gehörenden Samples für Links und Rechts immer nacheinander kommen. Außerdem muss man den Parameter von --race-delay mit 4 (= 8/2) multiplizieren.

(Falls das Fading bei Parameteränderung ein bisschen schnell ist oder komisch klingt kann man das per --fading-length etwas verlängern.)

Viele Grüße,
Frank
Bild
FoLLgoTT
Aktiver Hörer
Beiträge: 554
Registriert: 20.01.2011, 14:05
Wohnort: Hannover
Kontaktdaten:

Beitrag von FoLLgoTT »

Hallo Frank,
frankl hat geschrieben:(Falls das Fading bei Parameteränderung ein bisschen schnell ist oder komisch klingt kann man das per --fading-length etwas verlängern.)
Das klappt auch mit dem Standardwert sehr gut. Ich habe ihn trotzdem etwas erhöht. Hauptsache ist ja, dass es durch zu schnelle Änderung der Werte nicht knackst und das tut es nicht. :)


@alle
Ich habe mal ein bisschen überlegt, wie man diese Lautstärkeregelung auf einen dicken analogen Regler bringen könnte. Mit einem USB-AD-Wandler, wie hier könnte man den Wert in einem Script zyklisch auslesen und in die Datei für Volrace reinschreiben. Das Poti könnte man dann direkt in den PC montieren oder neben dem Hörplatz oder sogar direkt im Sessel anbringen.
An der Methode gefällt mir gut, dass man etwas Haptisches hat, dass einen minimalen und einen maximalen Wert besitzt. Man könnte also schon vor dem Einschalten prüfen, wie laut es eingestellt ist (->Kinder).

Theoretisch kann man die Datei natürlich beliebig beschreiben. Eine kleine App würde es auch tun. Ist aber nicht so komfortabel, wenn z.B. MPD nebenbei läuft. Und man kann nicht mal schnell hingreifen und mit geschlossenen Augen die Lautstärke regeln. Ich hasse es, beim Wegdösen die Augen öffnen zu müssen, nur um mal kurz was zu korrigieren. Da ist so ein dicker Drehknopf schon von Vorteil. ;)

Wie habt ihr das bei euch gelöst?

Gruß
Nils
Bild
Tinitus
Aktiver Hörer
Beiträge: 1322
Registriert: 10.11.2013, 21:48

Beitrag von Tinitus »

Hallo,

ich packe diese Neuigkeit mal hier hin (zumindest für mich war das neu):

Aufgepasst bei Dual Boot PC, anscheinend geht W10 aktiv gegen Linux Partitionen vor (dass man von W10 zum gläsernen Kunden gemacht wird, wenn man nicht aufpasst hatte ja Kai schon beschrieben):

http://www.modelpromo.nl/Audio-GD_Master7-Amanero.htm

Würde mich interessieren, ob das auch bei mir passieren würden bei mir ist das Linux OS im W7 bootloader eingehängt, habe mal im Internet gefunden, dass dies besser wäre, da dadurch die beiden Systeme nichts voneinander wissen und deshalb das eine beim anderen keine Schweinereien anstellt.

Möge es nützen (frei nach unserem Musikgeniesser)

Gruß

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

Beitrag von Daihedz »

Hallo Linuxer

Eine Frage in die Runde: Wer oder was wandelt besser - brutefir oder sox?

Man nehme zu dieser Frage zwei leicht unterschiedliche Setups
Beispiel 1:
Audiodatei -> cptoshm -> shmcat -> sox -> sox -> volrace -> brutefir -> sox -> playhrt -> Soundkarte
Beispiel 2:
Audiodatei -> cptoshm -> shmcat -> sox -> sox -> volrace -> brutefir -> playhrt -> Soundkarte

In beiden Beispielen wird die Audiodatei zunächst eingelesen und die Audiodaten über das shared memory in eine pipe eingelesen (cptoshm/shmcat). Danach erfolgt eine zweistufige Umwandlung von (z.B.) 16Bit/44k1 nach 64BitFloat/192k (sox/sox), und dann die weitere Bearbeitung mittels volrace/brutefir. Volrace und brutefir bearbeiten somit 64BitFloat-Daten. Dieses Format muss zur Weitergabe an die Soundkarte typischerweise wieder in das Format S32_LE oder S16_LE zurückverwandelt werden. Hier unterscheiden sich nun die beiden Beispiele.

Beispiel 1
In der ersten Beispielvariante erfolgt die Wandlung durch einen zusätzlichen Aufruf von sox. Brutefir gibt die Daten zunächst als FLOAT64_LE an sox weiter, und sox wandelt nach S32_LE. Zuerst also brutefir mit dem Eintrag in der config
...
output "IN_L", "IN_R" {
device: "file" { path: "/dev/stdout"; } ;
channels: 2/0,1;
sample: "FLOAT64_LE";
...
}
...

und dann sox, aufgerufen mit
$ sox ... -b 64 -e float - ... -b 32 -e signed - dither -f high-shibata

Beispiel 2:
In der zweiten Beispielvariante übernimmt brutefir die Wandlung nach S32_LE gleich direkt durch einen entsprechenden Eintrag in der Brutefir config.file. Sox erübrigt sich. In diesem Fall lautet der Eintrag in der brutefir-config
...
output "IN_L", "IN_R" {
device: "file" { path: "/dev/stdout"; } ;
channels: 2/0,1;
sample: "S32_LE";
...
}
...

Intuitiv würde ich vermuten, dass sox als Spezialist besser wandelt als brutefir, und ich würde somit der zweistufigen Variante ... -> brutefir -> sox -> ... den Vorzug geben. Aber Intuitionen führen manchmal direkt in die Irre. Weiss jemand etwas mehr und Konkretes dazu (Ich meine damit das Thema der Wandlungsqualität, nicht jenes über die Intuition...)?

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

Beitrag von frankl »

Daihedz hat geschrieben: Eine Frage in die Runde: Wer oder was wandelt besser - brutefir oder sox?
Hallo Simon,

ich habe diverse Versuche mit Dithering angestellt. Bei 32-Bit Integer Ausgabe (S32_LE) kann ich nicht den geringsten Unterschied zwischen der Ausgabe mit und ohne Dithering hören. In Deinem Beispiel würde ich also den zusätzlichen Aufruf von 'sox' sparen und 'brutefir' bei der Ausgabe die triviale Konversion durch Rundung zu S32_LE machen lassen (genau so mache ich es bei mir).

Wenn dagegen die Ausgabe S16_LE sein soll, dann würde ich Deine zweite Möglichkeit nutzen und den zusätzlichen Aufruf von 'sox' mit 'dither -f high-shibata' nutzen (so habe ich es in einem früheren Setup auch gemacht).

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

Beitrag von Daihedz »

Hallo Jürgen

Eine Beobachtung zu den delayed loops von playhrt:
koslowj hat geschrieben: ...
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
Bild
koslowj
Aktiver Hörer
Beiträge: 54
Registriert: 24.06.2015, 00:26

Beitrag von 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
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Daihedz hat geschrieben: 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
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

koslowj hat geschrieben: 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.
koslowj hat geschrieben: 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
Bild
Antworten