News for hackers. Stuff that matters.
Re:We need physical audio kill switches by mindslight on Sunday September 20, 2020 @03:46PM (#24536790)
The biggest problem with "modern" digital controls, the lag, is completely avoidable. One can easily design a system using a microcontroller that responds within 10ms, which gives the appearance of being instantaneous. It's all just shoddy software engineering using bloated frameworks and poor languages, and consumers that don't know any better. Somehow we've had this problem going on a decade, and nobody has seen fit to shape up their development process.
Re:We need physical audio kill switches by closeparen on Sunday September 20, 2020 @04:06PM (#24536958)
What languages and frameworks are people using in consumer electronics?
Re:We need physical audio kill switches by mindslight on Sunday September 20, 2020 @04:27PM (#24537117)
I have no idea these days, but it's clearly something that takes 100ms+ to process an input event (java? html? flash? all of the above?). Responsive encoders/buttons/displays were doable 15 years ago with 5 MIPS microcontrollers in C. Driving an HD44780 character LCD is easier than a full raster display, which explains the appeal of the bloat, but quick sprites etc should be completely doable after two decades of progress.
Re:We need physical audio kill switches by Gibbon1 on Monday September 21, 2020 @01:15AM (#24540050)
I have two thoughts. One is an overloaded CAN Bus. Some process is polling the switch every 100ms. The second is the process itself isn't allowed to run very often because it's sharing CPU time with a bunch of critical stuff.
Re:We need physical audio kill switches by hvidgaard on Monday September 21, 2020 @03:23AM (#24540723)
Either way, a car ought to have two separate systems. One for critical functionality, and one for controlling the radio, climate controls, windows and the like.
Re:We need physical audio kill switches by mindslight on Monday September 21, 2020 @10:14AM (#24543723)
No switches should be getting polled over a CAN bus. If there's enough of a processor to be a CAN node, there's enough processor to debounce a button and transmit state change events.

Sure the situation might exist, but it's exactly the kind of bad engineering I'm calling out.

Re:We need physical audio kill switches by GoToRO on Sunday September 20, 2020 @05:19PM (#24537510)
Autosar for automotive. The delay is a requirement and not really due to the framework.
Re:We need physical audio kill switches by mindslight on Sunday September 20, 2020 @06:25PM (#24537955)
Um, what? What kind of requirement of that? The UI lag on modern cars is a safety hazard.
Re:We need physical audio kill switches by GoToRO on Monday September 21, 2020 @06:13AM (#24541644)
I’m not sure what lag are you refering, but on physical buttons there is a minimum of 50ms - 100ms required by the customer.

I guess is the same as on iPhone where if you hold backspace, it will not zap all the text, but go one by one with a visible delay. These companies simply treat end users as babies.

Re:We need physical audio kill switches by mindslight on Monday September 21, 2020 @10:04AM (#24543588)
A good rule of thumb is that anything over 10ms response appears laggy (not instantaneous) to a user. This is especially dangerous on touchscreen inputs, as they lack tactile feedback and therefore require the user to focus on the display until their input has been acknowledged.

I can't tell the specific concept you're talking about though. If it's the auto-repeat rate (your iPhone example), then of course there needs to be a delay before that kicks in, and a steady repeat rate. I'm talking about single button presses.

If you're talking about the requirement to debounce buttons, the proper way to do this is to act on the button press immediately, while setting a timer that disallows further button state changes while waiting for the contacts to settle. This time is a balance between how long it actually takes the contacts to settle, and how rapidly a user could possibly push a button (missing a deliberate button press is also extremely frustrating and dangerously demanding of user attention, even with tactile feedback).

Re:We need physical audio kill switches by GoToRO on Monday September 21, 2020 @11:28AM (#24544544)
What I was saying is that the way you debouce a button comes from the customer (mercedes, ford etc.).

For sure you don’t act on a button press imediately. If you do that in automotive, all the electric noise will trigger the button randomly.