Hallo,
unter
http://www.digitalaudioreview.net.au/in ... lass-a-psu
wurde das "digitale Interface" von audio-gd getestet. Der Bericht ist gut geschrieben, der Verweis auf den audiophileo 2 eröffnet zusätzliche Infos unter
http://www.audiophilleo.com/audiophilleo2.aspx
Was steckt eigentlich hinter dieser Technik?
Nicht mehr und nicht weniger als der kleine Disput über das "PC-Geraffel".
Die Abkehr von klassischen Einzelbausteinen auf der Platine hin zu FPGAs (meist von Xilinx oder Altera), deren Leistungsfähigkeit zwar noch unterhalb des PC liegt, dafür aber nicht mit unnötigen Prozessen
des Betriebssystems belastet werden.
Wenn es gut und kundenfreundlich gemacht ist, läßt sich - wie bei Linn - die Software über das Netz auch updaten, was zu durchaus respektablen Verbesserungen führen kann.
Gruß
Bernd Peter
Digitales Interface von audio-gd
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4002
- Registriert: 04.05.2010, 19:37
Hallo Bernd Peter,
Es ist müßig die Upsamplingdiskussion nochmals loszutreten und das möchte ich auch nicht. Ich glaube das geht technisch einfach den meisten zu weit.
Das Linn und auch audio-gd mit dem FPGA das Problem zu lösen versucht ist doch schon sehr gut, aber für die optimale sinc-Interpolation gibt einfach nur den echten Computer.
Uli Brüggemann´s Statement :
Nun, Uli betont auch dass solche sinc-Filter in Praxis zu lang sind um in Audioanwendungen wirklich brauchbar zu sein, aber da hat er nicht einbezogen dass der cPlay´er diese ungeheure mathematische Kalkulation im L2 Cache des Intel Prozessors bewerkstelligt (deshalb ist das cPlay Programm auch in verschiedene Instruktionssätzen des CPUs gegliedert : SSE2, SSSE3, SSSE4.1).
Im L2 Cache können diese Berechnungen in Echtzeit durchgeführt werden, weil nur in diesem Cache Memory die Geschwindigkeit hoch genug ist.
Das sinc-Filter von cPlay ist gezielt in den Prozessor integriert.
-genau dafür gibt es ja zum cPlay´er das cMP 
Gruß aus Helsinki
Es ist müßig die Upsamplingdiskussion nochmals loszutreten und das möchte ich auch nicht. Ich glaube das geht technisch einfach den meisten zu weit.
Das Linn und auch audio-gd mit dem FPGA das Problem zu lösen versucht ist doch schon sehr gut, aber für die optimale sinc-Interpolation gibt einfach nur den echten Computer.
Uli Brüggemann´s Statement :
Nun bewirkt aber das Upsampling bzw. eine Interpolation der Zwischenpunkte selbst eine Erzeugung von Spiegelfrequenzen = Aliasing. Demzufolge muss bereits vor dem DA-Wandler, also im digitalen Bereich noch ein Tiefpassfilter angewandt werden, welches alles über 22050 Hz total sperrt. Gemäss Mathematik gibt es nur ein einziges Filter welches eine perfekte Rekonstruktion macht, das sinc-Filter. Alle anderen Interpolationen (Treppe, linear, Polynom 2. oder 3. Grades, Spline ....) sind nur Annäherungsverfahren. Nichts Perfektes. Es gäbe also hinsichtlich sinc keine Diskussion, wenn das sinc-Filter nicht auch eine unangenehme Eigenschaft hätte: es ist unendlich lang. In der Realität, speziell unter Echtzeitgesichtspunkten, ist es so nicht praktikabel.
Trotzdem wichtig !!! Obwohl das ideale sinc auch einen unendlich langen Vorschwinger hat, würde damit der Signalverlauf unserer vorliegenden Daten gemäß 1. perfekt rekonstruiert. Man könnte also aus den gefilterten Daten (unendlich lang) genau den Abschnitt herausschneiden, wie er unter 1. gegeben war. DABEI GIBT ES KEINERLEI VORSCHWINGER UND NACHSCHWINGER IM SIGNAL SELBST !!
Nun müssen wir aber auf den Boden der Tatsachen zurückkommen, also die Realität. Wir benötigen eine brauchbare Filterlänge. De facto verwenden also alle angewandten sinc-Filter endliche Längen. Längen von 31 Stützpunkten bis 1024 Stützpunkten oder auch noch viel mehr. Es kann sein, dass ein kurzes sinc-Filter damit mehr Fehler produziert als eine Spline-Interpolation. Es muss aber klar sein, dass ein sinc-Filter alle sonst üblichen Interpolationen übertrifft, wenn man es nur lang genug macht.
Nun, Uli betont auch dass solche sinc-Filter in Praxis zu lang sind um in Audioanwendungen wirklich brauchbar zu sein, aber da hat er nicht einbezogen dass der cPlay´er diese ungeheure mathematische Kalkulation im L2 Cache des Intel Prozessors bewerkstelligt (deshalb ist das cPlay Programm auch in verschiedene Instruktionssätzen des CPUs gegliedert : SSE2, SSSE3, SSSE4.1).
Im L2 Cache können diese Berechnungen in Echtzeit durchgeführt werden, weil nur in diesem Cache Memory die Geschwindigkeit hoch genug ist.
Das sinc-Filter von cPlay ist gezielt in den Prozessor integriert.
Code: Alles auswählen
....dafür aber nicht mit unnötigen Prozessen
des Betriebssystems belastet werden.Gruß aus Helsinki
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4002
- Registriert: 04.05.2010, 19:37
Hallo Ihr beiden,
warum so nervös, wenn über Technik gesprochen wird?
Die vor kurzem geführte Diskussion über einen Softwareplayer und Audio-PCs kam allein dadurch zustande, daß Aussagen getroffen wurden, die einer sachlich-technischen Begründung nicht Stand hielten.
Ob jemand nun über PC oder Streamer am liebsten hört, ist eine persönliche Entscheidung bzw. abhängig vom Geldbeutel.
Klangliche Vergleiche soll der ziehen, der beide Quellgeräte besitzt, und auch dann ist das immer noch ein bißchen Geschmackssache und im wesentlichen abhängig vom verwendeten DAC.
Ein Zodiac über USB wird wohl bessere Ergebnisse liefern als ein Face von RME, oder?
Gruß
Bernd Peter
warum so nervös, wenn über Technik gesprochen wird?
Die vor kurzem geführte Diskussion über einen Softwareplayer und Audio-PCs kam allein dadurch zustande, daß Aussagen getroffen wurden, die einer sachlich-technischen Begründung nicht Stand hielten.
Ob jemand nun über PC oder Streamer am liebsten hört, ist eine persönliche Entscheidung bzw. abhängig vom Geldbeutel.
Klangliche Vergleiche soll der ziehen, der beide Quellgeräte besitzt, und auch dann ist das immer noch ein bißchen Geschmackssache und im wesentlichen abhängig vom verwendeten DAC.
Ein Zodiac über USB wird wohl bessere Ergebnisse liefern als ein Face von RME, oder?
Gruß
Bernd Peter
Hallo Bernd Peter,
weder beim Threadtitel noch beim Lesen der bisherigen Beiträge ist mir bislang klar geworden, um was es in diesem Thread gehen soll. Hilfreich wäre, wenn Du die inhaltliche Richtung und die Intention deutlicher klarstellst. Denn über Vor- und Nachteile von Streaming- vs. PC-Lösungen gibt es ja bereits entsprechende Threads.
Grüße
Fujak
weder beim Threadtitel noch beim Lesen der bisherigen Beiträge ist mir bislang klar geworden, um was es in diesem Thread gehen soll. Hilfreich wäre, wenn Du die inhaltliche Richtung und die Intention deutlicher klarstellst. Denn über Vor- und Nachteile von Streaming- vs. PC-Lösungen gibt es ja bereits entsprechende Threads.
Grüße
Fujak
-
wgh52
- Aktiver Hörer
- Beiträge: 5650
- Registriert: 25.01.2008, 15:17
- Wohnort: Schweitenkirchen
- Kontaktdaten:
Leif,
es tut mir Leid, aber mir sträuben sich ob der Halbwahrheiten gerade die sämtliche Körperhaare (Ich war lange genug bei Intel um etwas behalten zu haben...
):
2. KEINE CPU rechnet im Cache!!! Sie rechnet in der ALU mit Daten aus dem Memory. Je nach Gebrauchshäufigkeit werden Entsprechende Daten in den verschienenen Cache Levels gehalten um die ALU mit Daten versorgt zu halten, so dass sie immer voll laufen kann und seltener auf Datennachschub "warten" muss.
3. Ein Cache erleichtert es dem Prozessor in Echtzeit zu rechnen, weil häufig benötigte Datensätze dort zum schnelleren Zugriff vorgehalten werden. Die hier angesprochenen CPUs haben 2-3 Cache Levels, L1 ist am schnellsten zugreifbar, L3 am langsamsten, aber immernoch schneller als Main-Memory zugriffe. Windows an sich steht aber wirklicher Echtzeitverarbeitung (das ist nunmal ein technisch genau definierter Begriff) übrigens komplett im Wege, darum muss man ja so viel "herausoperieren" um dieser in Windows nicht implementierten Betriebsart möglichst nahe zu kommen.
4. Sinc Filter sind in keinem Prozessor der Welt "integriert"!! Diese auf dem Chip als Maschinenbefehle fest zu verdrahten (und das heisst inder Halbleitertechnologie "integrieren"!) wäre technisch und wirtschaftlich kompletter Unsinn! Sinc Filter sind nichts "magisches", sondern ganz normale, auf Grundlage entsprechender Algorithmen erstellte Programm(teil)e wie alle anderen (und sei es Wordpad!) auch - eine Abfolge von Befehlen, in einer hohen Programmiersprache geschrieben, auf die Maschinensprache der CPU übersetzt (eventuell/wahrscheinlich mit Compileroptimierungen). Ich glaube übrigens nichtmal, dass sie auf Assembler-/Maschinen-ebene optimiert sind.
Das alles nur zur Richtig-/Klarstellung. Also nichts für ungut und Deinen cMP² Enthusiasmus in allen Ehren!
Gruss,
Winfried
1965
es tut mir Leid, aber mir sträuben sich ob der Halbwahrheiten gerade die sämtliche Körperhaare (Ich war lange genug bei Intel um etwas behalten zu haben...
): 1. Programme sind in die verschiedenen Instruktionssätze gegliedert, und jeweils für diese optimal programmiert, damit sie auch auf älteren CPUs laufen, die die neuesten Instruktionssätze noch nicht unterstützen!play-mate hat geschrieben:nicht einbezogen dass der cPlay´er diese ungeheure mathematische Kalkulation im L2 Cache des Intel Prozessors bewerkstelligt (deshalb ist das cPlay Programm auch in verschiedene Instruktionssätzen des CPUs gegliedert : SSE2, SSSE3, SSSE4.1).
Im L2 Cache können diese Berechnungen in Echtzeit durchgeführt werden, weil nur in diesem Cache Memory die Geschwindigkeit hoch genug ist.
Das sinc-Filter von cPlay ist gezielt in den Prozessor integriert.
2. KEINE CPU rechnet im Cache!!! Sie rechnet in der ALU mit Daten aus dem Memory. Je nach Gebrauchshäufigkeit werden Entsprechende Daten in den verschienenen Cache Levels gehalten um die ALU mit Daten versorgt zu halten, so dass sie immer voll laufen kann und seltener auf Datennachschub "warten" muss.
3. Ein Cache erleichtert es dem Prozessor in Echtzeit zu rechnen, weil häufig benötigte Datensätze dort zum schnelleren Zugriff vorgehalten werden. Die hier angesprochenen CPUs haben 2-3 Cache Levels, L1 ist am schnellsten zugreifbar, L3 am langsamsten, aber immernoch schneller als Main-Memory zugriffe. Windows an sich steht aber wirklicher Echtzeitverarbeitung (das ist nunmal ein technisch genau definierter Begriff) übrigens komplett im Wege, darum muss man ja so viel "herausoperieren" um dieser in Windows nicht implementierten Betriebsart möglichst nahe zu kommen.
4. Sinc Filter sind in keinem Prozessor der Welt "integriert"!! Diese auf dem Chip als Maschinenbefehle fest zu verdrahten (und das heisst inder Halbleitertechnologie "integrieren"!) wäre technisch und wirtschaftlich kompletter Unsinn! Sinc Filter sind nichts "magisches", sondern ganz normale, auf Grundlage entsprechender Algorithmen erstellte Programm(teil)e wie alle anderen (und sei es Wordpad!) auch - eine Abfolge von Befehlen, in einer hohen Programmiersprache geschrieben, auf die Maschinensprache der CPU übersetzt (eventuell/wahrscheinlich mit Compileroptimierungen). Ich glaube übrigens nichtmal, dass sie auf Assembler-/Maschinen-ebene optimiert sind.
Das alles nur zur Richtig-/Klarstellung. Also nichts für ungut und Deinen cMP² Enthusiasmus in allen Ehren!
Gruss,
Winfried
1965
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4002
- Registriert: 04.05.2010, 19:37
Hallo Fujak,
zum ersten ging es mir natürlich um die Verwendbarkeit und die Qualität des digitalen Interfaces von audio-gd.
Nebenbei, der zentrale Baustein des digitalen Interfaces von audio-gd ist ein FPGA.
Das ist eine schöne Überleitung zum hier stattfindenden Wettbewerb Audio-PC oder Streamer.
Da haben wir PC-Prozessor mit Peripherie und auf der anderen Seite die DSPs.
Hier das Universelle mit seinen gleichzeitigen Vor- und Nachteilen, da das auf die gewünschten Funktionen zugeschnittene Teil mit dafür eingeschränkter Rechenpower (was aber niemand daran hindert, mehrere DSPs zu verwenden).
Was klanglich dabei rauskommt, ist und bleibt offen.
Gruß
Bernd Peter
zum ersten ging es mir natürlich um die Verwendbarkeit und die Qualität des digitalen Interfaces von audio-gd.
Nebenbei, der zentrale Baustein des digitalen Interfaces von audio-gd ist ein FPGA.
Das ist eine schöne Überleitung zum hier stattfindenden Wettbewerb Audio-PC oder Streamer.
Da haben wir PC-Prozessor mit Peripherie und auf der anderen Seite die DSPs.
Hier das Universelle mit seinen gleichzeitigen Vor- und Nachteilen, da das auf die gewünschten Funktionen zugeschnittene Teil mit dafür eingeschränkter Rechenpower (was aber niemand daran hindert, mehrere DSPs zu verwenden).
Was klanglich dabei rauskommt, ist und bleibt offen.
Gruß
Bernd Peter
Hallo Bernd Peter,Bernd Peter hat geschrieben:Hallo Ihr beiden,
warum so nervös, wenn über Technik gesprochen wird?
von Nervosität kann überhaupt keine Rede sein, warum kommt nur immer wieder das gleiche Totschlagargument...
Generell bin ich der Meinung, daß man gehört haben sollte, worüber man spricht oder um es mit Peters Worten auszudrücken:
Vertraut euren Ohren und nicht der Anzahl der Lötpunkte!
Entspannte Grüße,
Stefan
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4002
- Registriert: 04.05.2010, 19:37
Hallo Winfried,
Zu deinen Anmerkungen und zur Beruhigung deiner Körperhaare :
Gruß Leif
Zu deinen Anmerkungen und zur Beruhigung deiner Körperhaare :
-cPlay ist genau für bestimmte Instruktionssätze bestimmt : Es gibt somit cPlay für SSE2 und einen anderen cPlay für SSE3, SSSE4 usw.wgh52 hat geschrieben:1. Programme sind in die verschiedenen Instruktionssätze gegliedert, und jeweils für diese optimal programmiert, damit sie auch auf älteren CPUs laufen, die die neuesten Instruktionssätze noch nicht unterstützen!
Okay, cPlay rechnet dann die neuen Interpolationspunkte mithilfe der Cache. Da cPlay ein Memoryplayer ist, ist der RAM des Computers voll mit nativen Daten ( das "Address Windowing Extensions" (AWE)) sorgt zusätzlich dafür dass mehr RAM Speicher für Musikdaten zu Verfügung steht. Im RAM sind die Daten (noch) nicht hochgerechnet. Dies geht auch von den gestellten Diagnose Daten hervor. Der Cache Speicher ist der Ort wo das Upsampling errechnet wird. Ob der ALU dort mitwirkt ist doch egal.2. KEINE CPU rechnet im Cache!!! Sie rechnet in der ALU mit Daten aus dem Memory. Je nach Gebrauchshäufigkeit werden Entsprechende Daten in den verschienenen Cache Levels gehalten um die ALU mit Daten versorgt zu halten, so dass sie immer voll laufen kann und seltener auf Datennachschub "warten" muss
Stimmt. In einem normalen Computer ist dies der Fall, aber eben nicht in cMP. Dazu sind die vielen Optimimierungsschritte auch da. Unter anderem im cMP Programm selber, aber auch die geänderte boot.ini wird genau für Echtzeit gefriemelt. Der ganze Explorer in Windows istWindows an sich steht aber wirklicher Echtzeitverarbeitung (das ist nunmal ein technisch genau definierter Begriff) übrigens komplett im Wege, darum muss man ja so viel "herausoperieren" um dieser in Windows nicht implementierten Betriebsart möglichst nahe zu kommen.
Integriert ist vielleicht nicht das richtige Wort, aber das Processing mit Secret Rabbit Code findet nunmal im Cache statt. Ob nun mit ALU oder wie auch immer. Dazu auch mehr auf der Webseite von cMP, wenn du es so genau wissen willst.4. Sinc Filter sind in keinem Prozessor der Welt "integriert"!! Diese auf dem Chip als Maschinenbefehle fest zu verdrahten (und das heisst inder Halbleitertechnologie "integrieren"!) wäre technisch und wirtschaftlich kompletter Unsinn! Sinc Filter sind nichts "magisches", sondern ganz normale, auf Grundlage entsprechender Algorithmen erstellte Programm(teil)e wie alle anderen (und sei es Wordpad!) auch - eine Abfolge von Befehlen, in einer hohen Programmiersprache geschrieben, auf die Maschinensprache der CPU übersetzt (eventuell/wahrscheinlich mit Compileroptimierungen). Ich glaube übrigens nichtmal, dass sie auf Assembler-/Maschinen-ebene optimiert sind.
Gruß Leif