Hallo Frank,
das mache ich gerne. An dich geht der Dank für die Tools selbst, eine tolle Spielwiese.
Die neue Version installiere ich in den nächsten Tagen.
Auch mit resample_soxr bleibt das messtechnisch schlechtere Verhalten bei Upsamlng auf gerade Vielfache. Für den Test wurden alle Signale mit float64 gerechnet und gespeichert. Als Konfiguration wurde sox mit "rate -v -b 93" und resample_soxr mit "-B 89 -P 50" gewählt, was in etwa vergleichbare Filter ergibt. Die Ergebnisse unterscheiden sich bei "precision=28" oder "precision=33" nicht.
Die unteren Bilder zeigen das Spektrum des Original-Dunn-Jitter-Test-Signals bei 44,1 kHz (blau), Upsapling auf 88,2 kHz (grün) und Upsampling auf 96 kHz (rot). Bei Upsampling auf 88,2 kHz sieht man sehr deutlich, dass periodische Störungen oberhalb von fs/2 auftreten, die aus dem Rauschteppich bei etwa -190 dB um etwa +20 dB herausragen. Bei Upsampling auf 96 kHz entsteht zwar ein um etwa 3 dB höherer Rauschteppich, aber es treten keine periodischen Störungen auf. Das zeigt auch der detaillierte Blick um das Nutzsignal herum. Bei 88,2 kHz Upsampling sind deutliche Spikes (= periodische Störungen) zwischen den Nutzsignal-Peaks zu sehen.
Jitter-Verhalten im Nutzsignalbereich, blau=Original@44,1 kHz, rot=96 kHz, grün=88,2 kHz
Jitter-Verhalten außerhalb des Nutzbereich (rechte Hälfte), blau=Original@44,1 kHz, rot=96 kHz, grün=88,2 kHz
Noch einmal kurz zur CPU-Last: Ich habe Messungen von einigen Konfigurationen über jeweils einen Zeitraum von mehreren Stunden gemacht. Für sox und resample_soxr habe ich wieder die oben genannten Einstellungen gewählt. Der Unterschied zwischen "precision=28" und "precision=33" ist bei mir auch nur marginal (2.1% zu 2.3%). Der Unterschied zwischen soxr und resample_soxr ist aber recht deutlich.
Pipe 1: kodi 44.1 k int32> sox int32 zu float64 > resample_soxr 44.1k float64 zu 96k float64 > ... Rechenzeit: sox 0.2%, resample_soxr 2.1%
Pipe 2: kodi 44.1k float32> sox 44.1k float32 zu 96k float64 > ... Rechenzeit: sox 5.3%
Seit zwei Wochen lasse ich die unterschiedlichen Anwendungen der Pipe auch auf unterschiedlichen Threads laufen. Der Datenlieferant kodi läuft auf Core 1, die letzte Stufe vor alsa (playhrt oder sox) läuft auf Core 3, alles dazwischen (sox, resample_soxr, brutefir) auf Core 2. Der Kernel darf aber (noch) Core0-4 benutzen. Das Isolieren von Cores über
isolcpus ist die nächste Baustelle, die mich interessiert.
Von playhrt als Teil meiner Default-Pipe habe ich erst einmal Abstand genommen, weil ich zum einen das Nachregeln der Clock irgendwie immer noch als zwar notwendigen aber wenig eleganten Ansatz empfinde. Zum anderen störe ich mich noch am Buffer-Management. playhrt füllt den Puffer immer mit der "echten" Datenrate und startet playback erst ab 50% gefülltem Puffer. Damit ergibt sich in meinem Fall etwa 80 ms Verzögerung, die mich bei Filmwiedergabe stört. Ich suche nach einer Lösung, die schnell die Wiedergabe (<=10 ms) startet und den Puffer schnell bis 50% Puffer füllt, um erst danach in den regulären Takt zu fallen. Damit bekomme ich kurzes Delay kombiniert mit hoher Betriebssicherheit. Mal schauen...
Viele Grüße,
Andree
