Music Assistant
Add native DSD (Direct Stream Digital) passthrough support - Ability to stream and play unaltered DSD via Sendspin or other capable Player Providers? #7043
Replies: 3 comments
|
Thanks for writing this up and for linking the PRs! A quick status on the DoP part (phase 1):
Tested on real hardware with a FOSI Audio ZD3 and an Ampapa Q1, with the Sendspin CLI on an Orange Pi 3B (4 GB), playing DSF files as DoP up to DSD256. One note on your native DSD notes: good point about the |
|
A note on phase 3 and DLNA, from my own experience: with Music Assistant, my DLNA renderers were not reliable even with plain PCM. They dropped their connection, skipping to the next track sometimes did nothing, the renderer sometimes just hung until I restarted it, and the playback position (where in the track it was at a given moment) was only reported correctly some of the time. That is why I stopped using DLNA for music with MA and moved to Sendspin. So before DSD passthrough over DLNA, I think basic playback, track changes and position reporting on DLNA renderers need to be solid, or DSD would just add one more thing that can fail. Sendspin seems the better place to start, since MA controls both ends there. |
|
Not sure if you all heard but in interesting news related to this you should also be aware that the upcoming next ESPHome firmware (already in 2026.11.0 Beta) will have added support for a new USB Audio Speaker (
So that means it should be possible to connect a USB DAC that support to something like example the new Home Assistant Connect AUX-2 (device based on ESP32-S3) and flash a different configued ESPHome firmware which have USB Audio enabled. However you would then also have to add DSD support to the Sendspin client (which uses sendspin-cpp on ESPHome). Note as well that believe it is only the newer ESP32-S31 and ESP32-P4 (which bothsupporting high-speed 480 Mbps USB OTG) that support USB Audio Class 2.0 (UAC 2.0) which have higher bandwidth than UAC 1.0 (hence there the Home Assistant Connect AUX-2 is not based on that newer ESP32-S31) . So while ESP32-S31, ESP32-S3, and ESP32-P4 all support support USB Audio Class (UAC) it is only ESP32-S31 and ESP32-P4 that support high-speed needed for USB Audio Class 2.0 (UAC 2.0) DACs. There for it would be better to look at using a ESP32-S31 or ESP32-P4 development board with a USB OTG port if interested in testing it. Ex: FYI, "ESP32-S31-Function-CoreBoard-1" (official development board from Espressif) at least looks to be available from third-party resellers: It also features an GPIO pin header (similar to the standard Raspberry Pi layout) so looks like it could be a nice board for prototyping(?): 
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Suggest MA adds opt-in support for nativly playing DSD (Direct Stream Digital) files unaltered on players whose whole chain can handle it.
The premise that that to audiophiles and audio entusisats it could be seen as limited in Music Assistant server that Sendspin and other player providers currently only support PCM, FLAC and Opus, meaning that DSD files always decoded to PCM.
If could make it so that Music Assistant server and its player providers (like the Sendspin Player Provder) could also support DoP ("DSD over PCM") as well as "Native DSD" (native native 1-bit DSD) then the clients supporting "DoP" or "Native DSD" playback (which require that client DAC which support DSD) could play back the stream as unaltered native DSD (i.e. bit-perfect raw DSD bits).
That is, instead of decoding DSD to PCM (which removed the original 1-bit DSD data), enable and allow Music Assistant's player providers to pass-through the original 1-bit DSD data directly to the player , with optional support to use DoP (DSD over PCM as per PR music-assistant/server#7429 ) or native DSD (native 1-bit DSD nativly supporting DSDIFF, DSD Interchange File Format), so the DAC natively receives bit-perfect untouched dsf/dff file streamed without being modified/converted/transformed end-to-end. So no longer always having Music Assistant's internal audio pipeline automatically converting DSD tracks into compatible PCM streams.
Suggest look at first adding support to Sendspin Player Provider and clients, then for other providers whose endpoints already support DSD.
FYI, be aware that some of the original use cases for the Direct Stream Digital (DSD) format was primarly used to digitally encoding audio signals for "Super Audio CD" (SACD) and "DVD-Audio" discs, but it is also a used by some commercial online services (like exampel Mobile Fidelity / MoFi) and audiophile entusiasts when digitizing vinyl records (e.g. LP records) and original analogue master tapes (a.k.a. masters) in order to preseve as high resolution into a convenient digital file format (
.dsf/.dff) for easier distrobution of highest possible HiFi audio recordings.More references:
Today these files/formats can only be played as decoded PCM in Music Assistant, so a DSD-capable DAC never gets to use its DSD path directly.
Competing music server/ecosystems such as Lyrion Music Server with Squeezelite, moOde, and Roon all offer either DoP or native DSD playback, and requests for DSD keeps coming up in this community (see #1720, #5110, #5111, #5372).
With Sendspin positioned as the open alternative to closed-source and propriatory ecosystens which already have native support for DSD, adding support for DoP and fully native DSD (native 1-bit DSD) would close one of the remaining gaps between them and capable Sendspin players.
The various common DSD formats for reference:
Where things stand
--clock-source dacfor bit-perfect single-room playback Sendspin/sendspin-python-cli#318 (--clock-source dac).Proposal (phased in several stages)
dsdformat next topcm,flacandopusin Sendspin's format negotiation, covering DSD64 up to DSD512. Native DSD uses a third less bandwidth than DoP, doesn't need ever-higher PCM carrier rates (DoP needs 705.6 kHz for DSD256 and 1411.2 kHz for DSD512), and also works with DACs that support native DSD but not DoP. This needs a Sendspin spec change, so it's listed here to keep the whole picture in one place.-D [delay][:format]withdop,u8,u16le/beoru32le/be), so DSD could be passed through to Squeezelite clients started with DSD support.GetProtocolInfosink.Note! Providers that can't carry DSD (AirPlay, Google Cast, Sonos, Snapcast and others) keep getting decoded PCM, as today, so no change.
Expected behaviour
What should not be in scope
Notes for a native DSD format in Sendspin
{"codec": "dsd", "channels": 2, "sample_rate": 2822400, "bit_depth": 1}insupported_formats(illustration only; the exact shape is up to the Sendspin maintainers).DSD_U32_BE).0x69) rather than zero bytes, to avoid pops and DoP dropouts.-Ddelay), while DSD-to-DSD track changes stay gapless.Other related dicussions and suggestions or requests:
server_transmittedfield to all server->client stream messages Sendspin/spec#106][https://github.com/How does Sendspin specs compare to this Open Advanced Audio Transport (OAAT) spec? Sendspin/spec#196] - How the Sendspin spec compares to OAAT and RAATPS: This is meant as a new standalone feature request, so not the same as a narrowly scoped DSD request suggested in #5372, so interest can be gauged separately from the general "minimal processing mode" that was declined there in that feature request.
All reactions