Options
Runaway Volume
Joe Hebert
Posts: 2,159
What do you all do to avoid volume runaway when ramping volume especially with the R4s? If the user presses and holds a button and we don’t see the release we’re pretty much SOL. The offline event for a TP or R4 doesn’t seem to trigger fast enough. Or is it just me?
The only thing I can think of besides cancelling a volume ramp when the TP or R4 drops offline is to only ramp volume x number of steps (using TIMELINE.REPETITION) before cancelling and make the user press and hold the volume up button again. I’m not too crazy about that solution but I’m out of ideas.
Whenever possible I also have the installer set the max gain of the device distributing the audio to a value that doesn’t blow out any speakers.
Thoughts? Suggestions?
Thanks.
The only thing I can think of besides cancelling a volume ramp when the TP or R4 drops offline is to only ramp volume x number of steps (using TIMELINE.REPETITION) before cancelling and make the user press and hold the volume up button again. I’m not too crazy about that solution but I’m out of ideas.
Whenever possible I also have the installer set the max gain of the device distributing the audio to a value that doesn’t blow out any speakers.
Thoughts? Suggestions?
Thanks.
0
Comments
In the hold event handler I just use an if(button.holdtime > 5000) type of thing with a do_release(tp,btn) below. Else would handle the repeating hold command.
That is the same solution that I have come up with as well.
That will help but doesn't solve the problem since if the volume is already quite high and the user presses and holds the volume it will continue for 5 seconds still. Can you not do the release in the offline event? Or is the offline event being delayed and allowing ramping to occur until it occurs? There really should be no way for this to happen in the firmware. AMX should fix this so that all buttons get released when an R4 loses its connection or the connection stalls.
Paul
At the low-end of the function scale I basically don't allow holds in general. These are gear that doesn't have much control over ramping or good old fashion IR control They just hit the up/down button until they get where they're going.
For gear that has fast feedback and the ability to do more than one ramp speed, I do a first hit jumps slow and quick hits right after it ramp faster.
So, hit hit hit hit hit means it's way too soft or loud and I'm in a hurry to adjust the volume.
But hit (wait) hit hit (wait) hit is more a person just rying to tweak the level. So, I keep the ramping slow and precise.
Of course it doesn't have to be 5 seconds either. It depends on your repeat intervals and how much you choose to step each repeat. It's basically just a safety relief valve that is just as useful for those times when someone or something (dog, cat, rat) sits on the remote and doesn't realize the increasing noise is becuase they're pressing the vol btn on the TP or remote under their a$$ or paw. That's one benefit of IR over RF, our fat a$$es usually blocks the IR.
You could do the release in the offline but as Joe mentioned in his OP that doesn't always seem to happen right away. Plus that won't help with the accidental "holds" when there is no release and there won't be an offline event. I use this method regardless of the UI being an R4 or not and IMHO there's no reason not too even if you want to add something in the offline. The more safety valves the better.
We do similarly to what others suggested here. We have a maximum repeat that equates to about 12% volume when applied to any given AVR/MR/TV volume device (calculated against the increment for the device - some are too slow to increment in 1%) or five max repeats for non VOLUME items. Then we do a forced release. Waiting for the offline is too late.
This is good for customers anyway, as a button can stick, or a book is set on a panel, or they carry it wrong, and 100% volume is not healthy for a business relationship either. We also put in room-by-room volume limits (with bypass exemptions for specific users by permissions if desired).
I have only had a couple of rare complaints about this issue over many projects, so I haven't put that much time into looking at it. I tend to try and avoid this problem rather than work around it since its so annoying. I have offered the rare client that has experienced this to change the ramp so that you can only ramp for a few seconds at a time, but all have refused. I think a lot of people like to play with the volume and since its so responsive they get a kick out of it compared to their typical IR remote so I don't want to disable the system just on the off chance that the volume might ramp. Besides, we sell more speakers this way
Paul
Ive never been a big fan of signee anyway. It's klunky and slow.
Imagine being able to upload an R4 over the network.
Yeah, wouldn't that be a trip. Actually it wouldn't cuz then we could do it remotely
Maybe the upcoming infocom release with have a wi-fi remote and then the whole zigbee thing can be eliminated from AMX completely, unless they want to do zigbee sensors or other low bitrate type devices. IMHO it never should have been used for a UI that requires medium to heavy traffic. Well maybe not "requires" but definitely should be capable of medium to heavy traffic to tap the potential an AMX wireless remote should have.
But WIFI+24/7 on time=short battery life.
That's why they did Zigbee in the first place. I get nearly 2 weeks between charging my R4 with daily use. You can't leave a WIFI active overnight off the charger. An 8400 will shut down and need a restart/reboot in the morning. A 5200 will just peter out and be dead. Not even if it's an iPad. The iPad turns off the wifi when it wants to, that's how it lasts for days. That's not acceptable for a dedicated remote...
Just sayin, there's a reason, and a consequence to the decision. Do you want battery longevity or remotable load? Can't have both today, and it's not because of a stupid design.
How about a hybrid system?
If you think about how many local systems only use a 5200 or 8400 for control? Those users seem to adapt and cope with that battery life. A lot of my customers don't use the systems for weeks so if they leave the remote undocked they're still SOL anyway even with the current battery longevity so they should complain cuz it doesn't last years like a standard remote. I think if you pay big bucks for a remote system you should get a little bang with those bucks and the R4's kinda make you feel like you didn't get the dinner and the movie, just went straight to getting... If you get my drift. Ok, it's not really that bad but it could be alot nicer.
Ha! another example of the iPad auto correct winning the day!
Regardless - it's funny how many cell phones, and smaller devices can have WiFi and people do not complain much about their battery life, or as vining has pointed out, adapt to it. I've been hoping for an R-5 that'd have WiFi since the R-4 came out.
Not to mention that with wireless N and current up-to-date wi-fi equipment there's no reason wi-fi couldn't suffice. The connection speed is almost instantaneously. Not to mention the possible use of lower power wi-fi transmitters. Laptops tend to have 300mW wireless transmitters while things like phones and iPads have 150mW transmitters.
On pick-up the first thing the remote would need to do is reconnect. For that to work though it will need to recognize picking up really quickly. Again something that isn't impossible with current tech standards. AMX just needs to incorporate those into one slick little remote. (and perhaps a better battery-pack)
Back on topic, I have used the HOLD event to force a release as well. 2-3 seconds depending on the ramping speed.
It seems like the majority that responded have some sort of timeout for volume ramping and while it’s not an ideal solution it appears to be our only viable option.
Volume runaway is not a problem I would want to just sweep under the rug and ignore. It may only happen rarely but when it does it can be quite embarrassing. If I was a client and the volume ran away when I was showing off my million dollar+ system to friends or when the baby was sleeping, I’d be pretty pissed about it.
So either we throttle the volume ourselves or just let the volume rip. We can brag to our clients how fast we can go from 0-60 although by the way there is a slight chance the accelerator will stick and the car will reach 300 and blow up. But we’d be happy to sell you a new car if it does.
If we could keep these devices connected that would be Utopia.
Thanks to everyone for their feedback.
There are other options. Four things seem to cause this problem most often:
1) Devices falling offline while ramping, which can be minimized or even abolished with careful planning and execution.
2) Inefficient code that hogs the cpu or too much define_program code causing events to get backed up in the message queue and then executed after the button is released.
3) Sending too many events to the processor during a hold causing events to get backed up in the message queue and then executed after the button is released.
4) Sending events in a hold faster than the preamp can execute them causing command buffering in the module/device.
Since all these issues are preventable, having volume ramping is avoidable in most cases, requiring a workaround only in suboptimal installations.
I tend not to worry too much about freak accidents like pets standing on the volume control or a remote getting stuck in between couch cushions, since its never happened in my 7 years of AMX programming. If it ever does I will come up with a solution for that client should they want one to prevent this.
Paul
I remember one call from a furious and frantic customer years ago with the system blasting away. He'd broken his CP4a and had spent 20 minutes of aural agony while trying to push the wires together to turn down the volume before calling me... I asked him to press STOP on the DVD player. He started to say something... then a few seconds later, blessed silence. How quickly and completely people forget there are still manual ways to operate their system.
if(i_volume < i_max) { i_volume++; send_string-blahblahblah }You can easily do swap it around to a minimum volume level too, that way they never can really ramp it to zero, but just have it really quiet; this way if it ever does ramp down, at least they'll be able to hear it and not say "Well, all of a sudden, I gradually lost audio - and now it won't work at all." and then you're out there chasing your tail possibly thinking the device went bad.
If it's caught in a loop, or a runaway volume - it'll stop at a predetermined value. I should mention that I do know the "risks" involved, say for instance having a receiver in the open and then a client manually changes the volume, then when they go to change the volume with the panel it'll drop down to what software thought it was supposed to be. Easily fixed by capturing the volume feedback if available. But to be honest, in the short six years I've been doing this - I've yet to see someone do this and if they have, I've never heard a complaint. Also, there are no volume knobs on a lot of the switchers out there, mainly just receivers - so I'm not too worried about it.
You bring up a good point about setting a max volume via software (which can be done with vol +/- commands just as easily.) So aside from a timeout we also have the option to do a do_release or stop a timeline when we see that the volume has reached our predetermined max level. Good idea.
As far as the volume level going to zero I just turn on the mute button when that happens.
I would much rather have a properly implemented WIFI remote with slightly lower battery life than a mediocre implementation of Zigbee.
Everyone of my clients with R4s put the remote back on the charger when they are done using the system, so we really only NEED 12 hours or so of battery life. We talk about the charging cradle concept as a selling point from day one. It is a way to always know where the remote is and a way to always have the remote charged and ready to go every time it gets picked up.
I would also much rather put the money that we spend on Zigbee gateways and receivers into 1 or 2 more WIFI access points with a Ruckus Controller to really offer a kick *** wireless network.