This is a minor issue, but I’ve noticed when I use command-option up arrow or down arrow on my Mac Pro, the volume goes in 5 unit increments as in previous versions, but occasionally the volume appears as 31, 36, 41 and does not remain in the expected 30, 35, 40 levels. If I decrease the volume to 1 and then down once more to 0 and back up, it’s remedied.
Well, its meant to do a +5 or -5, not a snap to value. I’ll throw this over in feature requests.
Hi Danny, I don’t expect the volume control to snap to values, but it seems to get incremented by 1 on its own. I didn’t see this behavior prior to version 1.1. And yes, I do expect a +5 or -5. It does that properly. I just don’t know how it gets off by 1. I hope that makes sense!
i have been trying to reproduce this and cant. I’ll have the QA team try. Thanks for letting us know.
I figured out what is happening. The system volume was being adjusted by other programs. In previous versions, Roon’s volume would only changed when chenged within Roon. Now, the volume is synchronized with the system volume. The +5 / -5 up or down is working correctly within Roon. Is there a keyboard shortcut to increase or decrease volumen in units of +1 / -1.
are you using mediakeys on your keyboard? in roon 1.1, we added support for keyboard drivers that send WM_APPCOMMAND instead of a keystroke.
ugh… ignore me… we dont do mediakeys support for volume, only playback
I seem to be having the same issue again. I noticed that when I hit play/pause button, sometimes the volume level increases by one unit from say, 30 to 31. I am using Roon on a Mac Pro with Audioquest Dragonfly.
I’m experiencing this issue, very annoying.
Setup: 13" rMBP running OSX 10.10.5 and Roon 1.1 build 55.
To reproduce:
- Select a volume value between 37 and 45
- Play a song, wait until it starts playing.
- Advance to next song using the media button. Volume goes down a tick. (NOTE: not adjusting volume, literally advancing the song is causing the volume to go down)
- Wait at least a couple seconds, advance to next song, volume again goes down a tick.
- Keep repeating, volume will eventually crest at 36 and stay there.
This happens consistently for me upon successive reboots, various sources (including just system/headphone out). Sometimes I do see it sporadically where it will go down just one tick at other volume levels.
Hey @disneymike – we are looking into reproducing what you’re describing with the Dragonfly.
@brandall10 – can you tell us a little more about the outputs you’re using? @vova and I will look into this using the steps you listed above and try to reproduce, but the more you can tell us about the outputs, the more likely we can actually see it happen and address it.
Let me know the details and we’ll proceed with testing on our end as well. Thanks for the report guys!
I’m experiencing this with all outputs I’m currently using which are
System output
Headphone out
Concero HP (a DAC I use for headphones)
Thanks, Mike. I get the behavior if I pause and then replay a track. The volume increments a unit.
Have you tried confirming the issue I’m having? In my case it’s notintermittent, it is repeatable every time. I just select a volume from 37-45, then change tracks and watch it decrement by one. It keeps decrementing until I hit 36. Doesn’t seem to care about source.
No, I can’t reproduce that consistently. Mine seems random. I change a few songs, or select different albums and the volume increments. It happens almost every listening session.
More information:
- I don’t need to use the media keys to get this to happen. It happens just switching a song in the Roon interface (ie. clicking the forward/backward buttons with my mouse). So the issue appears to exist entirely in Roon, there is no outside influence.
- I deleted my existing Roon copy and re-downloaded. No dice, it still happens, consistently, everytime without fail.
- I installed Roon on my girflriends laptop (similar machine, 13" rMBP), connecting to my machine. It happens for her as well. Again, this is consistent, 5/5 tries it happened on her machine, not once did it not decrement the volume when switching songs with a volume between 37-45.
The only variable left is using another machine as a server, but this is a UX issue. From where I’m sitting I would be surprised to find this not happening on every copy of Roon OSX 1.1 build 55, but @disneymike reports not so I’m really scratching my head here… if it’s not clear what I’m doing I’d be happy to take a youtube video and upload it.
In any case this has become annoying enough that I’m opting to not use my Concero DAC until it’s resolved (I tend to listen around volume level 40 on that for my JH Audio Roxanne earphones, headphone out more like ~20).
Ok, guys – thanks for all the extra info here.
We’ve found one set of solid reproduction steps, so we’re logging this as a bug and will be including a fix in a future version.
Sure, no problem.
One thing to keep in mind is there may be two different issues here - there is the repeatable one I’m reporting within a specific volume range, and then there is the one @disneymike is reporting which is intermittent at seemingly any range (I’m experiencing this too, but can’t provide a repeatable use case). While they are likely related / have the same root cause they could be two different issues.
Ok, this is a little bit tricky. We are planning to fix this for the next release.
Anyways, what’s going on is:
We tell your device “go to volume X”. It silently goes to volume Y instead. Then at a later point (one of these points is just before beginning playback, or unpausing), we re-sync to the device’s current volume and the value “snaps” to whatever your device decided that it should be.
This problem is device dependent. The AQ Dragonfly appears to support 50 discrete steps, not 100, and odd numbers turn into the even number one above. The built-in output on my mac appears to be doing something more complex (my guess: converting a scalar gain in [0.0,1.0] to dB, rounding or otherwise losing precision in dB space, then converting back). I also have several devices here that seem to preserve the volume exactly as it was passed in, and others that do modify it, but have enough resolution to make the behavior irrelevant.
OS X’s volume slider doesn’t have a 0-100 number on display–so any device-level snapping of values would be un-noticeable.
"This problem is device dependent. "
Brian, did you read my reports above? I get the same thing to happen w/ headphone out, system out, and a Concero HP. It happens everytime I switch a song when the volume range is 37-45, decrementing the volume by one. Everytime.
All the same I understand the issue @disneymike reports may be different and you may be speaking to just that. If I need to open another thread to report this as a separate issue so it is filed please let me know. It’s bad enough that I can’t use my main DAC with this application (not because my Concero is causing it, but because it happens in the volume range I listen at for that DAC and my earphones). And as offered above, if you can’t reproduce this or it’s not clear what I’m doing I’m happy to upload a video demonstrating the issue.
I tested with about a dozen pieces of hardware from a variety of manufacturers and driver vendors.
I found devices here that fall into four categories:
- Devices that don’t touch the number at all
- Devices that modify the volume number and have sufficient resolution to roundtrip values from 0-100.
- Devices that modify the volume number and have too little resolution to roundtrip values from 0-100.
So yes, I think device dependent is an accurate way to describe this problem.
Your issue where the volume decrements repeatedly is happening because the resolution mismatch is particularly unfortunate, and because there’s a floor() operation involved, so a slight rounding error is barely missing the requested value each time, then being truncated down to the next integer value. Each time we re-read the volume from the device (something that we do when you switch tracks), it happens again. Some numbers are inherently stable, just because of the mathematical relationship between our concept of volume and the devices. I saw very similar behavior on one of the DACs I tested (though the stable number was not 37, it was something else).
Anyways, the fix for @disneymike and your situations is the same: break the feedback loop between our concept of volume and the device’s unless there was actually an external volume change. This is what’s going into the next release.