Hallo,
ich habe ein eigenartiges Problem, für das ich keine richtige Lösung
weiß:
Ich habe einen ESP32 (WROOM-32), der eine Audiodatei von SD liest und
diese mit einem MAX98357 ausgibt. Funktioniert wunderbar, bis zu
Sampleraten von 44.1 kHz. Ab 48 kHz fängt es an, dass der Ton kleine
"Knackser" in der Wiedergabe bekommt. Als würde der Chip kurz skippen
oder so. Bei 96 kHz, die der MAX98357 ja eigentlich können soll, ist es
absolut katatrophal.
Ich hatte die Sache bei 48 kHz halbwegs in den Griff bekommen, indem ich
die APLL des ESP32 benutze. Jetzt ist die Frequenz stabil, die
Logiklevel sind korrekt und es passt auch alles zu 16 bit Daten, aber 96
kHz gehen immer noch nicht, obwohl das alles noch weit entfernt davon
ist, was der ESP32 können soll:
CLK= 2 Kanäle 16 bit 96 kHz = 3.072 MHz.
Zuerst dachte ich an Buffer underruns oder dass die SD nicht hinterher
kommt. Das scheint es aber nicht zu sein. Ich sehe in den Signalen
keinerlei Auffälligkeiten...
Hat jemand eine Idee, was das Problem ist? Hier der relevante Code:
MiTo schrieb:> die Logiklevel sind korrekt
Du hast die Pegel und die Flanken und das Timing aber schon so nah wie
möglich am MAX gemessen? Passen die gemessenen Werte zu den
Anforderungen im Datenblatt?
> Ab 48 kHz fängt es an, dass der Ton kleine "Knackser" in der Wiedergabe> bekommt. Als würde der Chip kurz skippen oder so.
Der DA-Wandler kann nicht "skippen", der hat ja nicht mal einen Buffer.
> Zuerst dachte ich an Buffer underruns oder dass die SD nicht hinterher> kommt. Das scheint es aber nicht zu sein.
Wie kommst du auf diesen Schein? Wie hast du die SD auf
unterbrechungsfreie Übertragung getestet? Greift zwischendurch noch
irgendwer auf die SD zu?
Mein Tipp: "Divide et impera!" --> teile das Problem in kleine
Teilaufgaben.
Berechne doch einfach mal einen Sinus oder einen Sägezahn ins RAM des µC
und gib den als Dauerton aus. Dann misst du mit dem Oszi, ob da was
zuckt oder ruckt.
Wenn das Geknackse anders (nicht unbedingt besser) wird, wenn du einen
47p-C gegen GND versuchsweise an die Signale hängst, hast du ein Timing-
und/oder Signalintegritätsproblem. Da wäre evtl. eine
47R-Serienterminierung in alle Signale zum DAC hilfreich.
dma_buf_len = 64 bedeutet alle 64 samples ein DMA interrupt bei 96kHz
heist das alle 666µs ein Interrupt für den DMA und ein neuer Puffer
fällig. Kann man machen, ist aber suboptimal.
Ich denke mal Du hast ein Problem mit dem Befüllen der DMA Puffer. Wenn
die leer laufen kommt nur noch Mist raus. SDs sind undeterministisch die
machen Wear-Leveling, auch beim Lesen. Das kann dreistellige
Millisekunden blockieren.
Ich würde lieber weniger Puffer, dafür größere nehmen. Einzelner Puffer
sollte wenigstens 4k (=1024 Stereo-Samples) groß sein, das entspricht
dann der internen Sektorgröße von modernen SD Karten. 1024 Samples sind
10ms bei 96kHz. Bei SD würde ich mal für mindestens 100ms Puffer
vorsehen. 8x1024 Samples, besser 4x2048 Samples oder gar 8x2048, das
senkt die Interruptlast. Evtl klapts auch shcon mit 4x1024 ganz gut.
Danke für die Tipps! Das erste Problem was ich jetzt gefunden habe, war,
dass die Clock der SD-Karte viel zu niedrig war. Im Prinzip trat das
Problem dann auf, wenn die Clock des I2S der Clock der SD-Karte nahekam
- logisch. Man kann die Daten schließlich nicht schneller lesen als man
sie schreiben kann.
Jetzt schau ich mal weiter, wie hoch ich die Samplerate bei ordentlicher
Tonqualität bekomme...
Nein. Das ist ein weiteres Problem, was ebenfalls ein Problem ist. Ich
bin gerade dabei herauszufinden, was die korrekte Konfiguration ist...
Aktuell spielt er damit nur jedes zweite Sample, so dass alles doppelten
Pitch hat (4 kHz Ton --> 8 kHz)
