rooDial a Wireless Volume Knob for Roon with Microsoft Surface Dial

Then it would depend on the order in which you group zones :slight_smile:
If you added kitchen to the living room the result would be different than if you started with kitchen and grouped it with living room.

But of course let’s look for the best idea!

That’s the point of my proposal. It’s not an undesirable side effect, it’s the point.

I love the way you guys share your expertise ! Does anyone know if the SpaceMouse setup would sidestep this issue and allow for device control to remain in the Zone it was initially assigned to, even after the Zone is added to a group?

The reason why I was asking this is to avoid someone in the Kitchen turning up the volume for themselves and unknowingly also for my beloved 2 channel system in the Living Room (after it was grouped with the Kitchen).

In all likelihood, the Living Room might already be at an elevated listening level. From what I’ve read here, the simplest thing to do is to set the Max Device Limit (aka Volume Limit) in Roon for any endpoint which might potentially be grouped and controlled with the MSD. (In my case set the volume limit for the Living Room endpoint)

Is this approach reliable, or is there a possibility for the MSD to dial the volume past the Device Max Volume Limit after it has been set up in Roon?

Well, this is an extension, not core Roon software. I’d suggest you run a controlled experiment, you seem to have the edge cases worked out. No guarantees this works as you want it to, but I think different people will have different expectations. I, for one, wish I could set it up so my primary 2-channel rig could never be grouped so that there’s no inadvertent mucking about. Not sure how RooDial will intersect with volume limits on individual zones when grouped, but it’s worth a try.

I can’t imagine you’ll see different behaviors across the SpaceMouse, Surface Dial, or Nuimo given that they are all on the same codebase and have the same basic set of operations (though SpaceMouse and Nuimo can do more than the Surface Dial given their additional control capabilities).

I would only answer this question if I were absolutely confident that I knew how things worked. I wouldn’t want wrong information to lead to harm to your eardrums or equipment.

What I can tell you is that Roon supports “Comfort” and “Safety” limits. Roon might allow extensions to programmatically push volume past the upper comfort bound. You could argue for it to allow or disallow that - that just seems like someone at Roon needs to have an opinion about what the right behavior is and then implement it that way. But Safety seems like a hard boundary that an extensions shouldn’t be allowed to push past. If you test this out and find that RooExtend (in any mode whatsoever) can push volume past a device’s upper Safety boundary, then that seems like a serious Roon bug that would require attention. Your best bet, as @Johnny_Ooooops suggests, is to test it out and share why learn!

That’s what I figured, but it was worth asking!

So far, so good. The MSD does not turn the volume in the living room past the Safety Limit I set for it in Roon. If I want to go above that “Safety Limit” , I can use the IR remote to turn up the volume on the Living Room DAC. This should limit any issues with harming eardrums or equipment :slight_smile: . I will have to give some thought to setting practical device limits for my other devices as well, just in case.

Thanks for the suggestions @gTunes and @Johnny_Ooooops.

1 Like

Sincere “Thanks!” for experimenting with this and sharing what you learned. This is great info.

@Markie_Sitar

This works for me now with rooExtend. I can control my KEF Wireless 50s using Surface Dial and SONOS (just in Living Room) using Roo6D. The way to configure this is to set:

  1. Zone follows playback = No
  2. Change volume at playback only = No

Enjoy!

EDIT — I would add #2 is one of the best features or at least top 3 IMO. To be able to remote control any roon connected speaker with respective control when NOT in roon. Priceless,

1 Like

I’ve searched this topic but can’t find the answer to my problem. My surface dial wont pair with my Raspberry Pi Zero W.

I found that the pairing window in the Pi is only a short period after booting. So I start the pairing as soon as I see rooExtend appear in my Roon Core. The dial is not paired with any other device. Still it wont pair. What am I doing wrong?

Any help would be much appreciated.

Never mind. Found it after 2 hours.

For who ever runs into this problem
In Roon:
Extensions > rooExtend > Settings > hide unlicenced extensions > No
Enable rooDial

1 Like

This happened to me too, 2 hours also in my case. I think the documentation should be updated at some point when Dr C is back. In the meantime, sorry I didn’t get to you before you figured it out yourself. Welcome!

I will add this to the documentation if I am back

Best DrCWO
From Africa, Sansibar

Hi all, fairly new user RooDial user here. Running the latest RooDial v1.54 and RooExtend v3.0.6 version installed on a Raspberry Pi 4 Model B Rev 1.5. The Pi 4 is connected via Ethernet.

I’m running Roon via latest version of ROCK on an HP G800 MiniPC which is also connected to the same Ethernet switch as the Pi 4.

I bought a new Surface Dial, it paired with RooDial first time and works great 99% of the time to control my NAD Amp defined as an audio device in Roon…Volume Control on this is set to “Device Volume”.

However, every so often when I very slightly rotate the dial anti-clockwise to reduce the volume slowly (normally set to between 75-85), the volume drops immediately to 0 and I have to turn it all the way back up. The Surface Dial is still always connected/paired during this time…immediately after occurring the volume dial works as normal.

I think this has also happened once or twice when rotating clockwise to increase the volume as well…but seems to occur more often on an anti-clockwise rotation.

This has occurred when Rotation Sensitivity is set to 34 and also 17.

It’s easy to recreate the issue, so got it to occur 3-4 times over a 5 minute period by varying the volume frequently throughout a couple of songs…the System Log doesn’t show much info at all…not sure if I can put it into “debug” mode or something to capture more info (i.e. show it detecting rotations and changing volume etc.).

Jan 31 14:05:30 rooExtend rooExtend[101872]: ***** startEventCapture
Jan 31 14:06:41 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/html: /tmp/selfgz101453/www/log.html
Jan 31 14:06:41 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/css: /tmp/selfgz101453/www/site.css
Jan 31 14:06:41 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/javascript: /tmp/selfgz101453/www/site.js
Jan 31 14:06:41 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/css: /tmp/selfgz101453/www/site.css
Jan 31 14:06:41 rooExtend rooExtend[101709]: Request from: 192.168.1.100 image/jpg: /tmp/selfgz101453/www/images/rooExtend_500.jpg
Jan 31 14:06:42 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/html: /tmp/selfgz101453/www/favicon.ico
Jan 31 14:06:42 rooExtend rooExtend[101709]: SEND 404
Jan 31 14:06:58 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/html: /tmp/selfgz101453/www/log.html
Jan 31 14:06:58 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/css: /tmp/selfgz101453/www/site.css
Jan 31 14:06:58 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/javascript: /tmp/selfgz101453/www/site.js
Jan 31 14:06:58 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/css: /tmp/selfgz101453/www/site.css
Jan 31 14:06:58 rooExtend rooExtend[101709]: Request from: 192.168.1.100 image/jpg: /tmp/selfgz101453/www/images/rooExtend_500.jpg
Jan 31 14:09:25 rooExtend rooExtend[101709]: Request from: 192.168.1.100 text/html: /tmp/selfgz101453/www/log.html

I’ve had a look through some of the previous posts for the last 2-3 months and can’t see anything similar being reported.

However, I did find a post from Eddie_F that talks about Volume Control issues, but in his case it appeared his volume went to 100 not 0!

Interestingly enough we are both using NAD pre-amps (I have a NAD C368 and he has a NAD C658) and ROCK so not sure if that’s just a co-incidence or there’s a common denominator there.

Just wondering if anyone else has experienced this?

Cheers,

Chris

This looks strange to me. There is one known issue that sometimes the Dial speeds up a lot so with the slightest rotation it jumps to 0 and back to 100. This is caused by a Linux driver error that is known since a long time but still not fixed :cold_sweat:

If you encounter it the next time please immediately after the issue get the complete system log and e-mail it to info@definiteaudio.de

Edit: Did you use rooUPnP for the NAD?

Best DrCWO

Thanks for getting back to me. With regards to the “Complete” system log, did you mean just the log.html file or is there another file with more debug data?

I can recreate the issue quite easily as it’ll occur within a couple of minutes if I repeatedly vary the volume. I’ll reboot the Pi and the ROCK PC, then generate the error and send through the log…although there’s not much detail included in just the log.html file.

Regarding the NAD…I am actually connecting directly from the Roon ROCK server to a NAD M51 DAC via USB…then the M51 connects to the NAD C368 amp via RCA.

I did have RoPieee setup as an EndPoint for the NAD M51, but repurposed it for use as the RooExtend server so no longer use that.

Yes, this is what I like to see…

Emailing it through now. I also got a video of it occurring which I’ve uploaded to YouTube so will send a link to that as well.

1 Like

I debugged your described issue and can confirm your writing. with v2.3.x it reconnects immediately, with v3.0.x it takes more than two seconds. As I thought this is an issue with bluez 5.55 when reconnecting to HID API which I had to use. I opened an issue here and here. Let’s wait what will happen. I fear there’s not much more what I can do at the moment.

In future I plan to move to DBUS API for rooDial which also should fix this issue. But it is really bad that this happened after migrating to ARMv8 and DietPi…

Best DrCWO

3 Likes

Thanks for following through, @DrCWO – much appreciated.

1 Like

Thanks for following up, @DrCWO.

I hope your holidays were great!

I’m comfortable staying on the 2.3.x tree for now, since it works flawlessly for me and I don’t use features that are specific to 3.0.x. I believe this should work fine unless your license server stops validating 2.3.x installations. I hope you don’t do anything that forces users to upgrade until you’re able to address the issue. Thanks again!

1 Like

Force is not my way to handle things. Stay cool :wink:

3 Likes