Grüezi miteinander ! Wie Andreas seinerzeit ja so richtig bemerkt hat, muss jeder aufrechte Elektrobastler mal einen MP3 Player bauen. Da ich es mit dem Löten nicht so sehr habe (ich weiss zwar, wo vorne ist, aber altersbedingt wird mir das kleine Fuzzelzeug mit ständig schrumpfender Baugröße schon eher lästig) suche ich nach fertiger, möglichst gut passender Hardware. Ich denke an einen schnellen Cortex (100-120 MHz), der dann auch gerade so im Stande sein sollte (hoffe ich), zwei 320kbit Stereo Streams parallel zu dekodieren (um Überblenden zu ermöglichen)und (mikro) SDXC Karten Slot(s) dazu ein ordentlicher D/A Wandler via I2S (Wolfson ?) und sowohl Line Out, optisch und oder SPDIF sowie irgend ein TDA xxx IC im Bereich 2*5 bis 10 Watt , einfaches Alpha-Display und IR Empfänger Mit Interesse habe ich den Thread zum Pollin Modul gelesen Beitrag "Stereo-Verstärkermodul mit MP3-Wiedergabe bei Pollin" Das ist schon ganz nett, aber jede Menge Dreck im Ausgang. Auch das Lesen der SD Karte kann man leider recht gut hören, speziell bei FAT Zugriffen. Auch gibt es eine unglaubliche Zahl an Modulen bei ebay und Alibaba, wenn man nur nach "MP3 decoder board" sucht einige davon sind wirklich nett und als "Küchenradio" etc sicherlich brauchbar (ich hab inzwischen ein ganzes Nest vor mir liegen ;) aber es fehlt halt immer an irgendwas. Also: kennt irgendwer passende Hardware oder baut vielleicht gerade jemand an etwas Ähnlichem? Ich würde mich da gerne dranhängen. Im Prinzip vergleichbar zum Beispiel dem Code Red RDB4078, nur eben ganz erheblich abgespeckt und angepasst Danke für Tipps
Wennes grob willst, dann eben AVR in DIL und dazu nen VS1011 in SOIP (gröberes SMD): http://www.reichelt.de/VS-1011E-S/3/index.html?&ACTION=3&LA=446&ARTICLE=54522&artnr=VS+1011E-S&SEARCH=vs1011 Soll MP3 in Software dekodiert werden (und das eben 2Mal). Dann guck mal nach den STM32 Discovery Kits. Da haste dann alles drauf und es gucken 2,54mm Stiftleisten raus. Nur eben die DACs gibts nur in fitzeligen TSSOP Gehäusen. http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f429idiscovery.html Haste gleich nochn Display drauf für den ID3Tag. Zum Software MP3 decoden guck mal nach "miniMP3" Da hat mal jemand die MP3 LIb aus nem Mediaplayer auf eine c Datei runtergedampft.
:
Bearbeitet durch User
Schau mal nach dem STM32F7 Discovery, das hat alles was du brauchst. Der uC sollte genug Leistung haben um MP3 in Software zu dekodieren. SD Slot sogar mit SDIO Anbindung, 8 MB RAM, und Klinke Buchse sind onboard. Nebenbei hat's noch ein schickes Display zur Bedienung.
> Ich denke an einen schnellen Cortex (100-120 MHz), der dann auch gerade > so im Stande sein sollte (hoffe ich), zwei 320kbit Stereo Streams > parallel zu dekodieren (um Überblenden zu ermöglichen)und (mikro) SDXC > Karten Slot(s) Dafuer reicht die Leistung nicht. Ich mache hier die Dekodierung in Software mit einem SH2A mit 130Mhz. Ohne eingeschalteten Cache schafft der 320kbit gerade so nicht, 256kbit geht. Mit aktiviertem Cache hat er da kein Problem. Da der SH7264 speziell als Multimediaprozessor gedacht ist wird ein ARM dem bei gleicher Taktfrequenz vermutlich nicht das Wasser reichen. (z.B DMA auf Dualportram ohne Waitstate) Daher denke ich das zwei 320er Streams gleichzeitig nicht funktionieren. Mit anderen Worten du brauchst ein fetteren ARM. Wenn du fertig kaufen willst dann ist es vermutlich am einfachsten du kaufst dir einen Rhasberry PI mit einer extra Soundkarte. Da gibt es doch auch etwas. http://www.elektronikpraxis.vogel.de/embedded-computing/articles/445797/ Olaf
Waldesruh schrieb: > Ich denke an einen schnellen Cortex (100-120 MHz), der dann auch gerade > so im Stande sein sollte (hoffe ich), zwei 320kbit Stereo Streams > parallel zu dekodieren (um Überblenden zu ermöglichen)und (mikro) SDXC > Karten Slot(s) Nix. Der ist nicht schneller als ein 486/100, und letzterer schafft einen MP3 Stream grade so mit Ach und Krach. Bei STM32 Discovery würde ich nur bei der hoch getakteten Cortex M7 Variante eine reelle Chance sehen. Waldesruh schrieb: > irgend ein TDA xxx IC im Bereich 2*5 > bis 10 Watt Wenn Du 10W für den Lautsprecher übrig hast, dann nimm lieber einen Raspberry Pi für 1-2 Watt als CPU.
Also auf nem Coertex-A9 667MHz (ZYNQ 7010) mit Linux drauf und dem besagten "miniMP3" braucht es 10% CPU Last und dabei war die I2S Ausgabe selber geknüppelt und eher nen Hack.
Mw E. schrieb: > Also auf nem Coertex-A9 667MHz (ZYNQ 7010) mit Linux drauf und dem > besagten "miniMP3" braucht es 10% Also 66MHz auf einem optimierten ARM Code mit Caches, oder 133 MHz für 2 Streams. Nur: Cortex M3 und M4 hat keinen Cache und kann nur Thumb2. Und weil man die Streams auch noch zusammen mixen muss wird da 150 MHz wohl eher knapp... BTW: Einige Raspberry Pi können mit I²S nachgerüstet werden.
:
Bearbeitet durch User
Jim M. schrieb: > BTW: Einige Raspberry Pi können mit I²S nachgerüstet werden. Soweit ich weis ging das nur beim ersten rasPI nicht. Bei allen anderen liegen die I2S Sgnale auf dem 40pol Header. Der miniMP3 Code ist nicht ARM optimiert ;) Der läuft mit demselben makefile auf x86/ARM/MIPS Linux. Bare Metal funktioniert der auch wenn man ihm direkt die MP3 Frames gibt. Im Beiepislcode besorgt er sich diese selber per mmap() Aber ja die fehlenden Cahces dürften da weh tun. Hab ja noch glatt den Link zu miniMP3 vergessen bisher: http://keyj.emphy.de/minimp3/
Das "alte" STM32F4 Discovery mit dem STM32F407VGT6 (geht bis 168 MHz) kann das möglicherweise schaffen. Les' mal hier: Beitrag "STM32F4 Discovery MP3 Player - komplett mit Code". Wenn man sich die Mühe machen würde, die MP3 Decodierung mittels der F4 DSP Befehle zu optimieren, würde das wohl ganz sicher klappen. Infos zum STM32F4 Discovery dazu: http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series/stm32f407-417/stm32f407vg.html Kaufen kann man es noch da: http://shop.mymcu.de/index.php?sp=article.sp.php&artID=200072 Aber wenn du zwei Stereo-Kanäle gleichzeitig decodieren willst (warum eigentlich?) brauchst du ja auch einen zweiten Codec. An Board ist nur einer! SD-Karten-Slot müsste man auch nachrüsten.
Jim M. schrieb: > Nix. Der ist nicht schneller als ein 486/100, und letzterer schafft > einen MP3 Stream grade so mit Ach und Krach. Die MP3 Decoder "damals" benutzten alle eine FPU. IMHO (weiß es leider nicht mehr genau) konnte die i486 FPU (also i487) keine single cycle FMUL Instruktionen. IMHO konnte die erst der Pentium. Das würde erklären, warum ein 60-70 MHz Cortex-M4 einen i486-100 in die Tasche steckt. IMHO hatte der i486-DX100 auch nur einen 33 MHz Bus, also RAM Anbindung. Ok, die Caches dürften da wieder was weg machen.
> Aber wenn du zwei Stereo-Kanäle gleichzeitig decodieren willst (warum > eigentlich?) brauchst du ja auch einen zweiten Codec. An Board ist nur > einer! Er koennte ja auch zwei Kanaele dekodieren und dann in Software mischen/ueberblenden und danach ausgeben. (warum auch immer) Die Frage ist allerdings ob irgendwelche ST-Demoboards mit Codec an Board ueberhaubt sorgfaeltig genug designt sind. Jemand der bewusst 320kbit dekodieren will wird da hoehere Ansprueche haben. Ich verwende im uebrigen den PCM3060 auf einem externen Codecboard. Damit bin ich klanglich zufrieden. Aber sowas kann man natuerlich nicht fertig kaufen. Olaf
Olaf schrieb: > Die Frage ist allerdings ob irgendwelche ST-Demoboards mit Codec an Board > ueberhaubt sorgfaeltig genug designt sind. Diese Frage stellt sich erst, wenn die Software läuft. Dann kann er immer noch vom 16-Bit-On-Board DAC auf einen hochwertigeren externen 20-Bit-DAC gehen. Ich würde auf jeden Fall mit dem on-board-DAC anfangen, denn dafür gibt es Beispielcode.
Wie ihr auch immer auf so utopische Zahlen kommt. So viel Leistung braucht man bei Weitem nicht für MP3! https://www.helixcommunity.org/projects/datatype/Mp3dec Der STM32F4 kann eher mindestens 3-4 Stereo MP3s bei 320kbit/s dekodieren. Und das auch ohne externen Ram.
> Wie ihr auch immer auf so utopische Zahlen kommt. So viel Leistung > braucht man bei Weitem nicht für MP3! Die Frage ist natuerlich auch was man vergleicht. Ich bin von libmad ausgegangen. Zu Helix kann ich nichts sagen. > Und das auch ohne externen Ram. Da waere ich vorsichtig. Ich hab zwar 1MByte internes Ram und das ist sicher uebertrieben fuer MP3. Aber nach meinen Erfahrungen sollten man schon so 64-100kbyte haben. Einfach weil manche SD-Karten schonmal kurz mit der Datenanlieferung stocken. Olaf
Olaf schrieb: > Da waere ich vorsichtig. Ich hab zwar 1MByte internes Ram und das ist > sicher uebertrieben fuer MP3. Aber nach meinen Erfahrungen sollten man > schon so 64-100kbyte haben. Einfach weil manche SD-Karten schonmal kurz > mit der Datenanlieferung stocken. Das ist natürlich richtig. Sobald man SD-Karten nutzt, sollte man schon eine Sekunde überbrücken können. Ich habe mich in dem Post nur auf die MP3-Dekodierung bezogen.
Toll. Eure Beteiligung ist prima, Danke ! 1) das mit den zwei Streams parallel (und dann auch noch 320kbit) ist ein "hätte ich halt gerne nice to have" meine neueren MP3 sind halt alle 320 und zum (optionalen) Überblenden braucht es dann deren zwei 2) mehr RAM (möglichst fliederfarbenes selbstverständlich) könnte natürlich den Überblendstress auch helfen mit zu lindern, indem ich da jeweils ein paar Sekunden des nächsten Liedes vorfabriziere, wann immer in der Haupttask Zeit ist 3) Tja, der Pi. Da war ich natürlich auch schon im Geiste. Und dass es da auch I2S Karten gibt ... wusste ich auch. a) Wo pack ich denn da die Musik hin, ich dachte, auf der SD-Karte wäre das System ... (und nein, es soll definitiv ein OFFLINE Projekt sein, ohne Netzschnickschnack. Davon hab ich schon zu viel) b) Wie lang bootet denn eigentlich so ein Teil bis es losdudelen könnte c) Pi-Batteriebetrieb ?!? Ich hatte Stromverbrauch nicht angegeben, aber so ein Teil in einem portablen Gehäuse wäre wohl auch sehr nett. Und nett wäre es gewesen, das Board wäre unter 50 EUR zu haben. Das wird mit Pi und Piggy auch schwierig. (Will von den Dingern etwa zwei Dutzend verschenken, wenn eines Tages fertich ...)
> a) Wo pack ich denn da die Musik hin, ich dachte, auf der SD-Karte wäre > das System ... Du koenntest die Musik auf einem USB-Stick haben. Oder einen USB-SD-Kartenreader anstecken. Und natuerlich koennte man auf der Systemkarte auch noch viele GByte fuer MP3s nutzen. > b) Wie lang bootet denn eigentlich so ein Teil bis es losdudelen könnte Ich hab noch nicht auf die Uhr geschaut. Aber so gefuehlte 10-20s. Das ist dann der Nachteil der Bequemlichkeit. Aber falls du dich als Programmierer zu hoeherem Berufen fuehlst kannst du auch auf Linux verzichten und den nackten Prozessor programmieren. Aber sicher ist das ein Punkt wo ein Controller mit integriertem Flashram und einer speziellen Firmware ueberlegen ist. > c) Pi-Batteriebetrieb ?!? Eher nicht. Aber das ist auch eine neue Forderung. > Ich hatte Stromverbrauch nicht angegeben, aber so ein Teil in einem > portablen Gehäuse wäre wohl auch sehr nett. Klar, aber du kommst da irgendwann in Bereiche wo es wirklich sehr viel klueger ist du kaufst dir einfach einen MP3-Player. Wenn es dir nur ums programmieren geht dann kauf dir einen Player auf dem Rockbox laeuft und modifiziere das nach deinen Wuenschen. > Und nett wäre es gewesen, das Board wäre unter 50 EUR zu haben. Das wird > mit Pi und Piggy auch schwierig. Das geht niemals. Rechne nur mal zusammen was Gehaeuse, Display, Schalter und anderer Kleinkram kostet. Wenn du Geld sparen willst dann fertig kaufen. Olaf
@Olaf Klar ist der Preis ehrgeizig. Aber "eigentlich" müsste man da schon hinkommen können ich meinte nur das nackte Board, auch ohne Karte, ganz zu schweigen vom Gehäuse. Allein die 64 Bit SD Karte ist ein netter Kostenfaktor...
@olaf eigentlich müsste zweilagig reichen Alternativ: ein baseboard unter so ein STM EVA Board,das könnte es sein ...
Olaf schrieb: > Das geht niemals. PiZero. Wäre ein Kompromiss. Ist definitiv schnell genug fürs dekodieren. Braucht auch nicht so viel Energie wie ein RasPi 1,2,3... RAM zum Puffern ist genug da, auch eine USB Schnittstelle um einen Stick anzuschließen. Programmieren dürfte viel schneller gehen als mit einem µC. Ein paar Zeilen python code... Mein PiZero hat 8 Pfund gekostet. Ist auch grad' lieferbar: https://thepihut.com/products/raspberry-pi-zero?variant=14062715972 Wenn du aus dem Bootvorgang alles rausschmeißest, was du nicht brauchst, dürftest du deutlich unter 10s kommen. Wenn man Ahnung hat, bekommt man auch ein Readonly root System hin, dann gibts auch weniger Probleme mit korrupten SD-Karten. Nur eine DA-Wandler Karte wirst du brauchen... z.B. http://www.mikroe.com/add-on-boards/audio-voice/audio-codec-proto/ Gibts bei mouser, hier im Forum bei der Sammelbestellung mitbestellen!
Waldesruh schrieb: > Allein die 64 Bit SD Karte ist ein netter Kostenfaktor... Genau, die Sonderanfertigung. Wobei, den 64-Bit Chip könnte man auch in der Badewanne ätzen...
> PiZero. Wäre ein Kompromiss. Ja, das klingt nach einer guten Anwendung für das Dingen. > Wenn du aus dem Bootvorgang alles rausschmeißest, was du nicht > brauchst, dürftest du deutlich unter 10s kommen. Das Problem ist nur, man braucht für eine gute effiziente Konfiguration dann Linuxkenntnisse auf Gurulevel. Die hat nicht mehr jeder. :-D Olaf
Der STM32F4 Dicovery wäre schon eine geeignete Plattform, er hat sogar noch einen I2S Bus frei und der Onboard CS43F22 klingt ganz anständig. Nur leider hat er viel zu wenig RAM für die Playbuffer. Wenn man alle Arbeitsvariablen in den CC RAM (64kB) verlegt, hat er gerade mal 128kByte für die Audiopuffer, so das es mit SD Karte ruckelt. Viel besser geht es mit echten USB Sticks, die deutlich schnelleren Zugriff haben.
Waldesruh schrieb: > Und nett wäre es gewesen, das Board wäre unter 50 EUR zu haben. Das wird > mit Pi und Piggy auch schwierig. Olaf schrieb: > Das geht niemals. Rechne nur mal zusammen was Gehaeuse, Display, > Schalter und anderer Kleinkram kostet. Ambitioniert aber könnte gehen. Das STM32F4 Discovery kostet ja grademal 35€: http://www.voelkner.de/products/586320/STMicroelectronics-Entwicklungsboard-STM32F429I-DISCO.html Display ist schon drauf, Taster braucht man keine, da es auch Touch hat. Matthias S. schrieb: > Der STM32F4 Dicovery wäre schon eine geeignete Plattform, er hat sogar > noch einen I2S Bus frei und der Onboard CS43F22 klingt ganz anständig. > Nur leider hat er viel zu wenig RAM für die Playbuffer. Also das STM32F420 Discovery hat 64-Mbit SDRAM, das reicht locker ;) Auf dem Board ist der SAI_1 und der I2S_2 frei für nen DAC
Matthias S. schrieb: > Wenn man alle Arbeitsvariablen in den CC RAM (64kB) verlegt, hat er > gerade mal 128kByte für die Audiopuffer, so das es mit SD Karte ruckelt. Man puffert auch nicht den audiostream, sondern die mp3 Daten. Dafür braucht man deutlich weiniger speicher. Bei 2 Stereo Streams könnte es mit 32kB/Kanal gerade so gehen. Beim audiostream reicht es wenn man ein paar Millisekunden puffert. Natürlich muss man sich da ein paar mehr Gedanken machen, wenn man keine 8MB ram zu Verfügung hat.
@an Alle: zunächst mal wirklich herzlichen Dank. Ich schätze Euren Input echt sehr. Allein in der Bastelecke ist man eben manchmal doch eher leicht vernagelt, da hilft etwas externe Illumination erheblich. und dann, der Reihe nach... @2^5 (bist Du 32 oder watt ? also ich bin 0011 0111) ähm, ja genau. über die Jahrzehnte in diesem Business hab ich mir die Einheitenpräfixe irgendwie abgewöhnt Sind so volatil .... gemeint war natürlich GIGA ;) PiZero: in der Tat, das sieht interessant aus. Und der ist öfers nicht lieferbar ? Schlecht. Pi ist mir auf Grund seiner doch etwas verquasten Architektur so suspekt gewesen, dass ich bisher einen Bogen .... Das muss ich evtl ändern @Olaf >Linuxkenntnisse auf Gurulevel in der Tat, das dürfte eher nichttrivial sein Allerdings ist da ja eine riesen Menge Nutzer unterwegs ... Die Chance, dass sich da (ganz genau da!) schon mal einer versucht hat, ist ja immerhin gegeben. @Matthias Sch >das es mit SD Karte ruckelt. Viel besser geht es mit echten USB Sticks Dein Ernst ? Ist das eine Annahme oder erlebter Schmerz ? Also das wundert mich aber doch. Ich hab vor Jahren schon (War glaube ich mit einem M16C und einem frühen VLSI) schon in einem Kundenprojekt SD Karten direkt für MP3 Wiedergabe ausgelesen Allerdings waren das afair nie 320kbit Files, geschweige denn gleich zwei. (also 2*Stereo) Geruckelt hat es nie. Und ich hatte allenfalls einzelne Sektoren gepuffert (einer wird gelesen, einer wird gerade ausgegeben. Also nix besonderes) Wobei VLSI ja intern auch ne FIFO hat, weiss nur die Größe nimmer. Aber ich hab echt Schwierigkeiten zu glauben, dass ein Stick da wirklich schneller ist. Ist das so ? Allein wenn ich an den Overhead eines USB Stacks für Host denke.... @avr Also selbst wenn man auf das Überblenden verzichtete, eine gewisse Menge fertige Audiodaten im Puffer wird man doch bestimmt brauchen. Ich hab mich noch nicht im Detail mit I2S beschäftigt, aber ich nehme doch an, dass das via DMA "von selber" rauslaufen kann. Wird man sich wohl nur um den Takt kümmern müssen (44 oder 48 kHz Samplerate je nach File) @alle also nochmals Danke. Mir scheint, ich werde mir den Pi (widerstrebend) näher ansehen und dazu auch das STM Discovery Schade dass es von NXP da nix zu geben scheint, die fand ich insgesamt immer pflegeleichter (also zumindest bis M3)
ähm ... kann mir jemand diesen Preis erklären ? http://www.ebay.de/itm/361623155657 das wäre doch genau das korrekte Board.
Interessanter Preis, wohl vom LKW gefallen? Aber ja, wie ich bereits oben geschrieben habe, ist das dein ideales Bretterl ;)
> Also das wundert mich aber doch. > Ich hab vor Jahren schon (War glaube ich mit einem M16C und einem frühen > VLSI) Das Problem gab es im Prinzip schon immer. Wobei aber früher weniger auftrat und kleiner war. Ich kann bei meinem MP3 Player sehen das der Bufferfuellstand immer mal ein paar Prozent runter geht. Das haengt aber auch von der Karte ab. Ich koennte mir auch Karten vorstellen die das Problem garnicht haben. Besonders aktuelle Karten die auch fuer 4k Video geeignet sind muessen ja eine gewisse Mindestgeschwindigkeit garantieren. Olaf
Waldesruh schrieb: > Also selbst wenn man auf das Überblenden verzichtete, eine gewisse Menge > fertige Audiodaten im Puffer > wird man doch bestimmt brauchen. Ich hab mich noch nicht im Detail mit > I2S beschäftigt, > aber ich nehme doch an, dass das via DMA "von selber" rauslaufen kann. > Wird man sich wohl nur um den Takt kümmern müssen (44 oder 48 kHz > Samplerate je nach File) Für I²S braucht man quasi keinen Puffer. Puffern muss man nur was nicht in Echtzeit ablaufen kann, d.h. unter der Sampledauer. Dazu gehört die SD-Karte und der Dekoder. Bei der SD-Karte muss man am meisten Puffer, daher nimmt man dafür am besten die MP3-Daten. Nach dem Dekoder reichen auf einem µC ein paar MP3-Frames, im besten Fall zwei. Ein MP3-Frames hat ungefähr 1000 Samples. Der Audiopuffer beschränkt sich nach dem Dekoder also auf < 10 KB. Mit dem Raspberry PI musst du dir um solche Sachen natürlich keine Gedanken mehr machen.
Olaf schrieb: > Ich koennte mir auch Karten vorstellen die das > Problem garnicht haben. Besonders aktuelle Karten die auch fuer 4k Video > geeignet sind muessen ja eine gewisse Mindestgeschwindigkeit > garantieren. Mindestgeschwindigkeit != Latenz. Auch schnelle Karten können größere Latenzen haben und trotzdem, durch die hohe Busbandbreite, schnell sein.
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.