Is your library still being analysed after the update to 1.3?
Others above mentioned several speakers, including the Pulse Mini, which is essentially the same digital architecture as the Pulse 2. In his case above the Mini was downconverted by Roon. So, Iām encouraged by this but confused as well.
I think @brian was just using that image above to show the āup to 192Kā. There is still the issue of the fixed 48K sample rate, causing the sample rate conversion and this āEnchancedā rather than āLosslessā signal path to show. It is annoying, not seeing that āLosslessā path on a device that is capable.
I think you have it backwards. The above example was showing a file that was being UPCONVERTED from 44.1 to 48 by Roon.
The pulses (mini or otherwise) can do Native Sampling Rates 32 - 192 kHz; so just need to sort out why bluesound has put in the āraat only_48000=ā1āā The signal path should be ālosslessā.
1 Like
I donāt have a Pulse 2 but I do have Pulse Mini, Pulse Flex, Pulse Soundbar and Node 2.
The Node 2 does not have the āraat only_48000=ā1āā entry - but all of the others do.
Which only bluesound can answer as to why. Definitely a pain in the bum.
1 Like
Indeed it is. I put in a support request to Bluesound when it first happened and got a simple reply saying that the problem must be caused by Roon because the speakers worked OK with the Bluesound app.
I have just replied to that quoting the evidence here!
Have tested with speakers connected to ethernet - problem still occurs when grouping includes 2 or more Bluesound speakers. Node 2 is fine - it doesnāt have the raat_only_4800 entry in diagnostics / settings.
Hey @DuckSoup ā thanks for your patience, not trying to bounce you back and forth 
Weāre talking with Bluesound and weāll be following up with you soon. Stand by!
1 Like
Thanks. Didnāt think that you were trying to bounce me back and forth - you have been very responsive, especially with the volume of support requests you have handled since release of 1.3 (which is wonderful )
1 Like
All indications are that this will be worked out. No reason my simple brain can think of to throttle the capabilities of the Bluesound speakers!
Canāt wait to build out my music network!
Roon have always been quite excellent in this regard; the community spirit is great. I have also found Bluesound to be very good; i have had a number of phone chats and discussions, and I have always been a happy bunny by the end.
Let us hope this is resolved soon.
1 Like
Didnāt it only come out today? Both Roon 1.3 and Bluesound compatibility updates?
I think weād assume there might be the odd teething problem which will get resolved over time. Of course it needs to be fixed but Iām sure a much bigger pain in the bum would be no sound coming out at all. 
2 Likes
Well, if 2 or more Bluesound speakers are grouped together thatās what happens. It was a problem with Roon 1.2 also.
Fortunately, Roon are being proactive and talking to Bluesound.
1 Like
Hi Guys
First of all, thanks for finally integrating Roon and BluOS, I have been waiting for this for a long time now. Hopefully, Iāll get it all working soon 
At the moment, I have been able to enable all my 4 BluOS devices. Also, I can play on one of them:
But when I try to group it with a second device, I get this error message, and the music stops:
Any ideas?
Thanks
Memo
I found a few minutes today in between the 1.3 support stuff to look at this.
Unfortunately, I donāt have any of speakers with the 48k stuff with me hereāso Iām not able to completely replicate your setup, but I can simulate the Roon core side perfectly.
I did get as close as I couldāone ā ā device with no SRC to simulate your Node2, a Roon Bridge, plus two more RR devices that have been hacked to present 48k only for their capabilities (to simulate the flex speakers). Then I tried that out with each device taking turns as the master clock, in case there was a problem specific to having one as the master or slave.
I think Iāve fully covered everything that might have gone wrong on the Roon Core side. With this setup, my Roon Core is doing the exact same signal paths as yours is.
And itās perfectly stable 
Weāre going to suggest that Bluesound replicate your setup in their qa lab, because they will have all of the equipment in one place to do so exactly. Weāll be in touch with them about this.
Is there any chance your core is working too hard pumping out those four streams with the resampling? If it isnāt keeping up in some way, that could cause this kind of problem too.
BTW: We are going to stop showing the 44.1->48k step as an enhancement in signal pathāthat was an oversight that happened when we added āupsampling as enhancementā for DSP engine. Going forward, upsampling for compatibility will be reflected with a green light, whereas upsampling that you configured deliberately in DSP Engine will be treated as an enhancement. I think all of the cases are done right now, but if you see anything wrong in the next build let us know.
(cc @robdarling)
1 Like
@brian @robdarling
Thanks for finding the time to look at this. I just did some more testing and monitored CPU usage on Core (Mac Mini).
- Set playing to RPi(Roonbridge) and Node 2. CPU usage 1%.
- Added 1 Bluesound speaker to group . CPU usage 1.5%. Occasional dropouts.
- Added another Bluesound speaker to group. CPU usage 2%. More frequent dropouts then dropped out completely.
Then set up 2 additional endpoints (Macbook Pro and Meridian Explorer 2 on Mac Mini).
- Set up group of 4 in Roon (RPi, Node 2, Macbook Pro, Meridian). No dropouts. CPU 2%.
- Started to force 44.1->48KHz conversion by using Custom setting in DSP engine (with 4 endpoints still grouped).
- Setting one output - no dropouts - CPU 2%
- Setting second output to forced conversion - occasional dropouts - CPU 2%
- Setting third output to forced conversion - more dropouts and then dropped out completely. CPU 2%.
So, looks as if having 3 endpoints where 44.1->48 conversion is taking place causes problems - but itās not Core CPU running out of steam. Is there anything else I should / could check?
Even if this can be fixed it still leaves the issue of why Bluesound force conversion to 48KHz - this means, in my view, that they are not meeting specification (of accepting inputs from 32 to 192 KHz) - so will be interested to know what Bluesound say on this (Iāve put in a support request but responsiveness is not quite up to your amazing standards).
Finally, agree with suggestions about differentiating between upsampling for compatability reasons andfor enhancement. What I wouldnāt want to see disappear is the indication that upsampling (or downasmpling) for compatability is happening - seeing that prompted a look in the Bluetooth diagnostics and spotting the 48K setting.
Yeah, this is clearly not a CPU issue in Roon with those numbers. Roon is smart enough to combine the resampling work when you have multiple streams at the same rateā¦so I donāt expect scaling problems on the CPU when scaling out zones with the same sample rate.
So, looks as if having 3 endpoints where 44.1->48 conversion is taking place causes problems - but itās not Core CPU running out of steam. Is there anything else I should / could check?
Hm, Iām up to six on my macbook pro, all doing forced 44->48 conversions, and itās looking OK. I have an older (~2013) mac mini I could try, but with such low CPU %'s, Iām doubtful that thatās your issue.
Is there anything else I should / could check?
Try to reproduce this with the BlueSound device out of the picture, but with the conversions. If that breaks for you, it might at least simplify whatās involved in tracking this down for us.
How long does it take for dropouts to appear when you run these tests? Minutes? Hours?