When comparing native DSD and I2S formats, they seem to be quite compatible. IMO two I2S/PCM data lines could be used for creating a native DSD interface. The 32 bits of each DSD channel could be split to two 16bit PCM channels, using 4 PCM channels (= 2 I2S interface data lines) for each DSD channel pair. RPi5 could output 4ch DSD256 (8ch I2S at 176.4kHz running with 32bit frames bclk = 32fs). RK 3308 (e.g. Rock Pi S stamp module) could output 8ch DSD512 (RK3308 I2S runs ok at 16ch 384kHz). Only the bit clock and data lines would be used, the frame clock (LRCLK) would be ignored.
IMO it would "only" take an alsa-lib plugin which would accept existing alsa DSD formats and shuffled the bytes for a multichannel PCM-format alsa I2S device. Any native-DSD-capable player (e.g. mpd-dsd) could use it on any multichannel-I2S SBC.
A boom in multichannel hats for RPi5 can be expected, those having a DAC chip with DSD support could even offer native DSD
IMO it would "only" take an alsa-lib plugin which would accept existing alsa DSD formats and shuffled the bytes for a multichannel PCM-format alsa I2S device. Any native-DSD-capable player (e.g. mpd-dsd) could use it on any multichannel-I2S SBC.
A boom in multichannel hats for RPi5 can be expected, those having a DAC chip with DSD support could even offer native DSD
Don't know about hats though. RPi historically has conducted and radiated noise problems. Just look at all the products Iancanada makes to help mitigate the noise issues (not that they are solely a problem with RPi). I would rather see RPi used as a USB host from a noise management perspective. Then the dac can have some physical distance from the noise source. Even then things like reclocking and isolation would probably help too.