Thanks for the reply. I did not explain the full extent of my issue.
I'm eager to understand why the device is working, rather than just be content that it works, because I have two DLNA devices with the same capabilities (I'll call them 1 and 2). Both 1 and 2 experience the same gaps in playback of DSD. The issue is resolved for device 1 if I disable "Bitstream DSD", but not resolved for device 2. With this option disabled, device 2 indicates it is receiving PCM data and becomes unlistenable due to stuttering. I was hoping that if I can better understand the "Bitstream DSD" option and what causes MC's audio engine to kick in and do the conversion to PCM, then it may lead me to a consistent setup where both devices can stream gapless DSD.
This section from the DSD - JRiverWIKI (
https://wiki.jriver.com/index.php/DSD#Bitstreaming)...
With a DAC that supports native DSD playback, it is possible to bitstream DSD and bypass MC's audio engine (and, therefore, the DSD to PCM conversion). There are multiple DSD bitstreaming technologies:
ASIO 2.2
DSD over PCM (DoP)
DSD over DLNA (DoPE)
...seems to imply that if DSD cannot be streamed with one of these three technologies, then MC's audio engine will convert it to PCM. A bit further down in the wiki (the DSD over DLNA section)...
If you have a DAC that supports DoPE (the DLNA version of the DoP standard), Media Center can control the device and bitstream native DSD content directly to it over the network.
...makes me think that the only way to send DSD content directly over the network is through the DoPE technology, which is enabled by the "Bitstream DSD" option in DLNA servers. Which makes me think if that option is not enabled, MC's audio engine should be kicking in and converting the DSD to PCM. This is what appears to be happening for device 2, but not for device 1 which still indicates it is receiving DSD data.
@thecrow , I'm confused by what you mean by "native stream." Is there another way JRiver sends native DSD data besides the technologies mentioned above?