Von einem High-End-Wandler bekomme ich 4 Daten, alle als 1-BIT-Audio mit
3.072MHz. Ich möchte beide L- und R-Kanäle zusammenmischen, also 1+3 und
2+4.
Üblicherweise müssen diese gefiltert werden, um digitale Signale zu
haben, die z.B. 16 Bit haben und die man dann addieren kann, um sie dann
wieder zurück zu verwandeln. Kann ich das auch direkt digital machen?
Abgesehen von der Umsetzung wäre zunächst zu klären, ob das überhaupt
theoretisch geht. Angenommen, ich nehme einen Addierer, dann bekomme ich
Werte von 0..3. Wie komme ich wieder zu einem 1-BIT-Audio?
Wäre es möglich, die Signale zu multiplexen, also einfach die beiden
Daten abzuwechseln? Dann hätte ich ein 6MHz-Signal, das wieder ein 1-Bit
Signal darstellt. Die 4 Daten vom Wandler sind synchron, soviel habe ich
schon gemessen.
Leider bringt der Artikel keine Lösung:
Beitrag "Wie addiert man digitale Audiosignale?"
Das kann man primitiv einfach re-quantisieren wenn man sich am
Delta-Sigma-Prozess erster Ordnung orientiert
<code>
Akku=A+B
IF Akku >=2 THEN
C=1
Akku=Akku-2
ELSE
C=0
ENDIF
</code>
Ergebnis ist C=(A+B)/2
Das leuchtet mir noch nicht so ganz ein. Wenn beide Signal hochsteuern,
kann doch nicht ein negatives Ergebnis rauskommen?
Ich interpretiere die "1" als +1 und die "0", als -1. Ein ständiger
Wechsel von 101010101 wäre also die Mittellage von 0,5 = Nulllinie. Wenn
mehrheitlich Einsen kommen, dann muss das Signal steigen. Wenn beide
steigen, dann müsste als Maximum auch permanent mehr, als 1 rauskommen
und irgendwo eine Teilung durch 2 entstehen. Die sehe ich im Code, aber
wenn ich das geistig durchspiele, komme ich nicht zum Ergebnis. Als
Beispiel könnte man den anderen Datenstrom auf 0 setzen und müsste dann
als Ergebnis das Halbe andere Signal bekommen. Ist das so?
Ich rechne so:
Wenn A=0 und B=0
Dann Akku +0
Daraus folgt C jedesmal = 0
Also C=(0+0)/2=0
Wenn A=1 und B=1
Dann Akku +2
Daraus folgt C jedesmal = 1
Daraus folgt Akku -2
Also C=(1+1)/2=1
Wenn A=1 und B=0 (oder anders herum)
Dann Akku +1
Daraus folgt im Wechsel
Akku=1 -> C=0 und Akku bleibt 1
Akku=2 -> C=1 und Akku wieder 0
Also C=(1+0)/2 = 1 0 1 0 1 0 ... im Mittel somit = 0,5
Jens U. schrieb:> Abgesehen von der Umsetzung wäre zunächst zu klären, ob das überhaupt> theoretisch geht.
Geht natürlich.
> Angenommen, ich nehme einen Addierer, dann bekomme ich> Werte von 0..3. Wie komme ich wieder zu einem 1-BIT-Audio?
Indem du den Takt verdoppelst...
Bitklopfer schrieb:> Ich rechne so:
Das muss ich mal probieren.
c-hater schrieb:>> Angenommen, ich nehme einen Addierer, dann bekomme ich>> Werte von 0..3. Wie komme ich wieder zu einem 1-BIT-Audio?> Indem du den Takt verdoppelst...
Der Takt ist festgelegt.
Jens U. schrieb:> Der Takt ist festgelegt.
Dann geht's logischerweise nicht ohne Informationsverlust. Sprich: du
brauchst einen Filter.
Für den gibt's ziemlich viele Implementierungsvarianten im gesamten
Bereich zwischen Kostenminimum und (unerreichbarem) Qualitätsmaximum.
Such' dir einen aus.
Tendenziell ist die Lage so, dass du Richtung bessere Qualität eine
zunehmende Zahl von "Umgebungsbits" in die Entscheidung mit einbeziehen
musst.
Als Beispiel ein Filter, er bezieht nur das direkte Vorgängerbit in die
Entscheidung ein und hat folgende Logiktabelle:
C C-1 A B
0 0 0 0
0 1 0 0
1 0 1 0
0 1 1 0
1 0 0 1
0 1 0 1
1 0 1 1
1 1 1 1
Das ist im Prinzip genau das, was Bitklopfer da mit sehr viel Prosa auch
schon beschrieben hat und stellt das untere Ende der möglichen
Qualitätsskala dar. Verbal könnte man das als "ziemlich grausam"
beschreiben...
Jens U. schrieb:> Wäre es möglich, die Signale zu multiplexen,
Sicher geht das, BTDT. Allerdings braucht es eine sehr gute analoge
Umschaltung, wenn das am mal gefiltert werden soll, oder es muss
entsprechend aufbereitet werden, dass keine unsauberen Signalperioden
entstehen. Die Chips, die das 1-Bit-Audio annehmen, synchronisieren sich
meistens, weil sie ein PDM erwarten, aber wenn das eine Analogschaltung
ist, die PWM erwartet, weil sie auch kleinste Pulsänderungen
mitverarbeiten soll, dann hast du da ein Problem.
Sind denn die Daten mit einem Takt gerastert? Oder ist das nicht ganz
und gar ein S/PDIF Signal?
Was du hoffentlich hast, ist DSD und da geht das. Von der spektralen
Qualität her ist das sogar besser, als Mischen und wieder Wandeln, aber
es gibt einen Phasenversatz für den einen zugemischten Kanal. Der ist je
nach Anwendung relevant. Wenn du den minimieren willst, kannst du auf
höheren Taktraten multiplexen. Ich mache das z.B. mit vollem FPGA Takt.
Da kommt dann so eine Art TDM raus :-)
Der Ansatz ist aber nur für wenige Anwendungsfälle nutzbar, denke ich.
Ein solches Signal lässt sich mit einem FPGA auch sehr leicht dezimieren
und mischen. Das sollte aber nicht ein Wandler 1. Ordnung sein, denn:
c-hater schrieb:> Verbal könnte man das als "ziemlich grausam"> beschreiben...
Das ist auch audiotechnisch grausam. Da bei einem so einfachen Verfahren
das Signal neu erzeugt wird und dies schlecht, sind wir sehr weit vom
"Mischen" entfernt.
Der ordentliche Weg ist nach wie vor ein möglichst gutes Dezimieren auf
hohe Auflösung und Abtastrate, Phasenkorrektur (wenn nötig) und gfs
Resampling und dann einfach addieren und wieder in ein gutes PDM / DSD
verwandeln.
c-hater schrieb:> Dann geht's logischerweise nicht ohne Informationsverlust. Sprich: du> brauchst einen Filter.
Ich verstehe nicht, wie das sein soll: Ich bekomme 2 Signale mit
DEMSELBEN Takt. Wenn ich den verdopple, was möglich ist, geht eigentlich
nichts verloren.
Und mit Filter bin ich wieder beim klassischen Digital-Mixer.
Gehen wir also von der Variante Mischen aus und dem doppelten Takt. Das
mit dem Versatz habe ich verstanden. Könnte man es eventuell so machen,
dass einmal das eine und mal das andere Signal zuerst weitergegeben
wird?
Jens U. schrieb:> Ich verstehe nicht, wie das sein soll: Ich bekomme 2 Signale mit> DEMSELBEN Takt. Wenn ich den verdopple, was möglich ist, geht eigentlich> nichts verloren.
Natürlich nicht. Schrieb ich in
Beitrag "Re: 1-BIT-Audio: Zwei Quellen mischen"
ja auch so.
Darauf antwortetest du in
Beitrag "Re: 1-BIT-Audio: Zwei Quellen mischen":
> Der Takt ist festgelegt.
Das kollidiert aber nun mit deiner neuen Aussage, dass die
Taktverdopplung doch möglich wäre...
Was also ist dein Problem? Dass du nichtmal weisst, was eigentlich
möglich ist in deiner Anwendung?
Ja, dann kann man dir auch nicht wirklich helfen. So ist das nunmal...
