Xmega Soundcheck

Anbei die Fotos. Nen bisschen unordentlich... aber es ist ja auch nur 
ein Test. Der Verstärker ist aus einem China Brüllwürfel.

XMegas sind cool und man kann sie mit AVR-Studio und AVR-ISP mkII oder 
Dragon programmieren. All das hat man sowieso ´rumliegen...

Der XMega kann es klanglich mit einem guten UKW-Radio aufnehmen, wenn 
man den Ausgang gut filtert und die internen Einstellungen optimal sind. 
Für HiFi reicht es nicht ganz, da bei etwa -50db deutliches Rauschen und 
Digitalstörungen zu hören sind. Aber für Spielzeug und Diktiergeräte 
durchaus brauchbar ohne zusätzliche, aktive Hardware.

anbei mal nen Digiknipse Video. Ich hoffe die Größe ist noch akzeptabel. 
Naja ich find es hört sich OK an. Erstens ist der Verstärker und der 
Speaker extrem billig (aus einem 5 Euro USB Brüllwürfel) und zweitens 
ist das halt nur 8Bit Sound.

Mal sehen vielleicht bau ich nachher noch eine SD Karte rein, dann kann 
man mal Classic abspielen ;)

Der XMega kann 12 Bit auflösen, warum spielst Du kein 12-Bit Sample ab? 
Klingt viel besser. Tip: auf ein 16MBit Dataflash passen etwa 30 
Sekunden Stereo-Mucke bei 32kHz Abtastrate. Das Dataflash ist durch 
seine 2 Puffer auch schnell genug, die Sounddaten ohne weitere 
RAM-Puffer azunehmen.

Ja wiegesagt das ist nur nen ganz billiger Test. Das Sample steht auch 
im internen Flash des Xmegas. Am Ende soll mal ein neues Roboterboard 
herauskommen, und der (autonome) Robi soll (weils der Xmega halt 
mitmachen kann .... ;) kurze Geräusche ausgeben wenn er 
Zustandsänderungen erfährt... Für den Zweck ists mehr als ausreichend. 
Ich bastel mal weiter und mach noch eine SD Karte dran, dann kann ich 
auch mal Stereo 12bit, 44Khz testen :)

Was mich noch interessieren würde, ob der RC Filter am DAC Ausgang 
überhaupt gebraucht wird. Ab welcher Sample Rate kann man darauf 
verzichten.
Und zweitens was würdet Ihr mir für Werte für C und R empfehlen. Zurzeit 
habe ich einfach mal ein 330nF Folienkondensator und ein 100 Ohm 
Widerstand genommen. Any hints?

Interessant!
Wie hast du denn den kleinen Verstärker angeschlossen? Welche Referenz 
für den DAC? Reichen die 1V oder hast du AVCC (3.3V) genommen?
Koppelkondensator?

Ob man damit auch höherohmige Kopfhörer direkt treiben könnte? Mit 
Schutzwiderstand am besten in Reihe.

3v3 nehme ich als Referenz. 1v geht auch, aber es raucht dann mehr 
(Drahtverhau halt ;). Ich hatte einen kleinen PC Speaker (0.25W) direkt 
am Pin probiert. Die Spannung am Pin ist dann sofort weggebrochen.

Kai O. schrieb:
> 3v3 nehme ich als Referenz. 1v geht auch, aber es raucht dann mehr
> (Drahtverhau halt ;). Ich hatte einen kleinen PC Speaker (0.25W) direkt
> am Pin probiert. Die Spannung am Pin ist dann sofort weggebrochen.

Du benutzt den Ausgang doch direkt als Eingang für den Verstärker. Mit 
welcher Referenz kriegt man die 12Bit denn möglichst gut ausgereizt 
(ohne einen handelsüblichen Audioverstärker zu übersteuern)?

Erik schrieb:

> Was mich brennend intressieren würde; kannst du das bitte mal testen?!
>
> -Erreichabre Qualität der Audioausgabe, bringt man beinahe hifi hin?!
>
> -Ausgabe einer Wave Datei mit 44.1 KhZ und 12 Bit.... Bringt dann ein
> Oversampling noch was? Theoretisch könnte der DAC 100 kHz?
>
> -Das File sollte ein anspruchvolles sein. Z.B. ein kurzes Klavierstück
> mit Dynik.


Siehe hier: 
Beitrag "Re: Xmega Soundcheck"

@ Erik:
Wieso sollen immer andere die Arbeit machen?

Alex schrieb:
> Wer es perfekt will, nimmt einen externen 16-Bit DAC der über SPI
> angehängt wird.

Genau da beginnt das Problem. Gute Audio-Codecs habe kein SPI, sondern 
I2S bzw. right- oder left justified 24 Bit Dateninterface. Das kann der 
XMega nicht direkt bedienen. Eine Lösung ist es, Interfacewandler in 
Form kleiner Controller dazwischenzuschalten. Beispielsweise so wie 
hier: Beitrag "SD-Karten-Wave-Recorder"

@kai

Ganz offiziell: Ich möchte dich bitten, dass du deine Erfahrungen / 
Quellcode zur SD-Karte veröffentlichst, und auch wo (Codesammlung, 
eigener Threat,..) weil man die SD-Karte wunderbar mit deiner 
Soundausgabe kombinieren könnte.
Es bräuchte dann eine Transferroutine im xmega, die die Daten von 
USB=>UART empfängt und in die Karte schreibt, mit Zeigerarray 
(Inhaltsverzeichnis)...
Mit einem Konvertierprogramm von WAV-PCM zu RAW (mono) könnte man dann 
Soundamples vom PC in die SD-Karte laden (und natürlich wieder 
abspielen)!

!! Zur Verbesserung der Soundqualität !!
Man könnte die Sounddaten 8 Bit Delta-Sigma codieren!
D.h. man speichert nur noch die Differenz zum Vorgängerwert.
Weil im Speicher keine Bitfehler existieren, wäre das problemlos.
So könnte man ohne viel Aufwand (eine Addition pro Wert) und 
verlustfrei(!) auf volle 12 Bit kommen!
Das funktioniert aber nur, wenn die Sampelrate so hoch und/oder die 
höchste Signalfrequenz so niedrig ist, dass die Differenz nie größer als 
+/- 127 ist.
Eine hohe Sample-Rate ist aber sowieso für die Soundqualität gut.
Natürlich könnte man sich auch auf weniger (als 8) Bit beschränken, dann 
ist aber der SW-Aufwand größer und man müsste wieder schneller 
samplen...

Zusätzlich könnte man zum Resamplen von 16/14 Bit auf die 12 Bit (DAC) 
noch Dithering mit Noise Shaping benutzen. Da bräuchte es dann einen 
FIR-Digitalfilter-Algorithmus für den PC. Das muss der D-S-Codierung 
vorgeschaltet werden!
So müsste man zu wirklicher HIFI-Qualität kommen.

Wenn ich Zeit hätte, könnte ich das in EXCEl (Visual Basic)
programmieren ;-))

PS:
Ich habe ein Xmega-Board von Chip45.com da ist schon eine 
USB-USART-Bridge und ein Micro-SD-Slot drauf!

Gruß

Alex

Was nützt all der Aufwand, wenn der XMega DAC nicht sauber ausgibt? Alle 
Klimmzüge tun der Qualität nicht gut, weder in Hard- noch in Software. 
CD-Qualität oder besser erreicht man nur mit nativen 16Bit bei 44.1kHz 
oder 48kHz Samplerate. Und das auch nur mit externen Wandlern. Zum 
Datenschippen und -verwalten ist der XMega schnell genug und auch gut 
geeignet.

Servus,

angehängt eine kleine Demo welche die Soundsamples nun von SD Karte 
liest.
Der Lesetransfer von der SD Karte läuft über DMA. DMA Ch2 gibt den Takt 
vor (Schreiben von 0xFF auf MOSI) und DMA Ch3 liest die Daten (515 * 8 
Bit von MISO) in einen Puffer ein.

Insgesamt habe ich drei State Maschinen (Maschinchen ;) benutzt. Die 
erste verwaltet den DAC DMA, die zweite den SD Katen DMA und die dritte 
den Arbeitspuffer, welcher die Oversampled Daten für den DAC aufnimmt.

Zur Ansteuerung der SD Karte habe ich auf den Code von Roland Riegel 
zurückgegriffen und diesen für meine Zwecke angepasst. Zusätzlich wird 
noch das CID und CSD Register der Karte dekodiert und ausgegeben.

Um die Sache zu vereinfachen (nur ne Demo!) wurden die Samples ohne 
Filesystem und Header direkt auf die SD Karte geschrieben (Linux dd). 
Die Soundkonvertierung erfolgte aus einem MP3 (128Kbit) via SOX (Linux) 
nach RAW Format. Auf der SD Karte sind ca. 4 Minuten Musik mit 44Khz, 
16Bit, Little Endian, Unsigned, Mono, PCM gespeichert. Ein (lineares) 
Oversampling erfolgt im MC auf 4 * 44.1Khz.

Auf dem Oszi kann man gut erkennen, wie der 4Mhz SPI Transfer (Dauer ca. 
1ms) durch den Output des DAC wandert (Messung direkt am PIN). Ich nehme 
an dass kommt durch die fehlende Trennung des Digital- und Analogteils 
zustande? Die Störungen wandern dann natürlich auch durch den Audio 
Verstärker. (Ich hatte die von Atmel empfohlene Enstördrossel 
wegelassen, weil ich diese nicht vorrätig hatte...)

Videos und Fotos folgen.

PS: Der Code ist natürlich noch verbesserungswürdig ;)

Ein Foto vom Aufbau (Sehr bastelig... ;). Ein Video gibts bei YouTube 
(Möchte den Foren Server nicht so quälen)

http://www.youtube.com/watch?v=wIfAMO3v07U

Hier kann man gut die Störungen sehen... "Gruschpeln" beim Abspielen.

Das ist ja funny (Xmega Movie Player)...:
http://www.youtube.com/watch?v=-vQ4VfyVYyE&NR=1

@Kai O.

warum wird der SD-SPI auf 4MHz gesetzt, obwohl (alle mir bekannten) SD 
Karten mindestens 20MHz verkraften?

Kai O. schrieb:
> Das ist ja funny (Xmega Movie Player)...:
> http://www.youtube.com/watch?v=-vQ4VfyVYyE&NR=1

ja, der "PICprogrammer" baut und coded schöne sachen. Leider ausser 
videos bekommt man nix zu sehen, kein code, kein doku, keine emails.

Werner B. schrieb:
> @Kai O.
>
> warum wird der SD-SPI auf 4MHz gesetzt, obwohl (alle mir bekannten) SD
> Karten mindestens 20MHz verkraften?

Es kommt vor dass die SD Karte sporadisch (teilweise erst nach ein paar 
Hundertausend gelesenen Blöcken) kein Datenblockstarttoken (0xfe) mehr 
sendet (Jedenfalls warte ich ewig darauf). Ich dachte erst die 
Geschwindigkeit für den fliegenden Aufbau ist etwas hoch, die 
sporadischen Fehler treten aber auch mit 4Mhz auf. Wenn jemand einen 
Verdacht hat an was es evtl. liegen könnte, dann her damit :). Es 
funktionierte auch schon mit 16Mhz.

Kai O. schrieb:
> Es kommt vor dass die SD Karte sporadisch (teilweise erst nach ein paar
> Hundertausend gelesenen Blöcken) kein Datenblockstarttoken (0xfe) mehr
> sendet

Was macht die Karte?! IMHO sendet einzig der Master einen 
Datenblockstarttoken und später einen Datenblockstoptoken, aber nur bei 
'multiple block read'. Warum betreibst Du die Karte nicht im 'single 
block read' Modus? Ist immer noch schnell genug.

Travel Rec. schrieb:
> Kai O. schrieb:
>> Es kommt vor dass die SD Karte sporadisch (teilweise erst nach ein paar
>> Hundertausend gelesenen Blöcken) kein Datenblockstarttoken (0xfe) mehr
>> sendet
>
> Was macht die Karte?! IMHO sendet einzig der Master einen
> Datenblockstarttoken und später einen Datenblockstoptoken, aber nur bei
> 'multiple block read'. Warum betreibst Du die Karte nicht im 'single
> block read' Modus? Ist immer noch schnell genug.

Ich meinte das "Startblocktoken" (0xfe) -> CMD17 (READ_SINGLE_BLOCK). 
Also das erste Byte vom Datenblock den die Karte sendet.

Alex P. schrieb:
> dein Steckbrettaufbau ist ziemlich kriminell für die hohen
> Digitalfrequenzen - sorry das sagen zu müssen.
> Vor allem die sehr langen Drähte sind heftig - da hast du Induktivitäten
> mit Sende- und Empfangsantenne.
> Ein Siebkondensator für die SD-Karte ist zwar gut gemeint, aber ein Elko
> taugt HF-mäßig leider gar nix! Da ist ein >= 100nF-Keramikkondensator
> (mit 10uF Tantal-C parallel dazu) viel besser - aber nur wenn er direkt
> dort angelötet ist, wo er gebraucht wird.
>
Ja der Aufbau ist nix. Ich wollte ursprünglich den Xmega nur 
ausprobieren, bevor ich mein Roboter Board Layoute ;). Aber wie das denn 
immer so ist.. Man kommt vom Hundersten zum Tausendsten.

Mich würde als (Softwaremensch) natürlich schon sehr die Behebung der 
Störungen interessieren. Interessant ist dass die Störungen (vom SD 
Takt) auf den gesamten Versorgungsleitungen (ca. 400mV Amplitude auf Gnd 
und VCC) zu finden sind. Am stärksten direkt an den Versorgungspins der 
SD Karte. Keine Ahnung ob Entstörung noch etwas bringt bei diesem 
Drahtverhau. Aber ich probiere mal den von dir vorgeschlagenen Tantal 
direkt an der SDKarte (geht auch 10uF Keramik?).
Ansonsten hatte ich die GND Leitungen noch sternförmig gesteckt (nachdem 
die Fotos oben geschossen wurden) und die SD Signalstrippen gekürzt. 
Einmal hatte ich (bei nicht verbundender Masse am Audio Stecker, 
Verstärker ausgesteckt und Masseabgriff mit dem Oszi direkt am 
Boardstecker) die Störungen fast auf Null. Habe ich dann die Masse 
wieder verbunden, waren sie wieder da... :( Naja du siehst ich habe 
nicht wirklich Ahnung und bin für weitere Tipps (auch fürs spätere 
Boardlayout) sehr dankbar.

Da du dich auszukennen scheinst... Was nimmt man am besten als Filter 
vor dem Verstärkereingang. Ich hatte diesen Rechner hier zur Berechnung 
eines RC Glieds benutzt: 
http://www.sengpielaudio.com/Rechner-RCglied.htm

Aktuell benutze ich 22 Ohm und 330 nF (Folie).

Ich habe gesehen auf dem Atmel Xplain Board (hat einen kleinen 
Lautsprecher samt Verstärkerchen) ist gar kein Filter? 
(Schaltplanauschnitt hängt an)



> Source-Adress-Fehler der DMA -> läuft über den Pufferbereich darüber
> hinaus.

Was meinst du genau damit?

>
> Poste doch mal die Links zu den SD-Infos. Das interessiert mich sehr.
>

Abgespeckte ofizielle Spez:
http://www.sdcard.org/developers/tech/sdcard/pls/

Das verstehe ich nicht ganz ... was du da machst.

1

      // Stauchung: 16Bit -> 12bit

2

      cur = (srcbuf[dac_bufpos    ] & 0xF0) >> 4; // Niederwertigste Bits abschneiden

3

      nxt = (srcbuf[dac_bufpos + 1] & 0xF0) >> 4;

Ist das nicht eine Stauchung auf 4 Bit? (Maske 0xF0 statt 0xFFF0)

Ich habe von diesem "Audio Kram" keine Ahnung (bei meinem Tinnitus habe 
ich meine "Musik" immer dabei, auch ohne Gadgets ;-))
Aber interessiern würde es mich doch!

Werner B. schrieb:
> Das verstehe ich nicht ganz ... was du da machst.
>

1

>       // Stauchung: 16Bit -> 12bit

2

>       cur = (srcbuf[dac_bufpos    ] & 0xF0) >> 4; // Niederwertigste

3

> Bits abschneiden

4

>       nxt = (srcbuf[dac_bufpos + 1] & 0xF0) >> 4;

5

> 

6

>

> Ist das nicht eine Stauchung auf 4 Bit? (Maske 0xF0 statt 0xFFF0)
>
> Ich habe von diesem "Audio Kram" keine Ahnung (bei meinem Tinnitus habe
> ich meine "Musik" immer dabei, auch ohne Gadgets ;-))
> Aber interessiern würde es mich doch!

Das steht so aber nicht im geposteten Code. Sondern es sieht so aus:

1

// Stauchung: 16Bit -> 12bit

2

cur = srcbuf[dac_bufpos    ] >> 4; // Niederwertigste Bits abschneiden

3

nxt = srcbuf[dac_bufpos + 1] >> 4;

Upps, das ist mein Fehler. Ich nehme alles zurück und behaupte das 
Gegenteil  8-(

Kai O. schrieb:
> Das ist ja funny (Xmega Movie Player)...:
> http://www.youtube.com/watch?v=-vQ4VfyVYyE&NR=1

wow, vor allem mit 1kB Code! Macht das Display da irgendwas - außer 
"display'n"?

Falls es interessiert. In meinem gepostetem Code habe ich noch 2 Bugs 
entdeckt. Erstens wird bei der Oversampling Berechnung beim Letzten 
Sample über den Puffer indiziert (+1). Deswegen war die Soundqualität 
auch sehr schlecht ohne Filter (knacksen).
Und zweitens scheint der DMA Transfer nicht fertigzuwerden, wenn das 
Debugging mit printf's angeschaltet wird. Hier brachte Abhilfe die 
Interrupt Flags (z.B. DMA_CH0TRNIF_bm) in DMA.INTFLAGS erst beim Starten 
des nächsten DMA Transfers zurückzusetzen. Die eigentliche Fehlerursache 
habe ich leider (wegen Zeitmangels) noch nicht herausfinden können....

Ich habe das Oversampling zwischenzeitlich entfernt. Ich höre keinen 
Unterschied ob mit oder ohne.

Ich poste bei Gelegenheit den aktuellen Code.

TecDroiD schrieb:
> kann man das Ganze auch ohne den Timer triggern? ich möchte die volle
> Bandbreite nutzen, kann ich den trigger nicht auf DACA.STATUS &
> DAC_CH0DRE_bm setzen?
> und äh wie geht das? ich bau mir hier nen wolf und nix geht mit dma

Keine Ahnung was du meinst. Kannst du das nicht ein wenig verständlicher 
ausdrücken?

X- Rocka schrieb:
> Kai O. schrieb:
>> Das ist ja funny (Xmega Movie Player)...:
>> http://www.youtube.com/watch?v=-vQ4VfyVYyE&NR=1
>
> wow, vor allem mit 1kB Code! Macht das Display da irgendwas - außer
> "display'n"?

Äh naja, also die DMA aufsetzen und starten ist ja jetzt nicht 
kompliziert ;)

TecDroiD schrieb:
> So wie ich das verstanden habe triggert der timer im Beispiel per event
> den DAC, welcher sich über den DMA dann seine Daten holen kann.
>
> Wenn man die vollen 1MS/s voraus setzt, kann man dann nicht auch die
> ganze Sache ohne den Timer realisieren?

Der DMA legt dem DAC sofort ein neues Sample in den Puffer wenn der DAC 
Puffer leer meldet (DREIF Flag). Die DAC Conversion wird aber erst durch 
den Timer via Event angestoßen.
Kommt der DAC nicht nach, z.B. weil die Conversion Rate (in 
DACA.TIMCTRL) zu niedrig eingestellt ist, dann zieht er die 
Ausgabe-Frequenz deiner Waveform runter (z.B. wird dein Sinus dann nur 
noch mit 10Hz, anstatt 20Hz ausgegeben).

Übrigend bekommst du im Sample und Hold Modus IMHO keine 1MS hin. Das 
geht nach Datenblatt nur im Continuous Mode (Nur 1 DAC Kanal).

Willst du eine Waveform ohne Timer ausgeben? Warum? Du kannst auch die 
volle Sample Rate mit Hilfe des Timers erreichen.

> zur Entstörung:
> Ein 10uF Keramikkondensator ist das Beste! Dann braucht es den Tantal
> nicht mehr. Genau so wichtig ist eine stabile Masseleitung. Wenn du eine
> Platine machst, ist eine Massefläche das Beste. Da bei hohen Frequenzen
> jedes Stückchen Leitung eine Induktivität bedeutet, die schnell eine
> hohe Impedanz hat, sind hier kürzeste Leitungen ein Muss (jeder cm ist
> da viel).
> Desweiteren versuche gleich am Entstehungsort die HF (=> schnelle steile
> Schaltflanken) mit Keramik-Cs abzupuffern. Also bei jedem Digital-IC >=
> 100nF von Vcc zu GND. Also Keramik-C direkt an die SD-Buchse Vcc-GND!
> Für die Audio- und NF-Leitungen gilt das natürlich nicht. Hier ist ein
> abgeschirmtes Kabel angebracht, wenns etwas länger ist.

Ich habe jetzt eigentlich keine Probleme mehr mit den digitalen 
Störungen. Dein Tipp mit dem 10uF + 1nF an der SD Karte habe ich 
umgesetzt (haben die SD Karten nicht auch interne Ablockkondensatoren?)

Evtl. lagen meine mit dem Oszi aufgefangenene Störungen aber auch daran 
dass ich die Masseklemme des Oszis zuweit vom Geschehen angeschlossen 
hatte. Mit einem Draht an der Massefläche des Tastkopfs (anstatt die 
Krokos) und Masseabgriff direkt am Verstärker, siehts OK aus.

Das Gruschpeln bei der Ausgabe hatte ja dann auch einen anderen Grund, 
als ich zuerst angenommen hatte (Programmierfehler).

> Mit einer höheren Vref für den DAC (bis 2,4V konstant & gesiebt) kommt
> mehr Saft raus und der Störspannungsabstand verbessert sich
> entsprechend.

Ich habe als DAC Ref. VCC (also 3.3v) eingestellt. Das sollte doch 
eigentlich OK sein. Mit 1v Ref. (Intern) ist der Rauschabstand nicht der 
Hit (schon ausprobiert).

> zur DMA-Vermutung:
> Du hast sicher die DMA so programmiert, dass sie deinen Pufferspeicher
> wie einen Ringpuffer immer wieder durchläuft (Adressincrement &
> Adressreload). Wenn da die Länge nicht stimmt, geht die Adresse über das
> Ende des Puffers hinaus. Dann wird auch das genommen, was da steht z.B
> Variable.

Das sollte eigentlich stimmen (konnte zumindest noch keinen Fehler 
entdecken). Mein SD-Karten-Fehler ist auch sehr sporadisch.

> zum (Antialiasing-)filter:
> Ein einfaches RC-Glied ist nicht so gut, da es bei der 10-fachen
> Frequenz erst auf 1/10tel dämpft. Wenn deine Sampelrate aber bei >20kHz
> liegt, hört man davon nichts mehr - eigentlich ist dann kein Filter
> nötig.
> Falls Filter, dann nimm einen 2-poligen Butterworth mit 20kHz
> Grenzfrequenz.
> Die 22 Ohm am DAC-Ausgang ist Quatsch - er hat selbst einen viel
> größeren Innenwiderstand. Eigentlich solltest du einen OPA-Verstärker an
> den DAC anschließen. Dann kannst du am Ausgang sieben. Bleib' aber bei
> 1k...20k-Widerständen.
> Dann stimmt die Formel: Fg= 1/(2*Pi*R*C) => 20kHz

Wieder was gelernt :). Danke. Was für ein OpAmp (z.B. von Reichelt, RS 
oder CSD) kannst du denn empfehlen für den Einsatzzweck?
Baut mann normalerweise so ein Butterworth Filter diskret auf, oder 
nimmt mann da fertige IC's (gesehen bei R+S)?

Ich möchte deinen Vorschlag zum Dithering umsetzen. Mein geplanter 
"Algo" würde 16-faches Oversampling machen. Und die abgeschnittenen lsb 
4 Bits auf die eingefügten Samples aufteilen. Angenommen die Samplerate 
wäre 30kS, dann wäre die Oversampled Ausgabefrequenz 480kS (Periode 
2us).

Die Ausgabe wäre dann natürlich nicht mehr "glatt", sondern das lsb 
würde toggeln. Z.B. 32000 (16Bit) resampled nach 12Bit ergibt: 4062.5. 
Ausgegeben mit 12 Bit: 4062 4063 4062 4063 ... (bis 16)

Denkst du ich bräuchte dafür einen Filter? Oder filtert dass der 
Lautsprecher (Tiefpass) weg. Wenn ein Filter gebraucht würde, würde es 
dann nicht auch ein RC-Tiefpass (natürlich diesmal mit OpAmp) tun?

Bringt das Dithering überhaupt hörbar was?

TecDroiD schrieb:
> was ich nicht verstehe ist, warum du beim dma ein DMA_CH_DESTDIR_INC_gc
> einwirfst. darf sich die Adresse denn überhaupt ändern?
>
> irgendwas mach ich auch falsch. ich häng mal meinen spielcode an..
> vielleicht sieht wer was?

1

// Quell und Ziel Adressen inkrementieren.

2

DMA.CH0.ADDRCTRL =   DMA_CH_SRCRELOAD_TRANSACTION_gc | DMA_CH_SRCDIR_INC_gc

3

                      | DMA_CH_DESTRELOAD_BURST_gc | DMA_CH_DESTDIR_INC_gc;

Das DAC Register ist 2 Byte (weils ein 12 Bit DAC ist). Das obige 
DMA_CH_DESTRELOAD_BURST_gc | DMA_CH_DESTDIR_INC_gc besagt jediglich dass 
nach 2 übertragenen Bytes (Bursttransfer) der Zielzähler resettet wird. 
Er zählt also 0,1,0,1... RegLow, RegHigh, ...

> würde toggeln. Z.B. 32000 (16Bit) resampled nach 12Bit ergibt: 4062.5.
> Ausgegeben mit 12 Bit: 4062 4063 4062 4063 ... (bis 16)
Ups. Richtig heißen muss es:
Z.B. 33000 (16Bit) resampled nach 12Bit ergibt: 2062.5.
Ausgegeben mit 12 Bit: 2062 2063 2062 2063 ... (bis 16)


Noch ein Bsp.: 65110(16Bit) -> 12Bit: 4069.375 -> Lsb's: 0110 -> 6. D.h. 
Korrekturwert 6 muss auf 16 12 Bit Werte aufgeteilt (offsetted) werden.

TecDroiD schrieb:
> irgendwas mach ich auch falsch. ich häng mal meinen spielcode an..
> vielleicht sieht wer was?

Moin,

mit Sinuswave Ausgabe habe ich zuerst auch experimentiert. Habe mal in 
meinem svn Repository gekramt, und das gefundene Testprogrämmchen 
angehängt ;).

Ansonsten fällt mir an deinem Code auf...

1

DACA.CTRLC = DAC_REFSEL_INT1V_gc | ADC_RESOLUTION_12BIT_gc;

Hier stimmen die Flags nicht (ADC Bitmaske!)

1

DACA.CTRLB = ~(DAC_CHSEL_gm) | DAC_CH0TRIG_bm | DAC_CHSEL_SINGLE_gc;

Ausknipsen von Bits funktioniert so nicht... Wenn du sowieso eine 
Zuweisung machst sind die nicht angeknipsten Bits 0.
Das hast du an einigen Stellen so gemacht. Weiter habe ich jetzt nicht 
geschaut. Aber dort müsstest du erstmal aufräumen.

Axel, vielen Dank für die Infos. Ich habe mir nun ein paar Grundlagen 
über Opamps angelesen. Finde das Themengebiet ganz interessant und würde 
gerne ein wenig damit experimentieren :)

Ein paar Fragen sind aber noch offen.

Dieser Rechner (http://www.sengpielaudio.com/Rechner-filter.htm) 
berechnet einen aktiven Filter mit OpAmps (was ist das eigentlich für 
ein Filter-Typ?).

1

 Aktives High Cut (Tiefpass) Filter

2

         +---------+--------+

3

         |         |        |

4

         R2        C2       |

5

         |         |   |\   |

6

 IN--R1--+---R3----+---|-\  |

7

         |             |  >-+--- OUT

8

         |         +---|+/

9

         C1        |   |/

10

         |         |

11

  -------+---------+--------------

Grenzfrequenz: 20Khz (ist das OK für Audio?)
r1: 371 Ohm
r2: 1k Ohm
r3: 185 Ohm
c1: 61nF
c2: 15nF

Nun, r1 kann man u.a. durch Veränderung von c2 beeinflussen. Welche 
Eingangsimpedanz für diesen Filter würde sich dann anbieten, oder hat 
sich in der Praxis bewährt? Der DAC Innenwiderstand liegt nach Xmega 
Datenblatt um die 270 kOhm. Also bräuchte ich noch einen zweiten Opamp 
als "Impedanzwandler" oder "Spannungsfolger" vor diesen geschaltet.

Auf meiner RS Bestellliste stehen jetzt mal diese Opamp-Typen: MCP6001, 
lm358 und ts922. Der letzte soll (nach Forum und Datenblatt) ordentlich 
Strom am Ausgang liefern könnnen. Da ich (wie Ihr wisst) keinen 
wirklichen Plan von Analogtechnik habe (aber möchte das lernen), würde 
ich mich über Vorschläge freuen, welche Opamps ich am Besten bestellen 
soll. Es stehen übrigens 3v3 und 5v als Versorgungsspannung zur 
Verfügung (keine negative Spannung).

Danke euch :)

>> Was für ein OpAmp (z.B. von Reichelt, RS
>> oder CSD) kannst du denn empfehlen für den Einsatzzweck?
> Es kommt auf die Betriebsspannung an. Wenn er auch mit
> einfach-Versorgung laufen soll, muss es auf jeden Fall ein
> Rail-Rail-In/Out-OPA mit bspw. 2,7...5,5V Betriebsspannung sein. Soll er
> nur einen Line-Eingang treiben, sind die restlichen Daten ziemlich egal
> (Bandbreitenprodukt >=MHz, ohne Verstärkung muss er nicht rauscharm
> e.t.c. sein!) . Etwas besser wäre es die OPA-Versorgung vor dem
> 3,3V-Regler abzunehmen und mit R-C-Filter die Digitalstörungen heraus zu
> filtern. Bei höherer (>5V) Betriebsspannung kann man mit
> R-Zehnerdiode-Siebung auf 5V herunter setzen, parallel noch 100nF.
>
>> Bringt das Dithering überhaupt hörbar was?
> Bei meinem Sinusgenerator war der Unterschied bei tiefen Frequenzen
> deutlich hörbar. Mit Musik habe ich da leider noch keine Erfahrung,
> außerdem habe ich die Kombination mit deinem lineares Oversampling nicht
> ausprobiert..

> Diese Seite finde ich besser:
> http://www.beis.de/Elektronik/Filter/ActiveLPFilter.html
>
> Sallen-Key-Topologie(V=1) ist etwas weniger anfällig für Veränderung der
> Werte (Rechenwerte -> Normreihen) und braucht einen Widerstand weniger.

Danke erstmal. Die Seite ist gut :). OK es gibt also verschiedene 
Schaltungen. Lese auch gerade in dem OpAmps for Everyone Buch von TI. 
Bin jetzt im Filter Kapitel (damit wird einiges klarer ;)... Diese 
Filtertypen (Tscherbi, Bessel, usw.) sind also nur verschiedene 
Koeffizienten...

Nun frage ich mich gerade welche Kondensatoren ich für die Filter nehmen 
soll (Reichelt). Kann ich da ganz einfach in meine Sortimenbox für SMD 
Kerkos greifen? Es kommt ja wohl auf die Toleranzen an? Du schreibtst 
Kerkos gehen. Den Klang werden Diese hoffentlich nicht verfälschen.

Die gleiche Frage für die Koppelkondensatoren (du schreibtst 1uF). Habe 
irgendwo gelesen dass man dafür MKP-Typen nehmen sollte. Einer würde 
dann 3€ kosten :(. Wenn auch Kerko oder MKS-Typen gehen, wärs günstiger. 
Ich frage mich obs wirklich einen höhrbaren Unterschied macht 
(Verzerrungen, etc.), oder ob hier wieder die Hifi-Propaganda-Mafia am 
Werk ist?

Wenn ich das dann weis, kann ich endlich die Bestellung abschicken... :)

Hallo Kai,
hast du eine neue Version von dem Code aus deinem ersten Post?

Mfg,
Kurt