Hi! Ich möchte demnächst probieren, einen MP3-Player auf Basis eines AVR Controllers zu bauen. Dazu würde ich gerne wissen, welcher der heute verfügbaren Decoder der beste und am einfachsten zu bedienende mit brauchbarer Audio-Qualität ist. Wichtig wäre auch, daß er mir einen Timecode ausgeben kann, wie lange ein gespielter Titel bereits läuft. Andernfalls bliebe nur die Anzahl der gesendeten MP3-Pages und das wird bei VBR wohl problematisch. Als DIP wird es sowas wohl leider nicht geben, also mit Adapter-Platine... Welchen Speicher würdet ihr empfehlen? SD-Card über SPI? Der Decoder benötigt bestimmt auch SPI, oder? Das bedeutet, ich bräuchte einen Controller mit zwei SPI-Schnittstellen. Mal sehen ob der ATMega1284 das kann. Diesen bevorzuge ich im Moment wegen der 16kB RAM. Wer hat Erfahrungen mit sowas?
Wie wärs mit denen: http://www.rohm.com/web/global/search/parametric/-/search/Audio%20Processors/Car%20Audio/?node=1228&application=164&circuit=10545
Guck doch mal bei VLSI - zu den Chips von denen findest du auch schon ganze viele Projekte... Hab mit dem VS1011 auch schon viel gemacht, läuft echt Klasse das Teil... Zur Tonqualität kann ich dir allerdings nicht so viel sagen... Ich habs nur mit billigen Kopfhörern usw. getestet und brauchte ihn auch immer nur zur Sprachausgabe... Aber da es ja schon einige MP3-Player mit dem Chip gibt, kann er soooo schlecht nicht sein... Du brauchst aber nur ein SPI und zumindest beim VS1011 kannst du die Zeit auch selbst messen bzw. zählen... In den internen Speicher vom VS1011 passen eh nur ein paar Millisekunden - da kann man sich ja quasi nicht verzählen... ;-) In Sachen Speicher, würde ich bzw. habe ich nachher einen Flash Speicher am SPI verwendet und die MP3 Daten per CAN übertragen und gespeichert... Ich habs auch schon mal mit einer SD Karte aufgebaut gehabt, aber der Overhead für das Dateisystem war verdammt nervig und hat unheimlich viel Ram und Zeit gekostet... Ohne Dateisystem geht natürlich auch mit ner SD Karte - aber dann bleiben auch fast alle Vorteile davon auf der Strecke... Außerdem hat die SD Karte immer wieder mal Wackelkontakte gehabt im Auto... Je nachdem, wie es bei dir mit Erschütterungen aussieht, solltest du das bedenken...
magic smoke schrieb: > Wichtig wäre auch, daß er mir einen Timecode ausgeben kann, wie > lange ein gespielter Titel bereits läuft. Andernfalls bliebe nur die > Anzahl der gesendeten MP3-Pages und das wird bei VBR wohl problematisch. Es ist ja wohl mehr als trivial, für jeden an den Decoder ausgelieferten MP3-Frame die verwendete Bitrate zu ermitteln und den Scheiß entsprechend aufzuaddieren. Dazu muß man nur den grundsätzlichen Aufbau eines MP3-Frames kennen und einige wenige Bits daraus auswerten. Absolute Kinderkacke.
@ magic smoke (magic_smoke) >Dazu würde ich gerne wissen, welcher der heute verfügbaren Decoder der >beste und am einfachsten zu bedienende mit brauchbarer Audio-Qualität >ist. Ob es der beste ist weiß ich nicht, aber die Dinger von VLSI sind verbreitet und sehr gut. VS1011 kann ich empfehlen. > Wichtig wäre auch, daß er mir einen Timecode ausgeben kann, wie >lange ein gespielter Titel bereits läuft. Kann man über Register auslesen. >Welchen Speicher würdet ihr empfehlen? SD-Card über SPI? Kann man machen. > Der Decoder >benötigt bestimmt auch SPI, oder? Ja. > Das bedeutet, ich bräuchte einen >Controller mit zwei SPI-Schnittstellen. NEIN! Man kann problemlos mehrere ICs an EINEN SPI-Bus anschließen! > Mal sehen ob der ATMega1284 das >kann. Diesen bevorzuge ich im Moment wegen der 16kB RAM. Braucht man nicht. Da reicht 2-4k schon aus. ~1k geht für FATfs & Co drauf (SD-karte), für den MP3 Dekoder braucht man meist kaum zusätzlichen Puffer (haben die schon eingebaut).
@ c-hater (Gast) >Dazu muß man nur den grundsätzlichen Aufbau eines MP3-Frames kennen und >einige wenige Bits daraus auswerten. Absolute Kinderkacke. Jaja, unser Choleriker Nr. 2 mal wieder. Dass so eine Information DEUTLICH einfacher und SINNVOLLER vom MP3 Dekoder geliefert wird, darauf kommen wir heute wohl nicht?
c-hater schrieb: > Es ist ja wohl mehr als trivial, für jeden an den Decoder ausgelieferten > MP3-Frame die verwendete Bitrate zu ermitteln und den Scheiß > entsprechend aufzuaddieren. > > Dazu muß man nur den grundsätzlichen Aufbau eines MP3-Frames kennen und > einige wenige Bits daraus auswerten. Absolute Kinderkacke. und du programmierst auch in Assembler?
Mampf, Falk, falls Verstärkung gebraucht wird: MPEG, WAV, MP3... In Assembler und C für DSPs, MIPS und ARM für Automotive CD und DVD Laufwerke. Ist schon eine Weile her, aber sollte alles noch im Regal hinter mir stehen. Was mich sehr stört ist nicht die Möglichkeit, dass da jemand Ahnung haben könnte, sondern die Art und Weise, welcher Ton benutzt wird, um diese womöglich vorhande Wissen anzupreisen. Ein typisches Phänomen unserer Zeit, die "Qualität" einer Aussage definiert sich über die "Lautstärke", nicht über ihren Inhalt. Für den TO mal was Sinnvolles und Hilfreiches: Ich habe mal einen Player auf Basis VLSI Chips entwickelt und dort aus Interesse auch mal den Timecode mit übermittelt, den der Chip dekodiert. Das sollte aus der Erinnerung passen. Exakt nachgemessen habe ich ihn aber nicht, da er bei dem Projekt keine Rolle spielte. Es gab aber zur Berechung der Abspielzeit eine Application Note von VLSI. Es gibt für den ATmega eine Library, die eine SD-Card auslesen kann, wenn sie mit FAT formatiert ist. Man kann dann einfach Dateien öffnen und in Blöcken a 512 Bytes auslesen. Auf einem ATmega32 hat man aber eigentlich nicht genug Platz um so viele Daten zwischen zu lagern, wenn man mit etwas Komfort durch die Dateien scrollen können will. Der VLSI will zudem etliche Bytes auf einen Schlag haben und signalisiert dann fortlaufend, wann der Puffer wieder mehr als 32 neue Bytes aufnehmen kann. Also habe ich noch folgenden Trick angewandt: Ich habe die SD und den VLSI an einem SPI und kann nun mit einem Logik-Gatter den SPI Daten Ausgang von der SD direkt auf den SPI Daten-Eingang vom VLSI schalten. SPI CLK und /CS werden an beide Chips angelegt. Dann muss der AVR nur noch Dummy-Bytes senden und die Daten werden direkt von SD nach VLSI übertragen. Das Dummy-Byte Erzeugen habe ich per SPI-Interrupt gemacht. Der muss ja nur mitzählen, bis Block-Ende erreicht ist. Das Blockende errechnet man einfach aus if (Datei_Rest > 512) block = 512 else block = Datei_Rest; Der VLSI unterscheidet nach Control und Data. Man kann also in der Zeit, in der keine Daten verschoben werden, und wo man gerade keine neuen Sektoren von der SD Karte "bereit legen" muss, auch mal den Timecode auslesen oder Lautstärke regeln oder ähnliches. Statt der FAT Library für den AVR, kann man auch den FTDI Vinculum einsetzen, ein Chip, der von USB-Sticks Daten entgegen nimmt und das ganze Dateisystem übernimmt. Trotzdem müsste man die Daten "zu Fuß" durch den AVR schleifen und das macht weder Sinn noch Spaß. Anders ist es, wenn Du auf Basis eines STM32F4 eine SD-Card direkt ansprichst und das MP3 Decoding mit einer der freien Libraries auf dem F4 direkt erledigst. Also keine weiteren Chips benutzt, die einen Teil der Arbeit bereits in Hardware erledigen. Aber auch die Decoder liefern bereits Time-Codes. hier hat man aber den Vorteil, dass man Audio-Frames zählen kann, die man z.B. per DMA an den DAC sendet. Da man die Sample-Rate kennt, ist das reine vorwärz Zählen kein Problem. Wenn man Skipping macht, vor oder zurück, wird es problematisch, gerade bei VBR. Aber Skipping ist in MP3 immer ein Problem, weil der Decoder eine Anlaufzeit hat, bis er wieder einen Ton produziert. Das wirst Du dann aber später merken. Gruß Ulrich
Hmm, ich werde auf jeden Fall den ATMega 1284 nehmen, einfach damit ich genug RAM habe wenn ich es brauche. Da zu sparen macht keinen Sinn und die paar Euro mehr gebe ich gerne dafür aus. Es geht darum, daß der Controller zu bestimmten vorher festgelegten Timecodes irgendwas (z.B. Pin an/aus) machen und dabei eine Genauigkeit von 0.1 bis 0.05s synchron zur Musik über den ganzen Titel hinweg erreichen soll. Klingt nicht nach viel, aber könnte noch knifflig werden. Darüber, die gesendeten Datenframes mitzuzählen hab ich natürlich auch nachgedacht, allerdings macht das spätestens bei VBR-Dateien Probleme. Ich weiß auch nicht, wie sich der Puffer des Decoders auf die Synchronität zur Musikausgabe verhält. Auf jeden Fall tritt da eine Verschiebung auf und ich weiß nicht, ob diese konstant ist. Falls ja, würde ich in Kauf nehmen, daß nur CBR-Dateien abgespielt werden und zu dieser mitzähl-Methode greifen, da ich dann die Verschiebung einfach herausrechnen kann. Wieviel Bytes puffert der VS1011 denn und "wieviel Musik-Spiellänge" entspricht das? Ich muß mir wahrscheinlich auch ein eigenes Dateiformat bauen, um die Timecode-Daten mit den MP3-Daten zu multiplexen oder ich lade die Timecode-Daten aus einer zweiten Datei. Da müßte ich aber recht viel ins RAM laden oder zwei Dateien gleichzeitig nutzen, multiplexen wäre wohl besser. Multiplexen heißt aber auch, ich muß alle Daten durch den Controller schleifen, was ich aber wahrscheinlich sowieso mache. Ich habe auch drüber nachgedacht, ein ganz einfaches eigenes Dateisystem zu bauen. Ordner usw. brauche ich auf dem "Laufwerk" nicht, nur ein minimales Verzeichnis zur Verwaltung der Dateien und Speicherorte. Lässt sich eine SD-Karte denn linear adressieren? Damit habe ich mich bislang noch nicht befasst. Ich hab auch kein Problem damit, die Dateien per RS232 vom PC auf den Player zu laden, die Zeit habe ich und sooo langsam ist RS232 ja nun wieder auch nicht. Wahrscheinlich wird es dann darauf hinauslaufen, daß SD-Karte und MP3 Decoder auf dem gleichen SPI-Bus laufen. Der ATMega hat nämlich nur einen Controller dafür. Danke euch auf jeden Fall erstmal für eure Tips. Hat jemand noch einen VS1011 mit Adapterplatine übrig?
magic smoke schrieb: > Wahrscheinlich wird es dann darauf hinauslaufen, daß SD-Karte und MP3 > Decoder auf dem gleichen SPI-Bus laufen. Der ATMega hat nämlich nur > einen Controller dafür. sollte auch mit usart-spi als 2. spi-bus gehen.
@ magic smoke (magic_smoke) >Timecodes irgendwas (z.B. Pin an/aus) machen und dabei eine Genauigkeit >von 0.1 bis 0.05s synchron zur Musik über den ganzen Titel hinweg Machbar, auch wenn der VS1011 nur ganze Sekunden signalisiert. Dazwischen muuss man halt per Timer die Zeit interpolieren. >herausrechnen kann. Wieviel Bytes puffert der VS1011 denn um die 2kB. >und "wieviel >Musik-Spiellänge" entspricht das? Kommt auf die Bitrate an. >Ich muß mir wahrscheinlich auch ein eigenes Dateiformat bauen, um die >Timecode-Daten mit den MP3-Daten zu multiplexen oder ich lade die >Ich habe auch drüber nachgedacht, ein ganz einfaches eigenes Dateisystem >zu bauen. Ordner usw. brauche ich auf dem "Laufwerk" nicht, nur ein Viel zuviel für den Anfang! Mach es erstmal einfach, spiele ein MP3 von SD-Karte ab! Nutze eine fertige FAT Bibliothek, FATfs von ELM Chan kann ich sehr empfehlen. >Wahrscheinlich wird es dann darauf hinauslaufen, daß SD-Karte und MP3 >Decoder auf dem gleichen SPI-Bus laufen. Kein Problem. Wenn dein AVR aber mit vollem 16 MHz Takt laufen soll, muss er mit 5V betrieben werden und du braucht für den SPI-Bus Pegelwandler auf 3,3V. 74HC4050 und 74HCT125 sind deine Freunde.
Also wenn Du wirklich so genaue Time-Codes brauchst, dann bau Dir das System auf einem STM32F4 Eval-Kit auf und mach das Decoding in Software. Das was Du jetzt mit dem ATmega machen willst, ist fast schon komplizierter, als es komplett auf einem dafür passenden Cortex in Software zu gießen. Wenn Du Dir www.ethernut.de ansiehst, das bietet eigentlich alles was Du benötigst, also Cortex, MP3-Decoder, Dateisystem... Du musst die vorhandene Software nur noch so modifizieren, dass es Dir die Audio-Samples zählt und daraus einen Time-Code zurecht baut. Aus einer VBR den realen Timecode zu errechnen ist nicht einfach und wird vermutlich den AVR ohnehin überfordern, gerade wenn er parallel noch die Daten von A nach B pumpen muss. Gruß Ulrich
@ Ulrich P. (uprinz) >Also wenn Du wirklich so genaue Time-Codes brauchst, dann bau Dir das >System auf einem STM32F4 Eval-Kit auf und mach das Decoding in Software. Würde ich nicht so sehen. Was hindert denn den OP, in einem 10 oder 50ms Interrupt den Timecode aus dem MP3 Dekoder auszulesen und darauf seine innere Uhr zu synchronisieren? Die restliche Ansteuerung eines VS1011 ist praktisch trivial.
Naja, die Spec vom VS1011e hat als einzige Angabe ein Sekunden-Register. Man müsste sich also wirklich an den Sekunden-Sprung heran-samplen mit schnellen Abfragen. Laut der Anfrage vom TO ist ihm die genaue Zeit innerhalb der Datei sehr wichtig. An sonsten, da gebe ich Falk recht, ist die Ansteuerung der VLSI Serie von Chips absolut trivial.
Nachtrag: Vielleicht sollte man sich mal den VS1005 ansehen, der kann einiges mehr. U.A. hat er gleich ein SD-Card Interface und Ethernet... Schick! Da könnte man den AVR wirklich als reinen Controller verwenden, damit man sich nicht das SDK von CLSI installieren muss um den DSP selbst zu programmieren.
Ohne selbst damit gearbeitet zu haben, bin ich nicht sicher, ob sich der VS1005 als Slave-Controller an einem Atmel als Master eignet. Ich habe das immer so verstanden, daß dieses schöne und leider hier nur schwer erhältliche Teil User-Applikationen unter einem herstellereigenen RTOS ausführt, im Gegensatz zu seinen kleinen Verwandten. Man kann übrigens einem VS1053 oder VS1000 genug "Eigenintelligenz" für einen Stand-Alone-Betrieb ohne weiteren Controller beibringen.
Falk Brunner schrieb im Beitrag #4111916: > Nö, den Zensurio Maximo hat ein anderer Spielverderber gespielt, ich bin > weder Admin noch Mod, kann also keine Beiträge löschen. Aber ich bin fast sicher: du kennst die Typen persönlich... Aber egal: Auch (oder gerade) wenn das nicht der Fall sein sollte, können wir uns ja gerne weiter über das Thema unterhalten, um welches es fachlich ging. Ich würde dich sogar darum bitten. Denn gerade das würde den Zensoren zeigen, daß Zensur SCHEISSE ist. Immer Scheisse war und immer Scheisse sein wird. Also fachlich: Deine Meinung war: Es ist Schwachsinn, den MP3-Frames die mit minimalem Aufwand erlangbaren Informationen über die verwendete Bitrate zu entnehmen, um die aktuelle zeitliche Position im File zu wissen. Deine Begründung war: jeder Decoder kann das selber viel besser und und man braucht ihn ja bloß dazu zu befragen. Ich hingegen behaupte: 1) Längst nicht jeder Decoder läßt sich überhaupt dazu befragen. 2) Es ist auch aus anderen Gründen sinnvoll, selber den Daten die Information zu entlocken, z.B. um eine korrekte Gesamt- oder Restzeit anzeigen zu können. So, nun deine Erwiderung... So funktionieren Diskussionen...
@ c-hater (Gast) Soll doch jeder nach seiner Facon glücklich werden. Wer der Meinung ist, per "Hand" die MP3 Frame auseinanderpflücken zu wollen, um die aktuelle Abspielzeit oder sonstwas zu extrahieren, na dann bitte schön. Ich würde es anders machen, aber das muss gar nichts heißen. Viel Spaß, ganz egal bei welcher Lösung.
c-hater, ich bitte Dich, noch einmal Deine immer noch unflätige Wortwahl in den Griff zu bekommen. Die Wortwahl wird auch durch Lautstärke (Fettschrift) nicht besser, richtiger oder inhaltsvoller. c-hater schrieb: > Ich hingegen behaupte: > > 1) > Längst nicht jeder Decoder läßt sich überhaupt dazu befragen. > Wir habe hier bereits Decoder vorgeschlagen, die dieses Feature haben, und wir haben festgestellt, dass diese ohne weitere Eingriffe nicht in der gewünschten Auflösung des TO ermöglichen. Wir haben Software-Lösungen und Verfahren vorgeschlagen, die zumindest die korrekte Ist-Zeit berechnen könnten. Deine Aussage ist also lediglich das herumreiten auf etwas, was ganz am Anfang bereits festgestellt wurde, Du schreibst aber keine Lösung. > 2) > Es ist auch aus anderen Gründen sinnvoll, selber den Daten die > Information zu entlocken, z.B. um eine korrekte Gesamt- oder Restzeit > anzeigen zu können. Wir haben auch dieses bereits vorgeschlagen. Wir sind uns aber nicht einig, ob der TO dazu in der Lage ist, das selber zu machen, auf einen dafür notwendigen Controller zu wechseln oder das VLSI eigene RTOS zu erlernen. Du hast diese Aussage auch bereits vorher getroffen und auch in der Wiederholung schreibst Du nicht, wie, wo und warum und vor allem nicht, welche andere Gründe denn eine händische Dekodierung der Frames erforderlich machen. Ich denke aber, dass wenn Leute mit einem zielführenden Wortschatz den TO dazu bringen, das ganze grundsätzlich mal ans Laufen zu bringen, dann kann man das Projekt auch Schritt für Schritt erweitern. Auch mit einem VLSI muss man schließlich wissen, was ein Header ist, wie man die Tags erkennt und deren Länge entschlüsselt. Sonst hat man lange Pausen am Anfang oder laute Störungen am Ende. Wenn der Aufbau des TO grundsätzlich erst einmal läuft, kann ich auch gerne Code-Schnipsel für MP3-Tags oder entsprechende Standards liefern. Aber alles nach der Reihe. Meinen Prototypen habe ich damals auf solch einen Adapter aufgelötet: http://www.reichelt.de/RE-471EP/3/index.html?&ACTION=3&LA=446&ARTICLE=50252&artnr=RE+471EP&SEARCH=SMD+adapter Dabei habe ich die Blockkondensatoren gleich auf dieser Platine mit verdrahtet, die Audio-Technik auf der darunter liegenden normalen Lochraster Platine. Hat gut funktioniert. Einen normalen SD-Slot kann man gut auf einer Lochraster-Platine unterbringen, oder solch einen Adapter nutzen http://www.reichelt.de/TEENSYSHD-WIZ820/3/index.html?&ACTION=3&LA=446&ARTICLE=152348&artnr=TEENSYSHD+WIZ820&SEARCH=SD+adapter Gruß Ulrich
Thread beobachten
Seitenaufteilung abschaltenBitte 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.