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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.