Software Experimente mit Linux

[Melomane]

Nachtrag für einen Test, falls die Idee oben nicht zündet:

Mach aus der flac- eine wav-Datei. Und dann gib die allein aplay (ohne sox) vor, um der Formatfrage und der Kompatibilität mit der Hardware nachzuspüren.

[koslowj]

Hallo Jochen,

Guter Vorschlag! Nachdem mir dieses blöde Problem keine Ruhe gelassen hatte, habe ich inzwischen nach weiterem Studium der sox- und aplay-Hilfsdateien genau dieses ausprobiert:

sox mymusic.flac -t raw -r 88200 - | aplay -t raw -f S32_LE -c 2 -r 44100 -D hw:0,0

nachdem auf der rechten Seite der Pipe mit "-r 88200" eine Vervierfachung der Geschwindigkeit eintrat (sehr lustig für den Nachwuchs ), aber "-r 22050" nicht angenommen wurde. Und das hat in der Tat funktioniert. Die technischen Daten des USB-Eingangs des Verstärkers lauten

PCM data sampling frequency 44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, 176.4 kHz, 192 kHz, 352.8 kHz, 384 kHz
Bit resolution 16/24/32-bit
DSD data sampling frequency 2.8/5.6 MHz (DSD64/DSD128)

Die Info-Anzeige im Display behauptet, es würden PCM32 Daten mit 44.1 kHz abgespielt, was zu passen scheint. Damit kann ich endlich die weiteren Beispiele in Angriff nehmen!

-- Jürgen

Hallo Jürgen,

nur eine Idee. Es sieht für mich so aus, als wolle die Hardware unbedingt S32_LE. Möglicherweise musst du die nicht nur auf der rechten Seite der Pipe bei aplay vorgeben, sondern auch auf der linken bei sox.

Wenn das nichts nützt, muss der Experte (Frank) ran.

Gruß

Jochen

[koslowj]

Hallo,

Nach weiteren Experimenten hat sich die oben beschriebenen Lösung nur als die zweitbeste herausgestellt. Natürlich sollte man sox dazu auffordern, Daten im 32Bit-Format bereitzustellen, anstatt an der Sample-Rate herumzuspielen. Dann klappt es auch bei 24Bit 96kHz Material usw.

sox mymusic.flac -t raw -b 32 - | aplay -t raw -f S32_LE -c 2 -r 44100 -D hw:0,0

Dann ein paar Fragen:

0. Was bedeuten Ausgaben der Form

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?

1. Viele Musikstücke enden mit Ausgaben der Form

playhrt: number of delayed loops: 6 (68768 sec 64296977 nsec)
playhrt: average available buffer: 8009 (68768 sec 78263993 nsec)
playhrt: bad read, 8 bytes missing at 68770.814801485
playhrt: bad read, 352 bytes missing at 68770.815799129
playhrt: Loops: 236230 (6 delayed), total bytes: 83152608 in 83152608 out.
playhrt: Bad loops/frames written: 0/0, bad reads/bytes: 2/360

Was hat es mit den 'bad reads'' auf sich? Die scheinen ganz am Ende aufzutreten. Die "input chunk size" dürfte bei 360 gelegen haben, was gerade 8+352 ist. Vermutlich ist das unerheblich.

2. Die "bad reads" machen es mir bisher leider auch unmöglich, play_upsample_convolve auszuprobieren. Beispiel:

playhrt: Step size is 999453 nsec.
playhrt: Setting input chunk size to 1536 bytes.
playhrt: Input buffer size is 68800 bytes.
playhrt: Accessing card in non-block mode.
playhrt: Min and max buffer size of device 48 .. 131072 - using 8064.
playhrt: Using mmap access.
playhrt: Start time (14199 sec 567084133 nsec)
playhrt: bad read, 512 bytes missing at 14199.570082492
playhrt: bad read, 512 bytes missing at 14199.573080851
playhrt: bad read, 512 bytes missing at 14199.576079210
playhrt: bad read, 512 bytes missing at 14199.579077569
playhrt: had 4 bad reads . . . exiting
playhrt: Loops: 12 (12 delayed), total bytes: 15360 in 15360 out.
playhrt: Bad loops/frames written: 0/0, bad reads/bytes: 4/2048
Terminated

oder auch

playhrt: Step size is 999966 nsec.
playhrt: Setting input chunk size to 1536 bytes.
playhrt: Input buffer size is 68800 bytes.
playhrt: Accessing card in non-block mode.
playhrt: Min and max buffer size of device 48 .. 131072 - using 8064.
playhrt: Using mmap access.
playhrt: Start time (14031 sec 825465930 nsec)
playhrt: Loops: 49 (49 delayed), total bytes: 72384 in 72384 out.
playhrt: Bad loops/frames written: 0/0, bad reads/bytes: 0/0
Terminated

je nach Einstellung des Werts für EXTRABYTESPLAY. Der steht zunächst auf 0, ich habe hier aber keine Idee, was ich einstellen soll. Für 44100 kHz und 96000 kHz hatten sich bei play_simple und play_volrace ganz verschiedene Werte ergeben, ca. 830 bzw. ca 60. Für Hinweise wäre ich dankbar.

Übrigens scheinen zwei Versionen von play_upsample_convolve zu existieren: die im Source-Code-Paket frankl_stereo-0.7 verwendet nicht shared memory, im Gegensatz zu der Variante, die unter http://frank_l.bitbucket.org/stereoutil ... html#pconv beschrieben ist. Das obige Problem tritt mit beiden Versionen auf, was gegen einen Fehler bei der Verwendung von shared memory spricht. (In frankl_stereo-0.7-bin-i686.tar sind gar keine Skripte enthalten.)

Inzwischen habe ich auch erste Hörvergleiche mit dem Raspberry/HiFiBerry via Coax-Kabel anstellen können. Mir scheint das Klangbild mit Franks play_writecatloop transparenter, luftiger zu sein. Allerdings kommt auch ein anderer Eingang des Verstärkers zum Einsatz (USB), insofern ist der Vergleich nicht ganz fair. Hier konnte ich zwischen verschiedenen Quellen umschalten. Franks play_writecatloop mit MPD vom selben Rechner zu vergleichen ist schwieriger, dazu muss ich meine Ohren noch besser trainieren. Zudem gibt es Franks Programme ja auch noch für den Raspberry Pi...

Noch eine ganz andere Frage: wie lassen sich .dff Dateien handhaben? Mit MPD-basierten Programmen lassen die sich abspielen. Es wäre schön, wenn das auch hier ginge.

Beste Grüße,

-- Jürgen

[frankl]

Nach weiteren Experimenten hat sich die oben beschriebenen Lösung nur als die zweitbeste herausgestellt. Natürlich sollte man sox dazu auffordern, Daten im 32Bit-Format bereitzustellen, anstatt an der Sample-Rate herumzuspielen. Dann klappt es auch bei 24Bit 96kHz Material usw.

sox mymusic.flac -t raw -b 32 - | aplay -t raw -f S32_LE -c 2 -r 44100 -D hw:0,0

Hallo Jürgen,

sorry, ich hatte in den letzten zwei Wochen nicht viel Zeit, um hier etwas zu schreiben. Ich hatte beim Überfliegen des vorhergehenden Beitrages gedacht, dass Deine Frage zu S32_LE beantwortet sei. Da habe ich aber wohl nicht sehr genau hingeschaut, denn dieses ist NICHT die RICHTIGE Lösung gewesen:

sox mymusic.flac -t raw -r 88200 - | aplay -t raw -f S32_LE -c 2 -r 44100 -D hw:0,0

Dabei wird von sox auf 88200 mit 16 Bit Samples hochgesampled und aplay liest dann immer zwei Samples, für linken und rechten Kanal, als ein 32 Bit Sample. Das sollte dann ungefähr wie das Mono-Abspielen des linken Kanales klingen, weil der rechte Kanal als Rauschen in den unteren 16 Bit verschwindet.

So, wie Du es oben angegeben hast, ist es richtig.

Dann ein paar Fragen:

0. Was bedeuten Ausgaben der Form

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?

Das playhrt durchläuft Schleifen, in denen jeweils Daten von der Quelle gelesen und an eine passende Stelle für den Audiotreiber kopiert werden und danach ein 'sleep' bis zum Beginn der nächsten Schleife aufgerufen wird. Ab und zu kann es sein (zum Beispiel durch einen Interrupt des Betriebssystems), dass die Schleife etwas zu lange gebraucht hat und die Aufwachzeit des sleep Aufrufes bereits vorbei ist. Dies sind die "delayed loops", die gezählt werden. Wenn Du nur 6 davon bei insgesamt 236230 Schleifendurchläufen hast, dann würde ich sagen, dass das gar kein Problem ist (und auch 200 statt 6 wären noch in Ordnung).

1. Viele Musikstücke enden mit Ausgaben der Form

playhrt: number of delayed loops: 6 (68768 sec 64296977 nsec)
playhrt: average available buffer: 8009 (68768 sec 78263993 nsec)
playhrt: bad read, 8 bytes missing at 68770.814801485
playhrt: bad read, 352 bytes missing at 68770.815799129
playhrt: Loops: 236230 (6 delayed), total bytes: 83152608 in 83152608 out.
playhrt: Bad loops/frames written: 0/0, bad reads/bytes: 2/360

Was hat es mit den 'bad reads'' auf sich? Die scheinen ganz am Ende aufzutreten. Die "input chunk size" dürfte bei 360 gelegen haben, was gerade 8+352 ist. Vermutlich ist das unerheblich.

Genau, zum Schluss werden ja Rest-Bytes in einem zu kleinen "input chunk" geschickt, weswegen ein oder zwei "bad reads" zu erwarten sind. Die Ausgabe oben sagt also, dass alles in Ordnung war.

2. Die "bad reads" machen es mir bisher leider auch unmöglich, play_upsample_convolve auszuprobieren. Beispiel:

playhrt: Step size is 999453 nsec.
playhrt: Setting input chunk size to 1536 bytes.
playhrt: Input buffer size is 68800 bytes.
playhrt: Accessing card in non-block mode.
playhrt: Min and max buffer size of device 48 .. 131072 - using 8064.
playhrt: Using mmap access.
playhrt: Start time (14199 sec 567084133 nsec)
playhrt: bad read, 512 bytes missing at 14199.570082492
playhrt: bad read, 512 bytes missing at 14199.573080851
playhrt: bad read, 512 bytes missing at 14199.576079210
playhrt: bad read, 512 bytes missing at 14199.579077569
playhrt: had 4 bad reads . . . exiting
playhrt: Loops: 12 (12 delayed), total bytes: 15360 in 15360 out.
playhrt: Bad loops/frames written: 0/0, bad reads/bytes: 4/2048
Terminated

Hier habe ich aus den Angaben keine Idee, was zu diesem Verhalten führt. Wenn Du mir per PN Dein play_upsample_convolve und die verwendete brutefir Konfiguration (und evtl. den gesamten Output beim Aufruf des Skriptes) schickst, kann ich mir das mal genauer ansehen.

je nach Einstellung des Werts für EXTRABYTESPLAY. Der steht zunächst auf 0, ich habe hier aber keine Idee, was ich einstellen soll. Für 44100 kHz und 96000 kHz hatten sich bei play_simple und play_volrace ganz verschiedene Werte ergeben, ca. 830 bzw. ca 60. Für Hinweise wäre ich dankbar.

Auf verschiedenen Notebooks habe ich auch gesehen, dass bei 44100 Hz ein sehr großer Wert für
EXTRABYTESPLAY benötigt wird, da wird also mit ungefähr 44300 Hz abgespielt. Auf meinem aktuellen Notebook kann ich bei 192000 Hz dagegen EXTRABYTESPLAY=0 benutzen.

Übrigens scheinen zwei Versionen von play_upsample_convolve zu existieren: die im Source-Code-Paket

Ja, sorry falls das Konfusion erzeugt hat. Bei Erstellen der Webseite hatte ich Fehler im Skript korrigiert, aber dann vergessen, die Korrektur auf das Skript im Archiv zu übertragen. (Das habe ich im Repository nachgeholt, aber ich wollte wegen dieser Kleinigkeit keine neue Version mit neuen Archiven erzeugen.

Noch eine ganz andere Frage: wie lassen sich .dff Dateien handhaben? Mit MPD-basierten Programmen lassen die sich abspielen. Es wäre schön, wenn das auch hier ginge.

Ich habe keine .dff Dateien. Einige Programme (evtl auch mpd) können die direkt mit "DSD via PCM" auf geeigneten DACs abspielen. Wenn man einen Convolver nutzen will, muss man zuerst das Signal in PCM verwandeln, such mal nach "dsd2pcm" in Web (oder versuche herauszubekommen, wie mpd das macht). Die Ausgabe kann man dann mit sox weiterverarbeiten.

Viele Grüße,

Frank

[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

[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

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

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

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

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

[Daihedz]

Hallo Nils

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

[FoLLgoTT]

Hallo Simon,

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

[frankl]

Hallo Nils

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

[FoLLgoTT]

Hallo Frank,

(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

[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

[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

[frankl]

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