Software-Experimente mit Linux

Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Hallo Frank & al.

heute habe ich mir auch die tools vorgeknöpft. Lokal auf dem rpi2 abgespielt geht es problemlos mit play_simple (Pfade angepasst sowie auf S32_LE konfiguriert für DAC).

Remote mag aber nicht (brutefir-Zeilen auskommentiert). Beim ersten Versuch kam was am rpi2 an, war aber mehr atmosphärische Störung mit leichten Musikanteil. ;)

Der zweite Versuch (zur Kontrolle Ausgabe von $ORIGRATE eingebaut) ging dann gar nicht mehr:

Code: Alles auswählen

sh play_remote.sh <Dateiname>.flac
44100
trap: SIGINT: bad trap
writeloop: Cannot open semaphore.bufhrt: Writing 1536000 bytes per second to port 5570.
bufhrt: Input from shared memory, output in 2000 loops per second.
bufhrt: Choosing 768 as length of input chunks.
Danach hängt das Script, ohne dass was ankommt beim rpi2.

Für sachdienliche Hinweise Dank im voraus. Falls das schon Thema war, bitte einen link.

Gruß

Jochen
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Nachtrag: Beim rpi2 sehe ich

Code: Alles auswählen

playhrt: Step size is 999482 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 7680.
playhrt: Using mmap access.
playhrt: Start time (16776 sec 238166430 nsec)
playhrt: bad read, 1536 bytes missing at 16776.239165912
playhrt: Loops: 1 (1 delayed), total bytes: 0 in 0 out.
playhrt: Bad loops/frames written: 0/0,  bad reads/bytes: 1/1536
Ich kann leider nicht sagen, ob das vom ersten oder einem späteren Versuch stammt.
Bild
Sire
Aktiver Hörer
Beiträge: 309
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Hallo Jochen,

eventl. hast Du einiges zuviel im play_remote-Script gekürzt. Das ist mir auch schon passiert. Ich erlaube mir mal, Frank zu zitieren:
Wenn Du play_remote minimal ändern willst ohne brutefir zu nutzen, musst Du
die Zeile mit dem brutefir Aufruf (z.B.) durch einen Aufruf von sox
ersetzen, der das Sampleformat von 64 bit floating point wieder auf
16 bit Integers kürzt, am bestem mit "Dithering". Zum Beispiel

ersetze
brutefir ${BRUTEFIRCONFIG} -quiet | \
durch
sox -t raw -c 2 -e float -b 64 -r 44100 - -t raw -e signed -b 16 - dither -s -f high-shibata | \
Vielleicht löst sich so schon das Problem.

Viele Grüße

Klaus
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Hallo Klaus,

danke für den Hinweis, dann bekomme ich:

Code: Alles auswählen

bufhrt: Writing 1536000 bytes per second to port 5570.
bufhrt: Input from shared memory, output in 2000 loops per second.
bufhrt: Choosing 768 as length of input chunks.
bufhrt (from shared): Write error: Connection reset by peer
Beendet
Und der Client meint dazu;

Code: Alles auswählen

playhrt: Step size is 1000000 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 7680.
playhrt: Using mmap access.
playhrt: Start time (27853 sec 735055474 nsec)
playhrt: bad read, 512 bytes missing at 27854.31055474
playhrt: bad read, 767 bytes missing at 27854.32055474
playhrt: bad read, 767 bytes missing at 27854.39055474
playhrt: bad read, 767 bytes missing at 27854.40055474
playhrt: had 4 bad reads . . . exiting
playhrt: Loops: 305 (9 delayed), total bytes: 464898 in 464898 out.
playhrt: Bad loops/frames written: 0/0,  bad reads/bytes: 4/2813
Edit: Ich muss auf 32, nicht 16 bit, sonst mag der DAC nicht.
Damit spielt der rpi immerhin einige Sekunden an, steigt dann aber wieder aus:

Code: Alles auswählen

playhrt: Step size is 1000000 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 7680.
playhrt: Using mmap access.
playhrt: Start time (28306 sec 987407366 nsec)
playhrt: average available buffer: 3339 (28311 sec 97407366 nsec)
playhrt: average available buffer: 3367 (28315 sec 193407366 nsec)
playhrt: average available buffer: 3215 (28319 sec 289407366 nsec)
playhrt: bad read, 512 bytes missing at 28322.983407366 
playhrt: bad read, 767 bytes missing at 28322.984407366 
playhrt: bad read, 763 bytes missing at 28322.987407366 
playhrt: bad read, 1534 bytes missing at 28322.989407366 
playhrt: had 4 bad reads . . . exiting
playhrt: Loops: 16002 (6 delayed), total bytes: 24575494 in 24575494 out. 
playhrt: Bad loops/frames written: 0/0,  bad reads/bytes: 4/3576
Gruß

Jochen
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Hallo Klaus,

nochmal danke für den Hinweis. Nach der bit-Anpassung will er jetzt doch. Vielleicht war der "Server" vorhin einfach nur in Sachen Netzwerk-Handhabung überlastet, weil er noch einen Download zu verkraften hatte.

Nun gilt es, ein wenig mehr zu hören. Denn im tiefsten Inneren fragt sich meine schwarze HiFi-Seele, ob nicht das dauernde Hin und Her bei den Sampleraten etwaige Vorteile der Tools wieder zunichte macht.

Gruß

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

Beitrag von frankl »

Melomane hat geschrieben: nochmal danke für den Hinweis. Nach der bit-Anpassung will er jetzt doch. Vielleicht war der "Server" vorhin einfach nur in Sachen Netzwerk-Handhabung überlastet, weil er noch einen Download zu verkraften hatte.
Hallo Jochen,

freut mich, dass es jetzt erstmal funktioniert. Wenn einer der beteiligten Rechner noch viel weiteren
Netzwerkverkehr hat, könnten die Beispielskripte in der Tat Probleme machen, da hier keine großen Puffer benutzt werden.
Melomane hat geschrieben: Nun gilt es, ein wenig mehr zu hören. Denn im tiefsten Inneren fragt sich meine schwarze HiFi-Seele, ob nicht das dauernde Hin und Her bei den Sampleraten etwaige Vorteile der Tools wieder zunichte macht.
Ich habe im Laufe der Zeit verschiedene Varianten ausprobiert. Der Hauptgrund, warum ich bei mir auf
192k resample, sind meine Korrekturfilter. Die Filter für hohe Sampleraten zu berechnen und anzuwenden ergibt bei mir ein noch glatteres/natürlicheres Klangbild im Vergleich zu kleineren Sampleraten.

Ein anderer Grund für das Resamplen könnte sein, dass ein DAC bei einer Rate besonders gut arbeitet, oder das externe Resampling eine bessere Qualität hat, als ein internes Resampling im DAC.

Aber wie immer bei solchen Fragen: es gibt keine allgemein gültige Antwort und man muss es im eigenen Setup ausprobieren.

Viele Grüße,
Frank
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Hallo Frank,
frankl hat geschrieben:Die Filter für hohe Sampleraten zu berechnen und anzuwenden ergibt bei mir ein noch glatteres/natürlicheres Klangbild im Vergleich zu kleineren Sampleraten.
Ja, das ist ein Eindruck, den ich bei früheren Versuchen mit Upsampling des Öfteren auch gewonnen habe.

Und ansonsten stimme ich dir voll und ganz zu, was die Wirkung im eigenen Setup angeht. In diesem - meinem - Fall ist der Eindruck zwiespältig. Bei lokaler Anwendung (play_simple) hatte ich den Eindruck, dass playhrt im Vergleich zu mpd ein wenig transparenter, aber auch aggessiver zu Werke geht. Das fiel unangenehm bei DGG-Produktionen aus der Zeit vor der Jahrtausendwende auf. Die können ja teils nerven...

Die fast volle Dröhnung ;) mit play_remote schien dann wieder relativ nah am Niveau von mpd zu spielen. Womit letztlich wenig gewonnen war. Aber belastbar sind diese Eindrücke in keiner Weise. Dazu sind die Unterschiede zu gering. Interessant wäre nun die Einbindung von brutefir, aber dazu fehlen mir (noch) die Filter.

Jedenfalls habe ich den Eindruck, dass die Klangunterschiede zwischen mpd und jriver deutlicher ausfallen als die zwischen mpd und playhrt.

Das alles soll in keiner Weise deine Arbeit und Mühe schmälern, sondern nur nachdrücklich bestätigen, dass es wie immer darauf ankommt, in welcher Umgebung Programme eingesetzt werden.

Gruß

Jochen
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Nachschlag:

Es läuft gerade Gergievs Einspielung von Brahms deutschem Requiem mit dem LSO in HiRes (96/24).

Mit mpd klingt das ziemlich intransparent-muffig bei mir. Mit playhrt ist die Produktion deutlich besser anzuhören, weil eben transparenter. Aber es gibt auch offenbar eine Betonung eines höheren Frequenzbereichs, in dem sich die Violinen tummeln, die dann tendenziell anfangen zu "sägen".

Und nun? Haben wir eben zwei Wiedergabemöglichkeiten, die je nach Musikmaterial und Laune hervor gekramt werden können. Also wird definitiv kein rm -rf frankl* stattfinden. ;)

BTW: Welche Einführung in die Berechnung von Filtern empfehlt ihr alten Hasen einem diesbezüglichen DAU. Man rechne mit dem schlimmsten Unverständnis. ;)

Gruß

Jochen
Bild
Sire
Aktiver Hörer
Beiträge: 309
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Hallo Jochen,

weiter vorne in diesem Thread gibt Frank noch einen Hinweis, wie brutefir genutzt werden kann, ohne dass bereits eigene Filter vorhanden sind. http://www.aktives-hoeren.de/viewtopic. ... 065#p98065 in diesem Post findest Du auch einen Link zu Franks LoCo-Filtern, die ich sehr interessant finde.
btw.: In dem von mir oben geposteten Scriptschnipsel wird wieder auf 16/44.1 heruntergesamplet. Hast Du das entsprechend für Deine Konfiguration angepasst? Leider kann ich im Moment nicht so viel hier schreiben.

Ich bin kein alter Hase, was die Erstellung von Filtern betrifft (eher das Gegenteil). Einfache Ergebnisse gibt es für den Anfang mit Alan Jordans drc-Designer auf die Schnelle. http://www.alanjordan.org/DRCDesigner/HelpFrameset.html Ansonten hoffe ich auch, hier noch einiges von den alten Hasen zu erfahren...

Liebe Grüße

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

Beitrag von koslowj »

Hallo,

Inzwischen habe ich Franks Skripte und die übrigen benötigten Programme auf dem Voyage-Rechner installiert; es handelt sich um ein PCEngines APU embedded board mit einem AMD G series T40E APU, 1 GHz dual core (Bobcat core).

Leider gibt es schon bei den ersten Beispielen auf Franks Seite Probleme mit aplay: bei

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

erhalte ich folgende Ausgabe:

Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
aplay: set_params:1233: Sample format non available
Available formats:
- S32_LE

Ersetzt man "S16_LE" durch "S32_LE", spielt die Musik mit doppelter Geschwindigkeit!

Die Flac-Datei liegt momentan auf einem mit vfat formatierten USB-Stick. Sie sollte in Ordnung sein, denn sie läßt sich mit MPD abspielen, und soxi liefert

Input File : 'mymusic.flac'
Channels : 2
Sample Rate : 44100
Precision : 16-bit
Duration : 00:05:45.96 = 15256836 samples = 25947 CDDA sectors
File Size : 40.4M
Bit Rate : 934k
Sample Encoding: 16-bit FLAC

Allerdings sagt die Hilfe für aplay am Schluß

Recognized sample formats are: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE IEC958_SUBFRAME_LE IEC958_SUBFRAME_BE MU_LAW A_LAW IMA_ADPCM MPEG GSM SPECIAL S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE G723_24 G723_24_1B G723_40 G723_40_1B DSD_U8 DSD_U16_LE
Some of these may not be available on selected hardware
...

Speziell diese letzte Zeile finde ich beunruhigend. Im Netz habe ich bisher noch keine Lösung gefunden.
Vielleicht hat jemand eine Idee?

-- Jürgen
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

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
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von 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.
Bild
koslowj
Aktiver Hörer
Beiträge: 54
Registriert: 24.06.2015, 00:26

Beitrag von 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
Melomane hat geschrieben: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
Bild
koslowj
Aktiver Hörer
Beiträge: 54
Registriert: 24.06.2015, 00:26

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

Beitrag von frankl »

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
Bild
Antworten