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
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.
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/
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!
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 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)
> 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.
