For your setup, the stream has to be encoded in DD (AC3) in order for it to be passed, and since nearly every major streaming service is now streaming in DD+ (EAC3), you of course wont be getting a DD (AC3) signal passed unless you can find a streaming service/channel that does so (good luck, though it sure would be nice if they all did as a fallback since they already have multiple encodes, but I digress).
As far as RMP goes, it does in fact correctly pass DTS and AC3/EAC3; however, it does not pass through the "HD" audio codecs (DTHD, DTS-MA/HD, etc).
So, RMP will in fact "output" audio encodes other than PCM 2.0 - assuming the "input" is AC3/EAC3/DTS, even with sources that have multiple "HD" audio tracks ahead of the AC3/EAC3/DTS track
You might want to check that the source file being streamed is in fact AC3 and not EAC3 - use MediaInfo to check if need be.
So there is a point to detecting/configuring the audio output for DD, even if the actual DD encoded content is increasingly rare/non-extant via streaming services, as other sources such as UPnP/DLNA servers have such encoded content.
One of my home theater setups is just as such - an LG TV circa 2012 with built-in DD+ capable apps (netflix/prime/hulu/smartshare), but only accepts/sends DD via the HDMI ports, and transcodes the internal DD+ to DD via ARC/Optical. RMP via a 2018 SS connected via one of its HDMI ports outputs AC3 and DTS encoded files from my server, but not EAC3 (no DD+ support on HDMI).
Again, I would verify your setup and your audio encodes on your source files.
.