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.

[capslock]

Ich glaub das wars, auch bei frühen USB-Soundkarten, es geht um 2x2.

[Udo]

sehr interessantes Projekt
eigentlich sollte auch mit USB 1.1 24/96kHz Stereo möglich sein

wobei ich einen SPDIF Eingang bevorzugen würde
es gibt C++ Bibliotheken für diese Funktion

S/PDIF receiver library for Raspberry Pi Pico series
Overview
S/PDIF receiver with sampling frequency detection by PIO function
Supported format:
Channels: 2 (Stereo)
Bit resolution: 16bit and 24bit
Supported sampling frequencies:
44.1 KHz, 48.0 KHz, 88.2 KHz, 96.0 KHz, 176.4 KHz and 192.0 KHz for Raspberry Pi Pico (rp2040)
44.1 KHz, 48.0 KHz, 88.2 KHz and 96.0 KHz for Raspberry Pi Pico 2 (rp2350)

s.a. Raspberry Pi Pico as S/PDIF Digital Audio Receiver https://www.elektormagazine.com/articles...o-receiver

also über SPDIF -> DSP -> 8 Kanäle I2S raus (z.B. TAS5830 Class D Amp) das wäre schon genial
bleibt die spannende Frage ob die Rechenleistung des Pico ausreicht ...

[JFA]

Der TAS5830 hat ja einen eigenen DSP drin, zwar mit weniger Features, aber in den meisten Fällen reicht das. D.h., man bräuchte nur einen I2S Bus und konfiguriert die TAS5830 dann über I2C.

[Udo]

sicher möglich aber widerspricht dem Konzept. Es soll ja möglichst universell sein u. vielleicht will jemand einen I2S DAC anschliessen o. möchte einen SPDIF Ausgang usw.
( momentan ist sowieso nur SPDIF(out) implementiert, mal schauen wie es sich weiterentwickelt )