Ich habe aktuell ein Projekt, bei dem es darum geht, vorgefertigte "Audiofiles" mit Samplingraten bis 500 kHz bei 24-32 bit von einer SD-Karte auf einen Trigger hin abzuspielen (gibt also gern mal knapp 40 MBit/s Datenverkehr). Es gibt mehrere verschiedene Dateien, und eine Playlist, die festlegt, in welcher Reihenfolge (mit Wiederholung) die gespielt werden sollen Vor und nach jeder Wiedergabe ist relativ lang Zeit (>5x Länge der Datei), eine Datei selbst ist nicht länger als 2 s. Soweit so einfach, der eigentliche Trick ist aber, dass das Abspielen getriggert sein soll. Also auf einen Pin Change hin, soll mit 100 us Zeitgenauigkeit die Wiedergabe der nächsten Datei starten. Wie würdet an so eine Aufgabe rangehen? Je "einfacher", desto besser. Das Teil soll wirklich nur Daten von SD lesen und die an einen DAC weiterreichen, nur halt zeitgenau auf einen Trigger hin.
Einen entsprechenden Bereich im RAM für die Sample-Datei reservieren sowie die Playlist ebenfalls bereits im RAM ablegen. Bei Port IRQ einen DMA auziehen und die richtige Datei von SD-Karte in Ram kopieren - zeitgleich einen zweiten One Shot-Timer starten. Länge des Timers auf 100us einstellen Bei Timer-IRQ dann einen zweiten DMA starten um aus dem RAM in den DAC zu schreiben. Die SD Karte muss natürlich schnell genug sein dun das Filesystem muss innerhalb der 100us die richtige Datei ausspucken - aber durch die Trennung der beiden Datenströme werden die beiden Zugriggs-Funktionen etwas entkoppelt
SD-Karten sind nicht deterministisch. Die machen zwischendurch einfach mal bis zu einigen 100ms Pause, wenn der Controller irgendwas anderes zu tun hat. Du hast auf das interne Zeitverhalten Null Einfluss. Und das ist von Karte zu Karte auch unterschiedlich. Deine 100us Reaktionszeit kannst Du so nicht garantieren. SD-Karten sind daher das falsche Medium. Es gibt mehrere Möglichkeiten: 1. alle Samples vorher ins RAM laden, oder wenn das reicht, nur das nächste. Du brauchst dann natürlich genug RAM. Es gibt SPI PSRAM, z.B.: https://www.apmemory.com/wp-content/uploads/APS1604M-3SQR-SN.pdf 2. anderes Flash-Speichermedlum, und zwar eines OHNE internen Controller. NOR-Flash ist einfach, aber die verfügbaren Kapazitäten sind begrenzt (so bis 16 oder 32MB). NAND-Flash ist komplizierter, weil es defekte Blöcke haben kann. Dafür hast Du viel mehr Kapazität. Dadurch, dass Du das Flash direkt steuerst, ist das Zeitverhalten absolut deterministisch, d.h. bei jedem Takt kommt zuverlässig ein Byte/Wort heraus, auf die ns genau. fchk
:
Bearbeitet durch User
Danke, die Idee mit DMA hatte ich auch. Ich frage mich nur, ob ich mit einem Raspberry nicht besser aufgehoben bin. Ich könnte doch die SD-Schnipsel in dessen umfangreichen RAM laden und das dann per Software abspielen. Habe ich da eine chance, oder macht mir da das Betriebssystem bei 100 us einen Strich durch die Rechnung? Die 100 us sind der erlaubte Jitter..., einige ms zusätzlicher, deterministischer delay wären auch ok.
Josef schrieb: > Danke, die Idee mit DMA hatte ich auch. Ich frage mich nur, ob ich mit > einem Raspberry nicht besser aufgehoben bin. Ich weiß nicht ob der Pi die geforderten 500 kHz Samplerate auf dem I2S kann. Ich denke, mehr wie die üblichen 48kHz werden nicht drin sein. Die Doku schweigt sich dazu leider aus. fchk
Ist das denn ein I2S DAC? Da gibt es ja doch welche mit schnelleren Schnittstellen ...
Gibt welche mit 384 kHz, das wäre gerade noch akzeptabel...
Josef schrieb: > dass das Abspielen > getriggert sein soll. Also auf einen Pin Change hin, soll mit 100 us > Zeitgenauigkeit die Wiedergabe der nächsten Datei starten. > Wie würdet an so eine Aufgabe rangehen? Je "einfacher", desto besser. > Das Teil soll wirklich nur Daten von SD lesen und die an einen DAC > weiterreichen, nur halt zeitgenau auf einen Trigger hin. Sowas hab ich vor Jahren mal gebaut, wenn gleich nur für 44.1kHz. Die Dateien lagen in einem parallelen Flash mit 1Gbit. Da konnte man sehr einfach taktgenau (44.1kHz) starten und stoppen, ohne Handstände. Lief über ein kleines FPGA. Vorher wurden die Dateien per AVR von SD-Card in den Flash geschrieben.
Ich habe mal in die Doku vom Arm Prozessor STM32H743 geschaut. Der hat einen recht frei programmierbaren I2S Kanal. Allerdings ist die maximale Frequenz dort auch nur 192 KHz. Mehr wird von den 'normalen' Audiospielern wohl nie gefordert. Ich denke, dass Standardwege über I2S für 500 KHz nicht mehr gehen, weil es für alle Chips ausserhalb der Specs liegt. Und das Raspi-Betriebssystem wird wir auf jeden Fall Knüppel in den Weg legen. Die Genauigkeit mit einem Linux auf dem kleinen Prozessor, das geht kaum. Da ist dann wohl eigene Hardware und Software fällig.
> Ich habe aktuell ein Projekt, bei dem es darum geht, vorgefertigte > "Audiofiles" mit Samplingraten bis 500 kHz bei 24-32 bit von einer Von welchem Planeten kommst du eigentlich? Weil es klingt irgendwie nicht so als wenn Menschen das hoeren koennten. Und sollte dir irgendeine Messtechnikanwendung im Sinn kommen, dir ist schon klar das Audio-DACs eben auch auf Audio optimiert sind und fuer Messtechniksachen oftmal unbrauchbar? Olaf
Josef schrieb: > 500 kHz bei 24-32 bit Soso, welchen 32Bit-DAC mit 2µs Settling-Time hast Du Dir denn dafür ausgesucht?
Peter D. schrieb: > Josef schrieb: >> 500 kHz bei 24-32 bit > > Soso, welchen 32Bit-DAC mit 2µs Settling-Time hast Du Dir denn dafür > ausgesucht? Er schrieb "Audiofiles", weil ihm der Begriff programmierbarer Funktionsgenerator nicht geläufig ist.
Naja, es reicht wenn Mäuse und Fledermäuse die Töne hören können. Ist für eine Anwendung in der Verhaltensforschung im Tierreich, und da die natürlichen Rufe der Tiere teilweise bis 120 kHz gehen, reichen 192 kHz DAC halt nicht aus.
Frank K. schrieb: > SD-Karten sind nicht deterministisch. Die machen zwischendurch einfach > mal bis zu einigen 100ms Pause, wenn der Controller irgendwas anderes zu > tun hat. Bei rein lesendem Zugriff gibt es sicherlich keine 100ms Pause. Ob die 100us eingehalten wegen können müsste man prüfen, aber mit einem entsprechend schnellen Controller, kann ich mir das schon vorstellen.
Josef schrieb: > reichen 192 kHz DAC halt nicht aus. ja ok, aber hören die Viecher 24-32 Bit? Weißt du was das für ein Störabstand ist (wäre...)? Sind das audiophile Fledermäuse?
> ja ok, aber hören die Viecher 24-32 Bit?
Yep, wuerde auch empfehlen mal testweise das aktuelle Radioprogramm
auf 8Bit runterzurechnen. So schlecht ist das garnicht mal.
Andererseits wenn eine Fledermaus goldene Ohren hat dann sind
die natuerlich auch sehr gross. :-D
Olaf
Die hören nicht 32 bit, aber es wäre sehr praktisch, wenn die Lautstärke der Töne über einen weiten Bereich direkt in der Datei codiert werden könnte, ohne zusätzlich am Gain rumdrehen zu müssen. Aktuell nehmen die Leute 16 bit, aber das ist nicht optimal. 24 bit müssten schon drin sein.
Wenn die Reihenfolge, in der die Dateien abgespielt werden, feststeht, kann man die jeweils nächste Datei rechtzeitig vorher ins RAM laden, dann sind Timing-Unregelmäßigkeiten der SD-Karte schonmal egal. Dazu ist natürlich genug RAM nötig (4MB), aber Controller, an die man SDRAM anflanschen kann, gibt es ja genug. Zum Abspielen ist dann nicht einmal DMA nötig, weil die CPU in der Zeit ja sowieso nichts anderes zu tun hat.
Josef schrieb: > 24 bit müssten schon drin sein. Dann will ich sehen, wie du 140dB Dynamikumfang zum Schallwandler bringst. Nochmal: Ist dir klar was das bedeutet?
Ist mir klar. Es soll halt einfach etwas besser als 16 bit sein. Wenn da effektiv 19-20 bit rauskommen ist das auch ok. Es muss nicht perfekt 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.