Raspberry Pico (2) als DSP

[capslock]

Das hier https://www.audiosciencereview.com/forum...fee.69343/
hat sich in kürzester Zeit rasend schnell entwickelt. Momentan kann es USB-in (leider nur bis 48 kHz) und 8x out als SPDIF. Geplant sind auch SPDIF und WLAN in und I2S oder ADAT out. Effizienzgewinne im Code oder evtl. Overclocking lassen auf 96 kHz hoffen oder auf längere FIRs. IIRs kann das Ding schon mehr als Aurora konnte (insbesondere gestackte Shelving filter pro Kanal).

[Micha_HK]

Das Projekt ist doch für den Rpi Pico (bare metal code) und nicht für den Zero (Linux), oder?

[capslock]

Danke, korrigiert.

[newmir]

Spannend!

Hast Du schon erste praktische Erfahrungen?

[capslock]

Nein, bisher habe ich mir nur einen Stuhl aufgestellt und gucke, was es wird. Der vorlaute Klickfinger hat aber der letzten Bestellung schon einen Pico 2W zugefügt.

[JFA]

Vielleicht hab ich was am Helm oder es überlesen, aber das Board hat doch keinen SPDIF? Also missbraucht er da einen GPIO?

[capslock]

Genau, er macht das über GPIO, I2S und ADAT sollen folgen. Mir ist noch der Gedanke gekommen, welcher Oszillator eigentlich der Master ist, frage ich mal dort.

[JFA]

Mein Erfahrungen so eine digitale Audio-Schnittstelle per Bit Banging zu machen sind schon einige Monde her. Damals war das ziemlich grauenhaft, die Clocks waren einfach mies. Mag sein, dass das heute besser ist.

[capslock]

---

Er schreibt, momentan über PIO, aber später auch externe Clock in. Dazu kommt, dass zB die ESS-DACs einen sehr robusten ASRC eingebaut haben.

[JFA]

Den braucht es dann auch. Ich denke da aber an sowas wie den TAS5830. Der hat einen I2S Eingang und verlässt sich dabei auf die Bitclock. Das ist ja auch normalerweise kein Problem, ich weiß aber nicht was passiert, wenn die mies ist. Auf dem EVM ist ein PCM9211 drauf, dessen Clock ist sauber genug.

Aber, wie gesagt, kann sein, dass das heutzutage kein Thema mehr ist.

[newmir]

Ich habe ja eher den Verdacht, dass der Hund mit dem Timing woanders begraben sein könnte. Ich kenn das aus der ESP8266 Welt. So ein Microcontroller hat so einiges an Firmware drin, so eine Art Betriebssystem mit dem er seine Schnittstellen bedient und Timer und sowas zu Verfügung stellt. Dafür darf der die Ausführung des sonstigen Codes unterbrechen. Das stört normal nicht, aber eben dann doch wenn man versucht zeitkritische Sachen zu machen. Aber ob das hier relevant ist ....?

[JFA]

Das erledigt man über (Software-)Interrupts die dann die gerade laufende Ausführung zwangsweise unterbrechen. Aber diese Interrupts hängen natürlich auch an der Clock, und wenn die Murks ist wird es halt nicht gut.

Der verwendete uC hat auch 2 Kerne, d.h man kann auf dem einen irgendwelches Gedöns machen und auf dem anderen die zeitkritischen Dinge. Und die haben da die Cortex DSP instructions mit drin, die können auch helfen, aber damit kenne ich mich nicht aus. Wenn ich mir das hier so durchlese klingt das aber gar nicht mal so verkehrt.

Ein "richtiger" DSP wird den weiterhin als nassen Lappen benutzen, aber vielleicht braucht man die Rechenleistung ja nicht unbedingt. Vor Allem, der billigste ADAU kostet ungefähr genauso viel und dann müsste man noch einen zusätzlichen uC dazu packen um die gleiche Funktionalität zu erhalten.

[capslock]

https://www.audiosciencereview.com/forum...st-2521882

[JFA]

Ah, danke. Das mit dem Fractional-N-Jitter kannte ich noch nicht, wieder was gelernt. Also packt er sich dann eine weitere stabile clock drauf.

[JFA]

Momentan kann es USB-in (leider nur bis 48 kHz)

Ich befürchte, dabei wird es auch bleiben, weil der uC nur einen Full Speed controller hat: https://www.edn.com/fundamentals-of-usb-audio/

A single isochronous transfer can carry 1024 bytes, and can carry at most 256 samples (at 24/32 bits). This means that a single isochronous endpoint can transfer 42 channels at 48 kHz, or 10 channels at 192 kHz (assuming that High Speed USB is used – Full Speed USB cannot carry more than a single stereo IN and OUT pair at 48 kHz).

Wobei ich die Rechnung dahinter noch nicht durchschaut habe, eigentlich müsste mehr gehen, und vor Allem wenn man nur In oder Out haben will, nicht beides zusammen. Vielleicht ist das auch eine Einschränkung im USB-Standard.