hallo, ich hab vor mir mit dem AT91SAM7S256 einen Audio-Player zu basteln. Ich schreibe bewusst nicht Mp3-Player oder Vorbis-Player weil ich der Schwierigkeit halber vorerst nur PCM-Dateien abspielen möchte. Als Codec hab ich mir den TLV320AIC23B vorgestellt - der wurde ja auch schon bei ähnlichen Projekten benutzt. Als Datenquelle für die PCM-Dateien möchte ich gern eine SD/MMC-Karte benutzen. Weil auf der "AT91SAM7S256 ARM Entwicklungsplatine" schon alles drauf ist außer der Codec werde ich wohl diese benutzen. Ich hab mich über PCM und den WAVE / RIFF-Container schon informiert und denk, dass ich den selbst implementieren kann. Von den Verarbeitungsschritten hab ich das Vorstellung: SD/MMC-Karte ---(SPI)---> AT91SAM7S256 ---(SPI + I2S)---> TLV320AIC23B --> Kopfhörer Im Controller werden die Daten dann eben aus dem RIFF-Container geholt und über I2S an den TLV320AIC23B geschickt. Klingt das ganze realistisch und was haltet ihr davon? Welche Tipps habt ihr für mich? Danke! mfg blan
sollte sicherlich machbar sein. das einzige was evtl. kritisch ist das du genug zwischenpuffer hast damit der audio-datenstrom nicht abreisst. ansonsten sollte das denke ich machbar sein. würde auch gern sowas ähnliches machen, stehe aber irgendwie mit den arm's auf kriegsfuß, denn ich krieg da keinen gescheiten fuß rein. :-(( ansonsten viel glück. gruß rene
also der AT91SAM7S256 hat 64kByte RAM. ich kann jetzt aber überhaupt nicht einschätzen wie viel so ein Zwischenpuffer braucht bzw. wie viel mein Programm brauchen wird - das Programm sollte aber egtl nicht so groß sein. Gibt es da eine Formel mit der ich den Zwischenpuffer für so ein PCM-Stream berechnen kann? Er sollte eine Sample-Rate von 44100Hz mit 16bit haben. mfg blan
also eine formel gibt es denke ich nicht dafür. es hängt davon ab wie schnell du deine sd-karte auslesen kannst. aber ich denke ein puffer von einigen kB (2-3) sollte schon reichen.
also ich hab hier mal ein Bild zu diesen PCM-Samples gefunden und versuch es zuverstehen: http://www.it.fht-esslingen.de/~schmidt/vorlesungen/mm/seminar/ss00/HTML/wavdataformat.jpg Sehe ich das richtig, dass ich bei 16bit Stereo einfach nur zwei 8bit Kanäle habe? Irgendwie erscheint mir das wenig - stimmt das so? mfg blan
Hallo, das mit der Formel ist in der Tat nicht pauschal beantwortbar, es hängt sehr davon ab, wie verläßlich die PCM Daten über einen längeren Zeitraum isochron bereitgestellt werden können. Ich hab das Thema gerade gemacht und brauche für die reine I2S tatsächlich nur 2x1024 Byte, jedoch davorgeschaltet nochmal 512kB, weil die PCM Daten bei mir über das Netzwerk kommen. TIP 1: In deinem Fall (hab grad mal das Product Data sheet der AT91 Serie überflogen) könntest du glaube ich eine DMA für SPI und eine für I2S nutzen. TIP 2: Denk doch mal über folgenden Vorschlag nach: * I2S-Interrupt triggert DMA, die DMA lädt dann I2S Register nach * Die I2S-DMA hat immer einen 1024 Byte Block in Arbeit * ein weiterer Block ist im Standby. * Bei DMA Interrupt (1024 Byte abgearbeitet) auf Standby Block umschalten * nach Umschalten einen neuen Standby Block vorbereiten Falls ich richtig gerechnet habe, mußt du es schaffen, ca. alle 5,8ms 1024 Byte bereitzustellen, damit HiFi Freuden aufkommen. TIP 3: Bring nicht die Links-Rechts Ordnung im Datenstrom durcheinander, so wie es mir passiert ist...
Erstmal danke. Ja also so wie ich das mitbekommen habe kann der AT91SAM7**** für jede Komponente DMA benutzen. Benutzt du den gleichen Codec wie ich vor habe zu benutzen? Und kommen deine Daten im PCM-Format übers Netzwerk? Also theoretisch sollte es doch machbar sein wenn es leute schaffen mit dem gleichen Mikrocontroller in der gleichen Zeit noch mp3 zu decodieren oder? mfg blan
Moin, bin grade an einem ähnlichen Projekt. Hardwaretechnisch habe ich mich an den Arm-mp3-Player Projekt gehalten (http://www.mikrocontroller.net/articles/ARM-MP3-Player). Ich will aber was interaktives daraus bauen, mit Display, Tasten und allem Schnick und schnack. Um möglichst flexibel zu sein, habe ich das ganze auf FreeRTOS aufgebaut und für die Entwicklung die mp3-decodierung erstmal weggelassen. Aktueller Stand: Wave (16 Bit, 44.1 kHz) geht prima, auch mit doppelter Abspielgeschwindigkeit (mit irgend einer ollen 256 MB-Karte). Der Buffer ist nicht besonders groß; schau mal beim oben genannten Projekt, die ganze DMA-Geschichte habe ich fast wörtlich übernommen.
Nein, ich hab nur einen DAC gebraucht und daher den PCM1770 genommen. Ja, bei mir kommt bereits PCM übers Netzwerk und zwar von einem Win-PC, der bekanntermaßen recht unvorhersehbar schedult - daher brauche ich soviel Zwischenspeicher. Du hast ja gute Hardware-Unterstützung. Wenn du die sinnvoll nutzt, hat dein AT91 bestimmt Langeweile beim PCM abspielen. Viel Puffer brauchst du jedenfalls nicht, wenn du von MMC streamen möchtest Also viel Erfolg...
Genau das habe ich mit der selben Hardware schon gemacht: http://www.mikrocontroller.net/articles/ARM_MP3/AAC_Player -> play_wav.c RIFF-Auswertung habe ich nicht implementiert, ich schicke die WAV-Files einfach direkt an den Codec.
hi, okay das klingt schonmal sehr gut, dass der zwischenspeicher reichen wird. also ich werde den WAVE / RIFF Container wohl selbst implementieren - will mir ja nicht nur Code zusammensuchen. Also hab ich das jetzt richtig verstanden, dass 16bit-Stereo pro Kanal (links, rechts) jeweils 8bit hat - klingt für mich bischen wenig? Ein problem wird noch sein, dass der Codec so ein kleines SMD-Bauteil ist - weiss noch nicht wie ich das löten soll. mfg blan
Üblich sind 16 Bit pro Kanal. > weiss noch nicht wie ich das löten soll http://www.mikrocontroller.net/articles/IC-Gehäuseformen#Adapterplatinen_f.C3.BCr_SMD-ICs oder [[Audio Codec Board mit TLV320AIC23b]]
@blan Nein 16Bit-Stereo, hat für jeden Kanal 16Bit, siehe auch deine eigene Grafik die du online gestellt hast. Diese 16Bit kann man aus 2x8Bit zusammensetzen.
@tom dann sollte ein Sample bei Stereo ja 4byte groß sein - für jeden Kanal 16bit. Was mich dann aber verwundert ist die Ausgabe meines Audio-Players (mplayer)
1 | AO: [esd] 44100Hz 2ch s16le (2 bytes per sample) |
Warum sinds denn hier 2bytes / Sample bei 16bit Stereo? mfg blan
@andreas Danke für den Link! Ich hab jetzt vor mir das hier zu bestellen: http://www.futurlec.com/SMD_Adapters.shtml (28 pin SSOP Adapter). Würde das passen, weil der Codec ein 28-Pin TSSOP Gehäuse hat - ich hab aber keine Ahnung was das T für ein unterschied macht. mfg blan
>ich hab aber keine Ahnung was das T für ein unterschied macht.
T = Thin. Die Gehäuse sind niedriger (dünner).
hi, also ich hab den TLV320AIC23B jetzt auf meine Adapterplatine gelötet. Allerdings weiss ich nicht ob er heil geblieben ist. Kann ich ihn irgendwie testen ohne unnötige Fehlerquellen ( zB. i2c, spi Ansteuerung ) zu benutzen? Vielleicht durch das Messen einer bestimmten Spannung an einem Pin? mfg blan
hi, ich komm momentan ins stutzen. kann es sein, das die Olimex AT91SAM7S256-Platine die Pins für SSC (I2S) für was anderes benutzt und ich das SSC in die Tonne treten kann? mfg blan
ja, das hab ich auch schon gesehen. allerdings sind die Pins für TK, TF, TD schon für andere Zwecke missbraucht worden. Wenn ich dem Plan hier trauen kann: http://www.olimex.com/dev/images/ARM/SAM/SAM7-Pxxx_Rev_E-sch.gif mfg blan
kann mir niemand sagen wie ich ohne zu löten an alle SSC Transmit-Pins herankomme? Laut dem Schaltplan kann ich nähmlich nur TF ohne weiteres abgreifen. TD ist mit der LED verbunden - das würde sich vielleicht noch einrichten lassen aber TK führt zum USB-Anschluss und da seh ich keine möglichkeit das abzugreifen. Niemand eine Idee? mfg blan
Hmm, da hat sich ja in der Rev. E leider einiges geändert. Ich fürchte das wird ein Gebastel TK abzugreifen. Schau dir als Alternative vielleicht mal das SAM7-EX256 an, da sind alle benötigten Signale am EXT-Anschluss verfügbar.
Bitte 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.