So they’ve turned off the DSP on the device to allow us to make full use of its 24/192 bit rate capabilities.
Seems like a fairly major problem to me with their implementation. We gain a bit now with the fix but lose something else… possibly!
One of roon’s many plus points the signal path revealing the truth that would have likely stayed hidden otherwise!
Maybe a non issue as I’m using roon’s DSP which I imagine is better anyway. Good to see the last of the green dot of death.
SQ wise I believe I am detecting a slight improvement with removal of a layer of murk though difficult to accurately compare before/ after.
Good there is resolution but am sensing a compromise/ workaround…
I’ll go reread the post from bluesound later when I have time, but I don’t think that’s what they said. I think they were saying their software wasn’t running fast enough on certain products to handle the added load of the roon endpoint. In order to still be able to ship, they hacked in a patch (without bothering to tell the clients) that limited the supported bit rate for the affected products, thus giving their software more headroom. Over the last 2.5 months they’ve been rewriting code to remove this bottleneck, which allows all BS products to run as a roon endpoint at their originally supported bit rate. Net, net is whatever DSP functions were there before are still there now.
We would not allow a product to achieve or maintain Roon Ready certification if something like the speaker DSP that Bluesound described were bypassed in Roon Ready mode. Nothing like that is going on here.
Allen and @Brian
Reading it again you’re right.
i don’t see why the statement refers so strongly to cost when that seems to have little to do with it.
i was reading into the DSP 24/48 being an actual limitation that they’ve had to bypass somehow.
Happy to be corrected.
As a Bluesound customer I found the almost total lack of communication about the issue during the delay highly frustrating and it made it look like there was something to hide. Highly unnecessary looking at the explanation now which could have been given (by Bluesound) at a much earlier stage.
Happy that it’s been fixed - I now have the option to use Roon to upsample to 192K before sending to Bluesound - but agree with @Scott_Fletcher that Bluesound could have been more open at an earlier stage. It confirms what I always thought (despite initial comments from Bluesound) that the issue was never a Roon problem but was caused by a setting in the BluOS (raat_only flag).
The question I now have (reading the explanation) - and it’s really a question for Bluesound (@Andrew_Haines) rather than for Roon - is whether the models affected still convert internally to 48KHz i.e. the change in 2.10.9 simply allows a range of inputs and then internally converts before feeding to the DAC and PWM amplification? If so, then this raises the question of whether it is better to use Roon to do the conversion to 48 rather than this being done in the Bluesound speaker?
Also interesting to note -looking at Roon’s product matrix - that the 3 products affected (Flex, Mini, Soundbar) were NOT tested in-house whereas those not affected (Node, PowerNode, Pulse) were tested in-house.
