Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

I've noticed irregular volume stepping when volume protection is on, for example if I hit MCWS as fast as I can then it's just totally broken

Code: [Select]

curl 'http://localhost:52199/MCWS/v1/Playback/Volume?Level=0' 2>/dev/null|grep Display; for i in {1..8}; do curl 'http://localhost:52199/MCWS/v1/Playback/Volume?Level=0.1&Relative=1' 2>/dev/null |grep Display; done
<Item Name="Display">0%</Item>
<Item Name="Display">5%  (-77.5 dB)</Item>
<Item Name="Display">1%  (-97.6 dB)</Item>
<Item Name="Display">1%  (-95.3 dB)</Item>
<Item Name="Display">1%  (-93.4 dB)</Item>
<Item Name="Display">2%  (-91.6 dB)</Item>
<Item Name="Display">2%  (-89.7 dB)</Item>
<Item Name="Display">3%  (-87.8 dB)</Item>
<Item Name="Display">3%  (-86.0 dB)</Item>

if I add a delay similar to a human mashing a button on a remote control then it's a bit more sensible but still broken

Code: [Select]

DELAY=0.25;curl 'http://localhost:52199/MCWS/v1/Playback/Volume?Level=0' 2>/dev/null|grep Display; sleep $DELAY;for i in {1..8}; do curl 'http://localhost:52199/MCWS/v1/Playback/Volume?Level=0.1&Relative=1' 2>/dev/null |grep Display; sleep $DELAY; done
<Item Name="Display">0%</Item>
<Item Name="Display">5%  (-77.5 dB)</Item>
<Item Name="Display">6%  (-73.2 dB)</Item>
<Item Name="Display">11%  (-53.6 dB)</Item>
<Item Name="Display">16%  (-46.1 dB)</Item>
<Item Name="Display">21%  (-39.5 dB)</Item>
<Item Name="Display">26%  (-37.0 dB)</Item>
<Item Name="Display">31%  (-34.5 dB)</Item>
<Item Name="Display">36%  (-32.0 dB)</Item>

if I increase the interval to 0.5s then it works reliably

if the intent is to limit the rate of volume change then it's clearly not working because it still mostly honours my requests with 0.25s delay just gets the odd request wrong whereas if you go faster then it's just totally broken.

I'm not sure what the intended behaviour is here but producing arbitrarily incorrect increases is not helpful, simply limiting the max increase to 5% in a single request seems reasonable but it should do that reliably.

[mattkhan]

btw, the pattern shown in the 0.25s delay case is repeatable, it always gets that 2nd request wrong and it happens as soon as the requested change approaches the limit

e.g. Level=0.04 produces these steps

Code: [Select]

<Item Name="Display">0%</Item>
<Item Name="Display">4%  (-82.0 dB)</Item>
<Item Name="Display">6%  (-74.0 dB)</Item>
<Item Name="Display">10%  (-56.0 dB)</Item>

whereas Level=0.03 works produces the correct step

[Matt]

Limiting won't let you go up more than 5% in a single call and limits you to 20% a second.

[mattkhan]

You can see it's not doing that in my log output

It makes 2 requests to go up by 5% each time with a 250ms delay and it applies just 1% increase on 2nd request, another request 250ms is allowed the full 5%. With no delay, it's just completely broken and the subsequent requests even reduce the volume. Based on your description it should allow the first 4 requests till we get to 20% and then do nothing.

[mattkhan]

https://yabb.jriver.com/interact/index.php/topic,138200.0.html would also help here so we know when we are clamped

[Matt]

I'll adjust this a little for the coming build.  We would store the starting volume, but it was the start before the pending volume change.  I'll switch to storing the volume after the pending.  It looks good in my testing now, but double-check appreciated.  Thanks a lot for the help.

[mattkhan]

Great thanks, will test when the build surfaces

[Matt]

Let us know how it's working.  All the changes I made are in build 20.  Thanks.

[mattkhan]

thanks but it's still a problem if you update more rapidly, e.g. MCWS/v1/Playback/Volume?Level=0.10&Relative=1 every 100ms produces

Code: [Select]

<Item Name="Display">0%</Item>
<Item Name="Display">5%  (-77.5 dB)</Item>
<Item Name="Display">8%  (-63.9 dB)</Item>
<Item Name="Display">11%  (-53.4 dB)</Item>
<Item Name="Display">14%  (-48.6 dB)</Item>
<Item Name="Display">17%  (-44.0 dB)</Item>
<Item Name="Display">20%  (-39.8 dB)</Item>
<Item Name="Display">23%  (-38.3 dB)</Item>
<Item Name="Display">26%  (-36.8 dB)</Item>

based on the earlier description of max 20% in one second then I'd expect it to go 0-5-10-15-20 and then the remaining requests are a nop but instead we end up at 26% and instead each request after the first is reduced in magnitude

[mattkhan]

with a delay of 200ms between calls, I just get 5% per call

Code: [Select]

<Item Name="Display">0%</Item>
<Item Name="Display">5%  (-77.5 dB)</Item>
<Item Name="Display">10%  (-55.0 dB)</Item>
<Item Name="Display">15%  (-47.5 dB)</Item>
<Item Name="Display">20%  (-40.0 dB)</Item>
<Item Name="Display">25%  (-37.5 dB)</Item>
<Item Name="Display">30%  (-35.1 dB)</Item>
<Item Name="Display">35%  (-32.6 dB)</Item>
<Item Name="Display">40%  (-30.1 dB)</Item>

in short, there are 2 problems

1) if you hit it too quickly, MC reacts erratically
2) the stated 20% max in a single second (measured from when? presumably the 1st call as opposed in an actual walltime second?) does not appear to exist

[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