I’m out for most of today so will do some more tests when i get back. I’ll eliminate one other thing that might be causing an issue - between the Core (Mac Mini) and Control (Macbook Pro) there is a wireless connection. This is ac running at about 1Gb so shouldn’t be an issue but will move kit later to eliminate that possibility.
The second set of tests (using Macbook Pro and Meridian DAC as additional endpoints) were done with 4 endpoints grouped (RPi, Macbook Pro, Meridian, Node 2). I forced conversion (44.1->48) in that order (i.e. Rpi first). Dropouts occurred within a few seconds.
This swiftness is encouraging. Bluesound will likely have to push an update to end the 48K conversion. I wonder why it was not picked up in the certification stage with roon. And all especially when this 48K conversion does not occur via the bluesound app or the nodes.
Well, I might have found out why the problem occurs (30 minutes and no dropouts so far …) and, if I have, it is somewhat intriguing.
Below is my reply on the Bluesound support site to Tony W (the problem has been escalated to Tony).
It looks like there is an incompatibility between Raspberry Pi running Roonbridge under DietPi and Bluesound speakers. Even more intriguing is that the problem doesn’t occur unless 1 or more Bluesound speakers are in the group - and it doesn’t appear when playing 192/24 files but it does when playing 44.1/16. Whether that’s something to do with the Bluesound speakers forcing Roon to convert to 48KHz I don’t know. Will do some more tests.
Hi Tony,
Whilst I want to run tests for longer to make 100% sure I think that I may have found the cause of the problem. Your suggestion about removing the Raspberry Pi did it - but in a way which is somewhat unexpected.
I had 2 Raspberry Pi systems. If I included these along with other non-Bluesound endpoints then no dropouts. If I added in the Node 2 then no dropouts again. Adding one Bluesound speaker caused dropouts, adding a second caused playing to stop.
The I did things the other way - tried with just the Bluesound kit (4 speakers plus Node 2). all was fine. Then I added in other endpoints (3 in total). Again. no dropouts. Then I tried adding the Raspberry Pis - with one all was fine but the other one caused playback to stutter and then stop.
The difference between the two Raspberry Pis is that one is using the HiFiBerry image and the other is using DietPi - and it is the one with DietPi that causes the problem.
Even more intriguingly, the DietPi system does not appear to cause any problems when playing 192KHz, 24Bit files but it does cause things to stutter and then stop when playing 44.1KHz, 16 bit files! Very odd but livable with given that (a) I don’t need to use the DietPi system at the moment and (b) I can revert it to HiFiBerry image if necessary.
As I said earlier I’ll do more testing to make 100% sure.
This just leaves the important question of why the Pulse Mini, Pulse Flex and Pulse Soundbar have a setting which appears to force ROON to convert to 48KHz but the Node 2 can accept up to 192KHz from Roon.
Feedback from Tony W at Bluesound (below). Good news (for me) is that even with the 48KHz conversion things seem to be working well here - I can group any combination as long as I leave out the Raspberry Pi running DietPi. It’s intriguing, though, that the RPi/DietPi only causes a problem when one or more Bluesound speakers are in the group.
So, can relax knowing that Bluesound and Roon are looking at solutions and spend some time over the weekend trying out the DSP / Room Correction features in 1.3. I’m impressed so far with 1.3 - particularly the speed of operation (doing background work using 4 cores yet still plays music without any problem) and also the speed of reconnection of the new iOS app - that’s a big and welcome improvement
This just leaves the important question of why the Pulse Mini, Pulse Flex and Pulse Soundbar have a setting which appears to force ROON to convert to 48KHz but the Node 2 can accept up to 192KHz from Roon.
I have forwarded this information to our BluOS Lab and they have confirmed this is one of the things we are looking at…
I unfortunately have nothing further to report until they get back to us but will have something as soon as possible as it is a priority for us.
Hey @Mike_Treatway, just wanted to let you know–I set up a device with DietPi tonight. Haven’t had a chance to do a test with it yet–but before I do, one question…
Maybe you said this earlier but I lost track of it. If so, I apologize–what are the details of that DietPi device? Which hardware is it using? Does it have a HAT, is it driving a USB DAC? If so, which one? I want to replicate as closely as possible.
Well, I don’t have any Pi Raspberries and any Flexes in my setup, but I am still having problems when trying to play through more than 1 BluOS speaker. Actually, now something really strange is happening:
As you can see in the screenshot above, in audio setup I can see 1 zone named “Memo’s Room+Kitchen”, but those are actually 2 zones. While “Memo’s Room” is indeed a Pulse Mini, the “Kitchen” is a separate Pulse 2.
The only thing I can add to this is that when I open the BluOS Controller, I can see that those 2 zones are grouped there. Does this make Roon see them as one zone? Would that mean that we should have everything ungrouped in the BluOS Controller when we want to use Roon?
I tried DietPi Roon Bridge but without a HiFiBerry…and I can’t reproduce the issue.
I had another idea for how to isolate further since I’m running out of stuff to try here.
If you swap HATs between the two Pi’s and the “bad” zone becomes the other one, you’ll have isolated the problem to the HAT.
If you swap SD cards, and the “bad” zone flips, you’ll pretty much prove that it’s a software issue with DietPi+RoonBridge.
If you swap both SD+HAT together, and the “bad” zone flips to the other location, you’ll have isolated the problem to one of the Pis.
Not sure how annoying that is for you, but it could isolate this really precisely. I’m going to try setting up a HiFiBerry Digi+ with DietPi next to see what happens. That’s one of the last moves I have available to replicate this. I hope it surfaces a problem
Hm. 20 minutes into playback and nothing funny happening :-/
I tried a few permutations, up to 6 zones, including up to 4 (not the pi or the powernode2, but all others) converting to 48kHz. Running out of ideas. Interested to hear the results of your tests on Thursday.
Back a bit earlier than expected so did some more tests. Noticed that Bluesound speakers had updated themselves with version 2.10.2 (previously was 2.10.0). So firstly did test to see if problem was still there:
a. Created group with RP1 (HiFiBerry Image), MacBook Pro and Meridian Explorer 2 endpoints. Added 2 then 3 then 4 Bluesound speakers. No problem - played fine, no dropouts.
b. Noticed that Bluesound speakers were still forcing conversion to 48KHz. Looked at Bluesound log / settings section - raat only_48000=“1” still there (so 2.10.2 hasn’t fixed this).
c. Added RP2 (DietPi). Skipped to next track after 5 seconds, then skipped another track then stopped playing.
d. NOTE - problem only happened when playing 44.1KHZ files - didn’t get any dropouts playing 48KHz or 96KHz.
e. Took out RP2. No dropouts. Put RP2 back in. Dropouts. Took out Bluesound speakers. No Dropouts.
f. Switched SD cards. Same happened as before - dropouts when I added the DietPi RPi to a group with 2 or more Bluesound speakers - so concluded that it was most likely NOT to be RPi or HAT problem (I didn’t want to disassemble RPi cases if I could avoid it).
g. Did a fresh installation of DietPi, set audio to HiFiBerry Digi, installed Roonbridge.
h. Tried again - no problems this time!!!
So, think it must have been a combination of:
(a) Possible corruption of DietPi (or some obscure setting that I had done without realising it).
(b) Bluesound speakers forcing upsampling 44.1KHz to 48KHz.
Can’t think of anything else to do (perhaps I should have kept the original DietPi image).
This has been an interesting thread to follow as I contemplate the purchase of 3 Bluesounds speakers (1 each Flex, Mini, and Pulse 2). I have confidence this will all get straightened out and I will make my purchase with that confidence for the future compatibility and functionality. Keep it coming!
I have two mini pulses, a node2 and a powernode2. We think they are great. Work well with Roon too. Once this 48K problem is gone, I’d make that purchase.
it’s your call, but I have been beyond underwhelmed with Bluesound technical support and their software quality. I was thinking of buying a Node 2 (have a Pulse Mini), but don’t want to give them any more of my money until I hear the 48KHz problem has been solved.
I had this message from Tony W (Bluesound) last week re. my support ticket on the 48KHz issue:
I have forwarded this information to our BluOS Lab and they have confirmed this is one of the things we are looking at…
I unfortunately have nothing further to report until they get back to us but will have something as soon as possible as it is a priority for us.
Thanks for your patience
Noticed (yesterday) that there was a Bluesound upgrade (2.10.2) so applied this. No change though on 48KHz issue (Pulse Mini, Pulse Flex and Pulse Playbar all forcing conversion to 48KHz - but Node 2 does not have this problem). Then noticed that my support ticket status had been marked as SOLVED!
