Mir kam vorhin die Idee, den Controller eines Eigenbau-MP3-Players zusätzlich für Lichtsteueraufgaben zu verwenden. Ich benötige dafür den Schaltplan eines möglichst erweiterungsfreundlichen MP3-Players auf Basis eines ATMega644 oder so, der seine Daten von einer SD-Karte bezieht. Wenn möglich brauch ich die Quelltexte für die SD-Karten-Operationen und die Versorgung des MP3-Decoders in Assembler, sorry, aber ich mag Assembler bei der µC-Programmierung. Wenns geht so viel wie möglich interruptgesteuert, damit man sich nicht groß um die Zugriffe auf die SD-Karte oder den MP3-Decoder kümmern braucht. Die Steuerdaten für das Licht könnte man in einem eigenen Dateiformat mit den MP3-Daten multiplexen und auf der SD-Karte ablegen. Der Controller macht dann das demuxen, sendet die MP3-Daten an den Decoder und verarbeitet die Lichtsteuerdaten selber. Die drei Timer ließen sich z.b. für drei 8bit-dimmerkanäle verwenden und etliche Pins des Controllers gehen bestimmt als ein/aus-Kanäle zu nutzen. Oder man überträgt die Lichtsteuerdaten per I2C oder so an einen zweiten µC, der die Lichtsteuerung übernimmt - diese Variante würde ich bevorzugen weil weniger Modifikationen am MP3-Player erforderlich sind. Soll auch kein Massenprodukt werden wo es sich lohnen würde den zweiten µC einzusparen. Als Controller schwebt mit der ATMega644 vor wegen der RAM-Größe, als MP3-Decoder der VS1001 oder VS1011 - je nachdem welcher besser ist. Meine Fragen an Leute, die sich mit dem VS1001 oder VS1011 auskennen: 1. Welchen von beiden ICs nehmen? Welcher bietet evtl. Vorteile? 2. Hat einer der beiden ICs Register womit man rauskriegen kann an welcher Stelle der Decoder gerade beim Abspielen ist? Ansonsten gibt es durch den Puffer des Decoders einen Zeitversatz zwischen gesendeten und abgespielten Daten, der evtl. schon im Licht-Timing bemerkt wird. 3. Wie konstant ist der Datenstrom zum Decoder bei einer MP3-Datei mit konstanter Bitrate? Ich strebe 192kbit/s als konstante Bitrate an. Der ATMega hat aber nicht viel RAM um viele Lichtsteuerdaten zu puffern, sodaß die Lichtsteuerdaten in der gemuxten Datei sehr nahe bei den abgespielten MP3-Daten liegen müssen. Soweit ich weiß bekommt der Decoder seine Daten ja immer in Form von Blöcken. Es erscheint mir sinnvoll, diese Blöcke einfach um eine Markierung zu erweitern ob dieser Block nur Audio-Daten enthält oder auch Lichtsteuerdaten. Also zwei Blocktypen, Audio plus Kein-Licht-Markierung und Audio plus Licht-Markierung plus Lichtdaten. Und mal sehen was Ihr von der Idee haltet....... :)
tschuldigung, ich vergaß zu erwähnen, daß auch SINNVOLLE ANTWORTEN erwünscht sind. mein fehler!
vielen dank leute... bin langsam auch dafür, daß gäste hier nicht mehr posten dürfen. gratulation - ihr habt es geschafft!
ähhh....wofür explizit "lichtsteuerdaten"? die daten hast du doch schon in form deines mp3files. damit ist das licht ja an höhen/tiefen des musikstücks gekoppelt. oder wolltest du mal eben das mp3format umschreiben um da für jeden song einzelne "lichtsteuerdaten" einzufriemeln?? bau erstmal nen mp3player der funktioniert...wenn du dann noch haare hast, dann ist die lichtgeschichte ein klacks :D
oder schwebte dir bei lichtsteuerung jetzt eher so etwas ala DMX vor?? dann ist es aber blödsinn, das in einem mp3 file codieren zu wollen
das ist ja der witz daran, aus dem MP3 player würde damit eine komplette programmablaufsteuerung. die daten die das ding dann braucht wären wie auch schon gesagt kein reines MP3 mehr sondern ein datenstrom in dem MP3 und lichtsteuerdaten gemultiplext vorliegen. quasi wie die audio/video-streams in den VOB-dateien von DVDs. klar, ne einfache lichtorgel dranadaptieren wäre das geringste problem, aber das reicht mir nicht. ich möchte gerne, daß das teil auch effekte wie strobos, ACL-spots oder nebelmaschinen steuern kann. DMX-512 wäre vom prinzip her auch denkbar, allerdings fallen dafür bestimmt mehr daten an als für das MP3. in erster linie brauch ich jemanden, der sich richtig gut mit dem VS1001 oder VS1011 auskennt... damit wäre mir schon einiges geholfen. und die SD-karten technik werde ich wohl brauchen um das ding mit daten zu füttern.
*nochmal hochschieb!* habe keine lust alles alleine zu bauen, hat keiner schon fertige ansätze hierfür? MP3-player in eigenbau müßte es doch schon viele geben!
Ben _ schrieb: > klar, ne einfache lichtorgel dranadaptieren wäre das geringste problem, > aber das reicht mir nicht. ich möchte gerne, daß das teil auch effekte > wie strobos, ACL-spots oder nebelmaschinen steuern kann. DMX-512 wäre > vom prinzip her auch denkbar, allerdings fallen dafür bestimmt mehr > daten an als für das MP3. Schieb das in wenig genutzte Frequenzen der mp3s, mach dann beim Abspielen ne FFT drüber (deine Lichtorgel), die aus diesen bestimmten Frequenzbändern Informationen zum Ansteuern der Spezialeffekte beinhalten. So als Idee :-)
das ist auch keine schlechte idee, aber FFTs dafür finde ich etwas "overkill". angesichts heutiger speichertechnologie ist es egal ob das MP3 mit den lichtsteuerdaten drin doppelt so groß ist wie vorher. im grunde bräuchte ich erstmal nur ein paar infos über die fähigkeiten des VS1001 oder VS1011 - von jemandem, der vielleicht schon ein paar davon verbaut hat.
Gleich vorweg: Ich hab mich noch nie mit den Details von MP3 beschäftigt. Aber mir drängen sich da sofort 2 Fragen (bzw. Problemkreise) auf * kann man in einem MP3 File mehrer unterschiedliche Kanäle unterbringen, oder ist das aufgrund der Herkunft als Audio Format auf 2 beschränkt * Was ich auf gar keinen Fall tun würde: Meine Steuerdaten einem File Format anvertrauen, welches verlustbehaftet komprimiert. Das führt u.U bei der Dekompression dann zu lustigen Effekten.
Wo liegt denn jetzt genau das Problem? Such dir ein fertiges mp3-player Projekt und bau das nach. Dann hast du die Ansteuerung von VS und SD-card schon fertig. Wenn das läuft überlegst du dir, wie du in die vorhandene Firmware noch deine Lichtsteuerung einbaust. Ich würde über ein Containerformat nachdenken. Also immer ein paar Byte Lichtsteuerdaten und ein paar Byte mp3 zusammenschnüren. Das kann man dann auch auf dem microcontroller sehr einfach wieder auspacken und hat weiterhin die zeitliche Zuordnung von Licht und Ton. Fertige Player musst du aber wirklich selbst suchen. Wenns schon an der Bedienung von Google scheitert ist das Projekt nämlich wirklich nichts für dich...
hm ich glaub mit google komme ich klar... :D das ganze war auch von anfang an so gedacht, daß der µC das containerformat (welches dann keine .MP3-datei mehr ist) wieder auspackt, der MP3-Decoder bekommt von den lichtsteuerdaten nichts mit und der fürs licht zuständige teil nichts von den MP3-daten. alles andere würde mit dem begrenzten RAM eines ATMega nicht funktionieren. im grunde brauche ich informationen wie der VS1011 mit seinem puffer funktioniert und ob er einen zeit-zähler hat wo er mit dem abspielen ist. sowas würde man brauchen um das licht mit dem sound dauerhaft synchron zu halten (unabhängig von puffer-füllständen). ein fertiges projekt in assembler wäre phantastisch, evtl. eines was auch auf die SD-karte schreiben kann. ich muß ja zum player auch das gegenstück bauen um die lichtsteuerdaten zu erzeugen. also vor allem die SD-routinen sind wichtig, muß zugeben, daß ich davon noch keine ahnung habe. C ist leider auch keine stärke von mir, bislang hab ich alles modernere in assembler (oder PHP) geschrieben.
... ich glaub mit google komme ich klar ... Gratulation!
Hallo Ben__, auf den Seiten des Herstellers der VS10xx-ICs gibt es Projekte für Standalone-Player. Da holt sich das IC selbständig die Daten von der SD-Card. Der µC muss dann das ganze nur noch steuern, aber keine Daten mehr schaufeln. Das wäre vielleicht das richtige für dich. Die Informationen dazu findest du hier: http://www.vlsi.fi/en/support/evaluationboards/vs10xxprotoboard.html (in der Leiste rechts) Gruß, DetlevT
danke dir für deine sehr interessante antwort, hätte nicht gedacht, daß der IC alleine das kann. allerdings muß ich schon einen µC dazwischenschalten, denn die licht-daten dürfen nicht zum VS10xx, die licht-daten müssen zusammen mit den mp3-daten von der SD-card runter (egal ob aus einer oder aus zwei dateien) und ich muß irgendwie an diese abspielzeit-register dran falls der VS10xx sowas haben sollte.
Hallo Ben___, meines Wissens kann man in eine MP3-Datei zusätzliche Informationen standardgerecht unterbringen, die vom Decoder ignoriert werden müssten. Bei den MP3-Tags wird das z.B. so gemacht. Ob auch der VS10xx damit klar kommt, müsstest du noch einmal recherchieren. Ich weiß ja nicht, wie umfangreich diese "Lichtdaten" sind. Passen die ins SRAM? (der ATMEGA1284P hat 16kB). Falls ja, kann man das System durchaus so aufbauen, dass sowohl µC als auch VS10xx auf die SD-Card zugreifen können, allerdings nicht parallel. Die Infos dazu findest du in den Application Notes, sind aber etwas versteckt. Dann liest man halt erst einmal die "Lichtdaten" ein und startet dann erst die Wiedergabe via VS10xx. Die aktuelle Position kann man AFAIK auch auslesen und so die Sachen synchronisieren. Das beste ist wohl, man hält sich die Optionen offen. Man kann die Hardware durchaus derartig flexibel aufbauen, wenn man vorher ein bisschen nachdenkt. Gruß, DetlevT
>habe keine lust alles alleine zu bauen, Dafür gibt es noch ein ROFL;) > hat keiner schon fertige >ansätze hierfür? Ansätze für dein seltsames Projekt? Wohl kaum. > MP3-player in eigenbau müßte es doch schon viele geben! Gibt es auch. google kennt sie alle. >ein fertiges projekt in assembler wäre phantastisch Assembler benutzt da aber kaum einer. >evtl. eines was >auch auf die SD-karte schreiben kann. ich muß ja zum player auch das >gegenstück bauen um die lichtsteuerdaten zu erzeugen. Das machst du auf dem PC. Schreiben auf SD ist also nicht nötig. Mit uC sowieso viel zu langsam. >ich muß irgendwie an diese abspielzeit-register dran falls >der VS10xx sowas haben sollte Hat er. Fassen wir doch mal zusammen: Du kannst das Datenblatt vom VS10xx nicht lesen. Du kannst kein C. Google interessiert dich nicht. Du hast keine Vorstellung davon wie kompliziert das ganze wird. Über Schaltpläne wurde noch gar nicht geredet. Da kommt auch noch einiges zusammen. Fazit: Du kannst es nicht ohne massive Hilfe. Die wirst du aber nicht bekommen wenn sich keiner für dein Projekt interessiert. Dann stehst du da mit angenähtem Hals;)
naja der einzige der irgendwann mit angenähtem hals rumsteht ist so ein gewisser holger. das heißt nur falls die ärzte noch was machen konnten nachdem ich ihm den kopf abgezupft, die restlichen knochen neu gemischt und die ganze k*cke aus dem hirn gekippt habe. ich fasse am besten auch mal zusammen... 1. ich weiß was ich will (das ist schon mal viel wert) und 2. es gibt bereits fertige MP3-player im eigenbau folglich 3. möchte ich das rad nicht neu erfinden weil 4. einer dieser player bestimmt erweiterbar ist. sorry wenn ich ein wenig patzig wirke, aber wenn du keine konstruktiven beiträge zum thema abgeben kannst dann machs doch einfach mal wie dieter nuhr. ich hab nichts dagegen wenn du mir schwächen in meinem projekt oder mögliche gefahren aufzeigen willst - aber bitte nicht auf die tour, daß du alles als grenzdebil hinstellst wenn du das projekt nicht verstehst oder verstehen willst. ich lass mich doch schließlich auch nicht drüber aus ob ich deine ideen merkwürdig finde oder nicht. @detlef ich weiß nicht ob 16kbyte ram reichen. auf jeden fall wäre so ein IC interessant weil dann große puffer möglich werden. wenn VS10xx und µC nicht gleichzeitig von der SD-karte lesen können bleibt nur die option das licht-MP3 auf dem µC zu demultiplexen und die MP3-daten alleine zum decoder zu schicken. damit liest der µC alleine nur eine einzelne datei von der SD-karte. aber hat jemand die routinen für die SD-karte in assembler? lesen muß das ding zwangsläufig können und schreiben wäre schön. das zu haben wäre erstmal das wichtigste, den VS10xx zu füttern sollte nicht das riesen-problem sein. die MP3-tags sind bei den älteren tags ganz am ende der datei, bei neueren dateien hängen sie ganz am anfang. oft sind auch beide tags vorhanden, aber der MP3-datenstrom hängt immer zusammen und wird nicht durch steuerdaten unterbrochen. werd mal schauen ob ich irgendwo assembler-routinen für den zugriff auf SD-karten finde.
es ist genau umgekehrt...bei id3 v1 waren die tags immer am anfang der datei. bei neueren id3 formaten können sie auch am ende sein. ich glaub bei den neuer id3-tags ab 2.x ist die länge der einzelnen felder nicht mehr begrenzt sondern kann variabel angepasst werden. wäre also für steuerinfos zu missbrauchen aber mit verlaub: ich finde das ganze irgendwie unsinnig :)
über unsinn oder nicht kann man sich streiten. um mal ein thema anzuführen wo ich probleme mit dem sinn habe sind nixie-uhren. sowas brauche ich nun wieder ganz und gar nicht. was die zweckmäßigkeit meines projekts angeht - denkt mal an die veranstaltungstechnik. oder wenn man mal eine größere party alleine "versorgen" soll, man hat einfach nicht genug hände für ton und licht gleichzeitig. das endet dann entweder mit einer schnöden lichtorgel oder diversen sound2light-varianten, die aber alle nicht zusammenarbeiten oder man überlegt sich halt was wo der player die lichtsteuerung übernimmt. naja lange rede kurzer sinn, mit dem demuxen der daten habe ich keine probleme wenn die erstmal im puffer im µC sind. für letzteres bräuchte ich ohne hilfe etwas länger...
Ben sprach: im Player werde Licht, doch selbst leichten tut er nicht.
Ben sprach: im Player werde Licht, doch selbst leuchten tut er nicht.
Ben _ schrieb: > über unsinn oder nicht kann man sich streiten. um mal ein thema > anzuführen wo ich probleme mit dem sinn habe sind nixie-uhren. sowas > brauche ich nun wieder ganz und gar nicht. OK. Ist ein Argument. Auf der anderen Seite ist so eine Nixie Uhr softwaretechnisch nicht besonders aufwändig. > was die zweckmäßigkeit meines projekts angeht - denkt mal an die > veranstaltungstechnik. oder wenn man mal eine größere party alleine > "versorgen" soll, man hat einfach nicht genug hände für ton und licht > gleichzeitig. Genau daran denke ich. Hast du die Tools um einen Song nach dem anderen mit einer Lichtspur zu versehen? Wer wird das dann machen? Hast du dir schon mal überlegt, welche Arbeit es ist 20 Songs mit Lichtdaten zu versehen? Das ganze schreit doch schon im Ansatz nach: nette Idee, aber nach dem 5. bearbeiteten Song stellt man fest, dass das zuviel Arbeit für wenig Effekt ist und alles schläft wieder ein. Seien wir doch ehrlich. > das endet dann entweder mit einer schnöden lichtorgel oder > diversen sound2light-varianten, die aber alle nicht zusammenarbeiten Die aber einen gewaltigen Vorteil haben: Man stöpselt sie ein und egal was man ihnen vorwirft, es kommt etwas einigermassen brauchbares dabei raus. > oder man überlegt sich halt was wo der player die lichtsteuerung > übernimmt. Die Idee ist ja prinzipiell gut. Und ich denke nicht, dass du der erste bist, der sie hat. Wenn man das bisher nirgends sieht, dann hat das sicherlich keine technischen Gründe :-) > naja lange rede kurzer sinn, mit dem demuxen der daten habe ich keine > probleme wenn die erstmal im puffer im µC sind. für letzteres bräuchte > ich ohne hilfe etwas länger... Mit meiner persönlichen Meinung dazu halte ich jetzt mal hinter dem Berg :-)
eine nixie-uhr ist in software kein problem, dafür hast du hardwareseitig unschön hohe spannungen. ok ich dreh meine frage mal um... wie wäre es ein lichtsteuerpult zu bauen was auch MP3 abspielen kann? ist das gleiche in grün. nur damit man mich versteht... lichtsteuerpult bau ich sowieso, richtig interessant wär's aber wenn dieses analog zu scheinwerfern auch endstufen steuern könnte. ist hardwareseitig kein großer mehraufwand, brauche eben nur die softwareseitigen ansätze.
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.