TL;DR it's possible, but the CPU doesn't seem to be able to cope with audio input, audio output and DRM decoding simultaneously.
I managed to compile Dream DRM software version 1.12b on the latest version of Raspbian. I followed these instructions:
Some changes were required for the code to compile properly (in a few places c library includes were omitted and the new libtool required some syntax changes for the bootstraps to work). I built a headless version because I couldn't get it to compile with QT (indeed, 1.12b was the only version I could build without any QT errors, whether in headless mode or not). So the configure command used was:
./configure --disable-qt --disable-hamlib --enable-portaudio
This required portaudio19-dev library to be installed, as the default ALSA audio interface doesn't work in headless mode (it uses QT threads).
First, I overclocked RPi to 1100 Mhz and used the file input mode ( -f) to decode an intermediate frequency wave file, available here:
That worked fine, the audio was decoded without a glitch and was played back through the default HDMI interface onto my TV. That was as far as I got without any trouble.
I have an old USB sound card, which I then used to feed the same wave file being played on my netbook from its audio out to Dream in normal mode. Log output indicated that Dream recognised it as a DRM stream, but no audio was produced, either through HDMI or the USB sound card (whichever I happened to select at the time).
I shut down Dream and recorded this input from the USB sound card using arecord into a wav file. I then used Dream in file input mode once again with this new wav file and it decoded it fine.
So, it appears that RPi doesn't have enough mojo to do everything at once. I'm still investigating whether I can remedy this situation by one or more of:
1) Using jack instead of portaudio
2) Using a different USB sound card
3) Building a newer version of Dream (if I can figure out how to get rid of QT compilation errors in headless build mode).