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.
[ Parent
| on HN ]
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.