mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mp3 Wiedergabe - Jitter.. sinnvoller Code?


Autor: Manuel Fegerl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo euch allen :)

Ich stehe vor dem folgenden Problem:

Mein MP3-Player (mit AT89C51SND1C) funktioniert mittlerweile ganz gut..
er gibt MP3-Dateien von einer FAT32-formatierten Festplatte aus und man
hört das am Audioausgang.. so wie sichs gehört :)

Leider treten regelmäßig Jitter auf.. es scheint nun so dass einfach
der Datenstream nicht schnell genug ist.. vor allem beim wechsel des
Clusters.

Derzeit funktioniert das ganze so:
MP3-Interrupt -> Buffer von 512 Byte wird aufgebraucht, wenn leer ->
Buffer von der HDD neu aufgefüllt.. das geht scheinbar schnell genug,
solange man sich im selben Cluster befindet.

Muss ein neuer Cluster errechnet werden, scheint es so als wäre der
FAT32 Code etwas zu lange, wodurch dies etwas zu lange dauert.. es
entsteht ein Jitter (Kurzes Störgeräusch.. etwa alle 2-3s, was in etwa
einem Cluster entspricht).

Nun bin ich auf der Suche nach einer Lösung für dieses Problem.. die
Lösung die mir als erstes einfiel funktioniert leider nicht

(Da der MP3-Player ansich nur über die Interrupts funktioniert, könnte
man über das Hauptprogramm die neuen Clusternummern quasi
vorberechnen.. dies funktioniert jedoch leider nicht, da in der
berechnung auch Festplattenzugriffe sind, d.h. sie würden sich mit dem
MP3-Dekoder (sobald dieser wieder aktiv werden will) überschneiden..)

Bin gespannt was euch dazu einfällt.. vielen Dank schon einmal :)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Du willst double-buffering verwenden. D.h. du hast zwei Buffer. Einer
wird immer befüllt während der andere abgespielt wird.

Matthias

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Liest du vor dem neuen Cluster erst die FAT von der Festplatte ?
Dieser abwechselnde Zugriff leert vermutlich den Puffer der Festplatte,
so dass diese immer zwischen beiden Stellen hin und her springen muss,
was einige ms dauern kann.
Abhilfe: Viel SRAM verwenden, und einen Teil der FAT da
zwischenspeichern. Wenn die Festplatte nicht, oder nur gering
fragmentiert ist, funktioniert das super.

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach ein zusätzliches SRAM an den Controller und dann dem Decoder
einen ausreichend großen Buffer spendieren, 16kB Buffer sollten da
schon reichen. Der Interrupt der den Decoder fütter bedient sich nur
aus diesem Buffer. Der Buffer wird dann regelmäßig aus der Mainloop
heraus gefüttert. Das hat den Vorteil, das keine Festplattenzugriffe
aus einem Interrupt heraus geschehen, die sich dann mit andern in die
Quere kommen könnten (z.B. wenn man ein neues Lied auf der Festplatte
sucht, während eines im Hintergrund abgespielt wird)
Ein 16kB großer Buffer reicht im Worstcase (320kbps) 0,4s lang. Wenn du
einen einigermaßen vernünftigen Code hast, der an keiner Stelle blockt,
wenn zum Beispiel auf eine Eingabe gewartet wird, sollte das locker
reichen.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich stimme da ape zu, am besten einen großen Ringbuffer der immer in
Happen von 512 Bytes gefüllt wird. Wenn du den Buffer zb. 8Kb groß
machst so hast du 16 solcher 512 Bytes Blöcke. Du kannst also 15 Buffer
schon im vorhinein laden. Desweiteren meine ich auch das der MP3 Dekoder
über Interupts gefüttert werden muß. Der Buffer wird aber in der
Mainloop deiner Anwendung befüllt, durch Polling wenn der nächste 512
Bytes Abspiel-Buffer fertig ist. Das hat, wie Ape schon sagte, den
Vorteil das die ISR ungestört arbeiten kann.

Gruß Hagen

Autor: Manuel Fegerl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt: ja genau.. das dürfte das problem sein

Die Idee mit dem zusätzlichen Ram ist ansich gut, leider jedoch nicht
verwirklichbar.. Die Hardware ist soweit fertig und soll nicht mehr
verändert werden.. außerdem gibts keine freien Ports die verwendet
werden könnten..

1,5K XRAM habe ich in etwa zur verfügung (entspricht 3 sektoren).. also
leider nicht sehr viel

ich könnte also eventuell diese 1,5k als ringspeicher mit 3 sektoren
verwenden.. sobald ein sektor komplett gelesen wurde, könnte das
hauptprogramm nachschub anfordern... fraglich jedoch ob dies sinnvoll
ist?

eine andere möglichkeit wäre, dass ich die clusternummern schon im
vorraus herausfinde und zwischenspeichere.. jede clusternummer ist 4
byte groß, somit sollten sich einige in 1,5k ausgehen..

wie seht ihr das?

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du machst es jetzt so das du nur einen Buffer hast. Ist der komplett
abgespielt lädst du erst von der FAT die nächsten Daten in diesen
Buffer nach, richtig ?

Baue 2 Buffer, sobald der 1. Buffer abgespielt wird lädst du in den 2.
Buffer die nächsten Daten. Danach Buffer 2 abspielen und in Buffer 1
die Daten laden.

Das sollte auf alle Fälle besser als deine jetzige Methode arbeiten
(falls ich dich richtig verstanden habe)

Gruß hagen

Autor: Manuel Fegerl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, diese idee kam mir auch schon..

ich füllte dafür 2 buffer zunächst voll an.. sobald der erste gelesen
ist wird er neu aufgefüllt...

jedoch funktionierte das nicht einwandfrei.. mir ist noch unklar
wieso.. werd das nocheinmal verfolgen

Autor: Manuel Fegerl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm.. das ganze erweist sich als recht schwierig für mich...

Bislang funktioniert das ganze nicht so wie ich mir das vorstelle..
vielleicht hat wer nen denkansatz für mich..

Ich machs derzeit so:

Die Funktion die daten vom IDE-Bus bringt alterniert automatisch
zwischen Buffer[0] und [1]. Bevor der MP3-Dekoder aktiviert wird, wird
diese 2x geladen, um so beide Buffer einmal anzufüllen.

Zusätzlich exisitieren die Hilfs-bits "needsector" und
"readfrombuffer"

wird nun ein Buffer komplett gelesen wird needsector auf 1 gesetzt.
Außerdem wird readfrombuffer getoggelt, und die feldvariable (die auf
das gewünschte byte zeigt auf 0 zurückgesetzt).

Das Hauptprogramm prüft laufend ob needsector=1 ist, und falls ja
startet es die IDE-Daten-Funktion um somit den Buffer neu aufzufüllen..
anschließend wird needsector wieder 0.

Für den Notfall: sobald die MP3-Funktion erkennt dass der bytezähler
größer als 400 ist, wärend gleichzeitig needsector immer noch auf 1
ist, wird der mp3-dec-interrupt disabled, und mit break; abgebrochen..
sollte somit also im hauptprogramm weitermachen, welches nachdem der
nächste sektor gelesen wurde, den mp3-decoder wieder aktiviert.

Leider funktioniert das ganze so nicht :(

Da ich über keine direkte debugfunktion am Chip verfüge ist das ganze
schwer zu erfassen.. ich kann mir also nur hin und wieder informationen
am display ausgeben.. diese haben folgendes gezeigt:

Beim Abbruch ist needsector = 0
Der Abbruch erfolgt bei Byte 509 eines Sektors.. also mittendrin
9 erfolgreiche Datenanforderungen wurden durchgeführt bevor der Crash
passiert

Thx für Tipps.. vielleicht weiß ja jemand überhaupt eine elegantere
methode

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.