koslowj hat geschrieben:
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.
koslowj hat geschrieben:
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).
koslowj hat geschrieben:
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.
koslowj hat geschrieben:
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.
koslowj hat geschrieben:
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.
koslowj hat geschrieben:
Ü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.
koslowj hat geschrieben:
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