Klangunterschiede trotz Bit-Identität ("bit-perfect")

[Thias]

Einfach mal die Platine betrachten und die Beschreibung dazu lesen, dann müsste es klar sein, wie es vor sich geht.

... was willst du jetzt damit sagen?

Das ist doch kein DAC sondern ein USB-SPDIF/I2S-Wandler mit Taktratenconverter.
Als "Beweis" für den asynchronen USB-Betrieb ist der Taktgeber. Aber es fehlt der D/A-Wandler . I2S ist synchron. Das asynchrone USB-Signal wird in ein synchrones I2S-Signal gewandelt, welches ein anzuschließender DA-Wandler versteht, aber meines Wissens im Eingangsregister nochmals synchronisiert wird.
Ich würde es aber für umständlich halten damit wieder in ein anderes Gerät zu gehen. Hat diese Karte ein Masterclock, die auch den DA-Wandler bedient?
Dieser (oder ein ähnlicher ) Baustein ist in einem kompletten DAC für USB integriert.
Aber ich denke das ist alles OT.

Als Fazit können wir, denke ich, festhalten, dass bei asynchroner USB-Übertragung der PC Takt das Endergebnis nicht verjittern kann.

[Thias]

Um so erstaunlicher, wenn PCM-Daten über einen asynchronen Weg transportiert abhängig davon verschieden klingen sollen, mit welchem Programm sie gerippt wurden, wo sie auf der Platte liegen, welches Betriebssystem auf dem Rechner in welcher Optimierung läuft, welches Laufwerk zum Rippen verwendet wurde, ob der Rechner beim Rippen am SNT oder mit Akku betrieben wurde, ob die CD vor dem Rippen tiefgefroren war oder nicht, ob die CD-Ränder angefast oder angemalt oder unbehandelt sind... - wüßte nicht, wie ich ggf. solche Unterschiede, so sie denn da seien, über eine asynchrone Strecke bekäme...

Hallo Ulli, sehr schön zusammengefasst
Ergänzend... wenn bitidentische Daten über einem asynchronen Weg...

Aber wo kann man noch suchen ?

[uli.brueggemann]

Frage meinerseits an die Spezialisten:
wenn Speicherplätze als Puffer verwendet werden ist es - wohl noch einfach - logisch verständlich, dass man nicht zum selben Zeitpunkt lesend und schreibend auf einen bestimmten Speicherplatz zugreifen sollte.
Wenn aber unterschiedliche Speicherplätze für Lesen und Schreiben verwendet werden, ist es dann ok ?
Wie werden Konflikte auf den Adress- und Datenleitungen zum Speicher gehandhabt ? Die Leitungen können doch nicht GLEICHZEITIG von Sender und Empfänger belegt werden.

I²S bedeutet eine serielle Übertragung. Da kommen die Kanäle abwechselnd (gemultiplext) mit bis zu 32 bits je Kanal, das MSB zuerst. Die Kanäle kommen doch hoffentlich nicht zeitlich hintereinander versetzt als analoge Signale raus. Also ist im DAC-Chip noch irgendeine seriell/parallel-Wandlung nötig, oder?
Was wiederum ein Zwischenspeichern bedeutet.

Und immer, wenn ein Speicher im Spiel ist, treten wieder Zugriffskollisionen auf, selbst auf dem DAC-Chip. Irgendwer/was muss warten. Eine Lösung sehe ich da nur, wenn mit unabhängigen Adress- und Datenleitungen gearbeitet wird.

Grüsse
Uli

[Thias]

Allerdings wird mit dem anliegenden Word Clock gearbeitet - dessen Jitter kann also durchkommen

Beste Grüße
Ulli

... ich gehe mal davon aus, dass es sich um die gleiche Clock handelt, nur die Frequenzen werden unterschiedlich geteilt. Aber klar, in diesem Bereich kann sehr viel klangentscheidend sein.

[Bernd Peter]

Hallo Thias,

Das asynchrone USB-Signal wird in ein synchrones I2S-Signal gewandelt, welches ein anzuschließender DA-Wandler versteht

so stimmts:

Das USB-Signal wird (beim WaveIO) in ein I2S-Signal gewandelt, welches ein Wandler versteht

weil er nun alles (Clocks und Dateninfos) bekommt, um die D/A Wandlung durchzuführen.

Würde man beim WaveIO über S/PDIF gehen, müsste erst über einen Receiver synchronisiert und dann ein I2S Signal ausgegeben werden.

Gruß

Bernd Peter

[ESM]

Hallo Uli,

Frage meinerseits an die Spezialisten:
wenn Speicherplätze als Puffer verwendet werden ist es - wohl noch einfach - logisch verständlich, dass man nicht zum selben Zeitpunkt lesend und schreibend auf einen bestimmten Speicherplatz zugreifen sollte.
Wenn aber unterschiedliche Speicherplätze für Lesen und Schreiben verwendet werden, ist es dann ok ?
Wie werden Konflikte auf den Adress- und Datenleitungen zum Speicher gehandhabt ? Die Leitungen können doch nicht GLEICHZEITIG von Sender und Empfänger belegt werden.

I²S bedeutet eine serielle Übertragung. Da kommen die Kanäle abwechselnd (gemultiplext) mit bis zu 32 bits je Kanal, das MSB zuerst. Die Kanäle kommen doch hoffentlich nicht zeitlich hintereinander versetzt als analoge Signale raus. Also ist im DAC-Chip noch irgendeine seriell/parallel-Wandlung nötig, oder?
Was wiederum ein Zwischenspeichern bedeutet.

Und immer, wenn ein Speicher im Spiel ist, treten wieder Zugriffskollisionen auf, selbst auf dem DAC-Chip. Irgendwer/was muss warten. Eine Lösung sehe ich da nur, wenn mit unabhängigen Adress- und Datenleitungen gearbeitet wird.

Ich bin zwar kein Speicher- pder Hardwarespezialist, aber wenn schreiben und lesen nicht gleichzeitig ginge, dann wäre ein Puffer nutzlos und man könnte gleich jedes Bit und Byte auch in Echtzeit übergeben. Das ginge garantiert schief. Das gleichzeitige Lesen und Schreiben in FFIFOs ist nicht audiospezifisch. diverse Microcontroller würden sonst nicht funktionieren. Siehe http://www.mikrocontroller.net/articles/Speicher#BRAM Block RAM, üblicherweise in FIFOs im Einsatz.

Gruß Erwin

[uli.brueggemann]

Allerdings wird mit dem anliegenden Word Clock gearbeitet - dessen Jitter kann also durchkommen

Beste Grüße
Ulli

... ich gehe mal davon aus, dass es sich um die gleiche Clock handelt, nur die Frequenzen werden unterschiedlich geteilt. Aber klar, in diesem Bereich kann sehr viel klangentscheidend sein.

In dem von Ulli gezeigten Bild kommen die I²S Daten getaktet. Parallel dazu hat der Chip einen eigenen Oszillator. Wie das dann zusammenspielt wird nicht gezeigt.

Grüsse
Uli

[KSTR]

Der Memory-Controller in einem Async-USB-Reciever wird so ausgeführt sein, dass Lesezyklen, die den DAC-Chip füttern, Priorität haben. Schreibzugriffe ins FIFO werden für die Zeit verzögert (WAIT-Leitung).

[uli.brueggemann]

Der Memory-Controller in einem Async-USB-Reciever wird so ausgeführt sein, dass Lesezyklen, die den DAC-Chip füttern, Priorität haben. Schreibzugriffe ins FIFO werden für die Zeit verzögert (WAIT-Leitung).

Dass die Jungs, die den Chip entwerfen, bestimmt alle mögliche Tricks drauf haben, hat für mich eine sehr hohe Wahrscheinlichkeit. Nichtsdestotrotz, wenn nun gerade ein Schreibzugriff erfolgt, muss das Lesen dennoch warten. Oder das Design ist so, dass per entsprechender Logik ein Schreiben nur in bestimmten Zeitabschnitten zwischen den Lesezugriffen erfolgen kann. Und so eine Logik müsste sich denn auch bis in den DAC-Chip durchziehen. Wobei wir da auch nicht wirklich reinschauen können.

Ich hatte ja meinen Senf zum Thema begonnen mit dem Wörtchen "These". Um schlicht mal Möglichkeiten zu finden, die eben dafür verantwortlich sind, dass trotz Asynchronität, Pufferung etc. anscheinend die Qualität des ankommenden Datenstroms das Ergebnis beeinflusst. Ich halte eine sachliche Diskussion dazu eben zielführender als das Hin- und Her mit "Gibt's nicht - ich hör's doch - ich aber hör nix - gibt's doch -kann nicht sein..."

Wenn der von Ulli zitierte TDA1541 das Latchen perfekt machen täte, dann bräuchte er doch die Mutec MC-3+ nicht, oder?

Grüsse
Uli

[Thias]

...Nichtsdestotrotz, wenn nun gerade ein Schreibzugriff erfolgt, muss das Lesen dennoch warten. Oder das Design ist so, dass per entsprechender Logik ein Schreiben nur in bestimmten Zeitabschnitten zwischen den Lesezugriffen erfolgen kann. Und so eine Logik müsste sich denn auch bis in den DAC-Chip durchziehen. Wobei wir da auch nicht wirklich reinschauen können.

... ich denke mir so ein DAC kann man nicht mit einem PC vergleichen, bei dem alles frei software- und taskgesteuert ist. Der Ablauf wird ziemlich harwaregesteuert sein, bzw. ein starrer Ablauf in der Firmware, da kann nicht eben mal ein Interrupt zwischen funken, das Zeitregime ist fest vorgegeben, wenn geschrieben wird kann nicht gelesen werden... sozusagen nur eine Programmschleife, eine Ebene, ein Task... und das sehr maschinennah programmiert.

[KSTR]

Der Memory-Controller in einem Async-USB-Reciever wird so ausgeführt sein, dass Lesezyklen, die den DAC-Chip füttern, Priorität haben. Schreibzugriffe ins FIFO werden für die Zeit verzögert (WAIT-Leitung).

Dass die Jungs, die den Chip entwerfen, bestimmt alle mögliche Tricks drauf haben, hat für mich eine sehr hohe Wahrscheinlichkeit. Nichtsdestotrotz, wenn nun gerade ein Schreibzugriff erfolgt, muss das Lesen dennoch warten. Oder das Design ist so, dass per entsprechender Logik ein Schreiben nur in bestimmten Zeitabschnitten zwischen den Lesezugriffen erfolgen kann. Und so eine Logik müsste sich denn auch bis in den DAC-Chip durchziehen. Wobei wir da auch nicht wirklich reinschauen können.

Ich denke, man könnte zB die Schreibzugriffe in der Dauer kennen bzw beschränken, und ein etwas längeres Intervall nehmen, um schonmal den nächsten Lesezugriff anzumelden. Dann würde dieser Zugriff noch stattfinden und danach wäre Schreiben (und Lesen an sich genauso) blockiert bis der Lesezugriff vorbei ist. Ich könnte mal Ploytec mit dieser Frage belästigen, die bauen seit Jahren USB2-Transceiver für async. Mehrkanal-Audio (hauptsächlich OEM, zB für TASCAM), auf Basis von µC's mit USB2 I/O, wenn es genau interessierte...

Ich hatte ja meinen Senf zum Thema begonnen mit dem Wörtchen "These". Um schlicht mal Möglichkeiten zu finden, die eben dafür verantwortlich sind, dass trotz Asynchronität, Pufferung etc. anscheinend die Qualität des ankommenden Datenstroms das Ergebnis beeinflusst. Ich halte eine sachliche Diskussion dazu eben zielführender als das Hin- und Her mit "Gibt's nicht - ich hör's doch - ich aber hör nix - gibt's doch -kann nicht sein..."

"Kann schon sein", denn vollständige Isolation ist halt extrem schwierig zu implementieren, da braucht es wohl einen äusserst clever durchdachten und aufgebauten Re-Clocker.... die Frage ist dann, wie vollständig (quantitativ) die Jitterisolation sein muss, abhängig auch noch vom jeweiligen DAC-Chip...

[Thias]

Soooo,
ich bin jetzt erst mal drei Wochen im Norwegenurlaub...
Vielleicht findet ihr es bis dann heraus, warum gleiche Bits unterschiedlich klingen sollen


Nochmal eine ganz steile These.
Audio DA-Wandler wurden ja seinerzeit hauptsächlich für CD-Player entwickelt. Da hatte man ja einen gemächlichen und ziemlich kontinuierlichen Datenstrom.
Beim PC bekommt man einen großen Sack Daten hingeworfen, dann erst mal nichts....
Vielleicht sind manche DAC auf diese Anforderungen traditionell noch nicht ausgelegt von Puffergrößen etc...
Manche DAC-Entwickler haben sich auf diese großen notwendigen Puffer eingestellt... (das könnte es vielleicht erklären, warum ich keine gestresste CPU hören kann )

Wie dem auch sei.
Ich sehe es als den optimalen Weg an einen DAC zu wählen, der Daten ausreichend puffern kann und mit der diskontinuierlichen Datenbereitstellung gut umgehen kann. Technisch sollte das ja durchaus möglich sein.
Nicht optimal sehe ich alle Anstrengungen einen PC so zu vergewaltigen, damit er möglichst langsam und gleichmäßig arbeitet mit einem gleichmäßigen Datenfluß (um ein AudioCD-Laufwerk zu simulieren), um die Unzulänglichkeiten eines DAC auszugleichen. Das ist wie einen Porsche auf 25 km/h zu drosseln um ohne Führerschein zu fahren...

Grüße
Thias

[uli.brueggemann]

Thias,

wenn wir mal davon ausgehen, dass wir eine wav-Datei in CD-Qualität hören wollen, also 44/16, dann ist der Datenstrom nun einmal sehr langsam verglichen zum sonstigen CPU-Tempo. Nun hat ein z.B. per spdif angeschlossener DAC gar keine Möglichkeit, die Daten schneller zu bekommen, das Protokoll gibt vor, wann was übertragen wird. Insofern muss sich der PC anpassen.

Nun könnte man sich auch einen Puffer im DAC vorstellen. Wenn der aber zu groß wird, z.B. 1000 Samples/Kanal(was ja nicht wirklich groß ist), dann wird die Wiedergabe um Puffergröße/Abtastrate verzögert. Was hier also schon 22.6 ms wären. Man könnte den Puffer ja heutzutage problemlos groß machen, z.B. gleich die ganze CD im DAC abspeichern. Aber da will keiner solange warten, bis das per spdif übertragen ist. Selbst mit WLAN oder Ethernet dauert das zu lange.

Für mich besteht da auch nach wie vor noch der mögliche Adress-/Datenleitungskonflikt. Wenn man synchron zum Lesetakt ausliest und vielleicht in einer Zwischenzeit reinschreibt, ist das Management eines asynchronen Schreibens in den Puffer nicht gerade trivial.

Schönen Urlaub !

Grüsse
Uli

[Unicos]

Thias,

wenn wir mal davon ausgehen, dass wir eine wav-Datei in CD-Qualität hören wollen, also 44/16, dann ist der Datenstrom nun einmal sehr langsam verglichen zum sonstigen CPU-Tempo. Nun hat ein z.B. per spdif angeschlossener DAC gar keine Möglichkeit, die Daten schneller zu bekommen, das Protokoll gibt vor, wann was übertragen wird. Insofern muss sich der PC anpassen.

Nun könnte man sich auch einen Puffer im DAC vorstellen. Wenn der aber zu groß wird, z.B. 1000 Samples/Kanal(was ja nicht wirklich groß ist), dann wird die Wiedergabe um Puffergröße/Abtastrate verzögert. Was hier also schon 22.6 ms wären. Man könnte den Puffer ja heutzutage problemlos groß machen, z.B. gleich die ganze CD im DAC abspeichern. Aber da will keiner solange warten, bis das per spdif übertragen ist. Selbst mit WLAN oder Ethernet dauert das zu lange.

Für mich besteht da auch nach wie vor noch der mögliche Adress-/Datenleitungskonflikt. Wenn man synchron zum Lesetakt ausliest und vielleicht in einer Zwischenzeit reinschreibt, ist das Management eines asynchronen Schreibens in den Puffer nicht gerade trivial.

Schönen Urlaub !



Grüsse
Uli

Hi,

Muss man denn wirklich warten bis der Puffer voll ist?
Solange der Puffer schneller gefüllt als geleert werden kann konnte man damit doch sozusagen im Hintergrund den Puffer so groß wie man will machen. Und potentiell auch den ganzen Track einladen im Hintergrund. So machen wir es auch mit folve um die online Zugriffszeiten trotz Puffer so gering wie möglich zu halten.

Naive Gruesse

Thomas

[uli.brueggemann]

Solange der Puffer schneller gefüllt als geleert werden kann ...

Thomas,

schon klar. Aber wie willst Du den Puffer bei spdif schneller füllen als leeren? Kennst Du einen Dac der das kann?

Grüsse
Uli