Verfasst: 13.08.2011, 23:31
Hey Uli,
I´m delighted about your intrigue into this....
-ja, in Deutsch kann man ja nicht "intrigant" sagen, ohne einen negativen Beigeschmack zu provozieren.
Ich jedoch verspüre eine gesunde Neugierde bei dir in Sachen Upsampling und sinc-Filter.
-eigentlich geht´s hier ja um Schnittstellen, aber ich bin voll dahinter dass man diese schwierige Schnittstellen-Problematik nicht ganz ohne Upsampling auseinanderhalten kann.
Ein 96/192 kHz Signal überträgt in Praxis grundsätzlich weniger Jitter als ein (originales) 44.1 kHz Signal .
-populär kann man sagen, dass die kürzeren Samples, und eingehend die schnelleren Dispatches im System, für strafferen Ablauf der Datenpakete sorgen. Mit weniger Jitter zur Folge.
-dies tut jedem D/A Wandler gut; speziell diejenigen die kein avanciertes & teueres Re-Clocking betreiben.
Was man von deinen grafischen Darstellungen halten soll sei dahingestellt, aber empirische Hör-Erfahrungen sprechen auch eine Sprache....
(eigentlich sollte ich nicht die Arbeitsweise von cPlay (SRC sinc-Filter) weiter ansprechen, aber ich muss doch einen gewissen Einspruch erheben. Der Secret Rabbit Code den du auf der Webseite von Eric di Lupo (Secret Rabbit Code) gefunden hast und in deine technischen Darstellungen einfließen lässt, ist zwar prinzipiell als Quelle offengelegt, aber entspricht nur Teilweise der Funktionsweise von cPlay.
Vorerst ist der sinc-SRC Code im cPlay´er integriert; -verhält sich dynamisch zum Ereignis der Daten und die Berechnungen davon werden fortlaufend im L3 Cache des Prozessors ausgeführt.
-und zwar "real-time" !
Dies kannst du nicht pauschal mit dem statischen Quellcode vergleichen.
Es ist auch ein ungemein großer Unterschied zu einem Plug-in Verfahren das z.B. SoX in Foobar verwendet. Vorerst weil das sinc-Filter in cPlay nicht nachher im DSP verarbeitet wird, aber direkt im Prozessor stattfindet. Daher auch die spezifische cPlay Version ob nun eine SSE2, SSE3 oder SSSE4 Prozessor das Upsampling ausführen soll.
.....cics (und andere ehrgeizige Audiophile) haben sich mit der Problematik fünf Jahre akribisch damit auseinandergesetzt. cPlay ist eben nicht eine 08/15 Software. Da ist schon ein gewisser Hirnschmalz eingeflossen.... just think about it twice).
Nun ja, ich bewundere deine mathematisch-technischen Einsichten und ich danke auch für so viele deiner wissenschaftlichen Korrekturen, aber wäre es nicht einmal Zeit zu hinterfragen, warum einige Prozeduren so viel überzeugender klingen ?
Upsampling ist eben nicht einfach die Taktrate zu erhöhen, und digitale Schnittstellen sind auch nicht nur den Zustand "Bit-Perfekt" zu garantieren.
Jitter - (sprich) "Zeit-Perfekt" ist das schwierige an der Sache. Da hat Upsampling ganz andere Vorzüge die man Offline nicht beweisen kann !
Gruß Leif
I´m delighted about your intrigue into this....
-ja, in Deutsch kann man ja nicht "intrigant" sagen, ohne einen negativen Beigeschmack zu provozieren.
Ich jedoch verspüre eine gesunde Neugierde bei dir in Sachen Upsampling und sinc-Filter.
-eigentlich geht´s hier ja um Schnittstellen, aber ich bin voll dahinter dass man diese schwierige Schnittstellen-Problematik nicht ganz ohne Upsampling auseinanderhalten kann.
Ein 96/192 kHz Signal überträgt in Praxis grundsätzlich weniger Jitter als ein (originales) 44.1 kHz Signal .
-populär kann man sagen, dass die kürzeren Samples, und eingehend die schnelleren Dispatches im System, für strafferen Ablauf der Datenpakete sorgen. Mit weniger Jitter zur Folge.
-dies tut jedem D/A Wandler gut; speziell diejenigen die kein avanciertes & teueres Re-Clocking betreiben.
Was man von deinen grafischen Darstellungen halten soll sei dahingestellt, aber empirische Hör-Erfahrungen sprechen auch eine Sprache....
(eigentlich sollte ich nicht die Arbeitsweise von cPlay (SRC sinc-Filter) weiter ansprechen, aber ich muss doch einen gewissen Einspruch erheben. Der Secret Rabbit Code den du auf der Webseite von Eric di Lupo (Secret Rabbit Code) gefunden hast und in deine technischen Darstellungen einfließen lässt, ist zwar prinzipiell als Quelle offengelegt, aber entspricht nur Teilweise der Funktionsweise von cPlay.
Vorerst ist der sinc-SRC Code im cPlay´er integriert; -verhält sich dynamisch zum Ereignis der Daten und die Berechnungen davon werden fortlaufend im L3 Cache des Prozessors ausgeführt.
-und zwar "real-time" !
Dies kannst du nicht pauschal mit dem statischen Quellcode vergleichen.
Es ist auch ein ungemein großer Unterschied zu einem Plug-in Verfahren das z.B. SoX in Foobar verwendet. Vorerst weil das sinc-Filter in cPlay nicht nachher im DSP verarbeitet wird, aber direkt im Prozessor stattfindet. Daher auch die spezifische cPlay Version ob nun eine SSE2, SSE3 oder SSSE4 Prozessor das Upsampling ausführen soll.
.....cics (und andere ehrgeizige Audiophile) haben sich mit der Problematik fünf Jahre akribisch damit auseinandergesetzt. cPlay ist eben nicht eine 08/15 Software. Da ist schon ein gewisser Hirnschmalz eingeflossen.... just think about it twice).
Nun ja, ich bewundere deine mathematisch-technischen Einsichten und ich danke auch für so viele deiner wissenschaftlichen Korrekturen, aber wäre es nicht einmal Zeit zu hinterfragen, warum einige Prozeduren so viel überzeugender klingen ?
Upsampling ist eben nicht einfach die Taktrate zu erhöhen, und digitale Schnittstellen sind auch nicht nur den Zustand "Bit-Perfekt" zu garantieren.
Jitter - (sprich) "Zeit-Perfekt" ist das schwierige an der Sache. Da hat Upsampling ganz andere Vorzüge die man Offline nicht beweisen kann !
Gruß Leif