More > JRiver Media Center 32 for Windows

Volume protection lags when using MCWS/v1/Playback/Volume

<< < (3/3)

Matt:
Trying to turn up 10% 10 times a second is simply faster than you're allowed to go.  Turn off volume protection if you don't like it slowing you down.

mattkhan:
I'm testing according to the stated specification and, as I said, there are 2 things that just don't work as stated. It's precisely why I test like this, to see if it actually works to protect the user.

All I'm doing is simulating the behaviour of a UI which has a slider for the volume control and some buttons for fixed steps. Since it has buttons then I can mash them rapidly and I can move a slider a long way quite happily, MC protecting my ears from fat fingers is a good thing.

IMV having a time based throttle as well as a request based one is v sensible and I'd like it to work as stated. I'd even like a slightly richer version (in which it clamps more aggressively above a certain volume level) but didn't think it was important enough to me to even ask for that :)

Hendrik:
The 20% per second does exist (its really more like 5% instant and 20% per second for 3 seconds), but it doesn't quite work like a limit, but rather scales the increase by time passed since essentially the last request.

If you request any increase, and 0.15s second passed since the last increase, you get a 20% * 0.15 seconds = 3% increase at most (eg. min(3%, request))
The first request goes through unlimited (other then the 5% per request limit), afterwards you get the 20% per second limit, for 3 seconds. The first request can't really be time-limited as it has no time window.

Of course you also can't go above 5% per request, so to exhaust the limit you need 5 requests per second (an initial one to kick-off the timer, and 4 more to consume the 20%).

So what you are seeing in the 100ms scenario seems sensible to me. The first request gives you full 5%, afterwards you are limited to apparently 3% per request (rather then 2%), which might be accounted for by response time of the MCWS calls spacing them slightly over 100ms.
Maybe logging with timestamps at the responses might be clearer.

I think the gradual limiting of requests is much more sensible then giving you 20% in less requests and then stone-walling the requests until the timer expires. Of course it assumes there is more requests coming, but protection is designed for a user-interaction scenario, so there usually are.

mattkhan:
Ok fair enough, problem is fixed then. Thanks!

mattkhan:
I think the 20% per second rate limiter should be made more restrictive as being able to go from 0-80% in 4s seems pretty aggressive though this is very much a system dependent setting as it depends on what sits downstream of MC.

In my case, I set the max to 80% as this is just a shade beyond reference. It means that, in normal use, I wouldn't expect someone to go beyond ~60% but when you want to let her rip then the headroom is available. I think the current setup in MC is such that I should likely set the max to something more like 65% and then manually edit that when I want to go beyond that.

It's a little clunky. It would be nice if there were a way to control that limit remotely or some form of "sound mode" that one could set to change such limits.

I appreciate this is a niche use case :)

Navigation

[0] Message Index

[*] Previous page