5 ms·

Maybe this is cruel, but in some ways I’m surprised modern hardware can be damaged over a modern bus? I wonder how it damages them.

TaylorAlexander 6y ago
The device that can be damaged is a DJ controller with haptic feedback. So it has motors in it, and some kind of audio outputs. If the audio levels get turned to maximum or the motors get sent invalid commands, it could cause the device to damage itself. I’d call it a firmware problem if the motors can be commanded to move too fast, but anyway it may be reason for them to warn their customers. The editorialized hacker news headline makes it look like Big Sur is to blame, but it could easily be written as “Native Instruments Hardware does not fully support Big Sur and could be damaged if run on Big Sur.”
- sqldba 6y ago
  Or, depending on the cause, “Bugs in Native Instruments hardware / drivers can damage their hardware with Big Sur”.
  - mijoharas 6y ago
    To be fair to the person you're replying to they say: > I’d call it a firmware problem if the motors can be commanded to move too fast So it sounds like they agree with you. (Edit: typo)
  - sneak 6y ago
    It seems that the rule the crowd likes to go with is “last change broke it!”, which is something I don’t like very much.
- morpheuskafka 6y ago
  Yeah, that is an issue of the device IMO. It should prevent itself from being run in a destructive manner so long as the bus itself is in spec (ie no overvoltage, reverse polarity, etc). Unless it is clearly labelled as not to be connected to any system that hasn't been specifically evaluated and qualified by them, this shouldn't be the customers fault. Also, I initially misread this as National Instruments and imagined a DJ programming in LabView, LMAO.
  - pySSK 6y ago
    > Also, I initially misread this as National Instruments and imagined a DJ programming in LabView, LMAO. This made my day. This is one of the funniest things I have ever read.
- hungryforcodes 6y ago
  I’m not sure why you’re getting downvoted. This is a totally succinct summary of the situation.
marcan_42 6y ago
It's definitely a buggy device/firmware. There is no way an OS update can cause this (barring some massive Apple bug which is unlikely); more likely the device firmware mishandles some valid standard USB commands that older OSes didn't issue. In general, it's quite common for USB device firmware to be of extremely poor quality; it'll be tested and bugs fixed until it works with the target OSes and drivers, but no comprehensive testing of whether it can deal with all possible standard request patterns is done.
tialaramex 6y ago
As I understand it the Kontrol S4 has moving parts (essentially motors) under USB control. Obviously you could design this sensibly so that no legal inputs result in malfunction let alone damage, but that might cost more, so, do it all in software right? And then you're at the mercy of the software and anything (such as the OS kernel) which that software depends on. We do teach Computer Science / Software Engineering students not to do this, showing them e.g. the Therac-25 incident as an example of why software control isn't enough - but well, check out how many HN regulars are proud that they either didn't pay any attention in class or never attended and are "self-taught". SANE (the Free Software document scanner software) has run into cases where it's just cheaper to have code that checks "Is this the end of the bed? If so, turn off the motor" than spend five cents on a limit switch or one cent adding a stop so that the scan head physically can't fall off. Somebody reverse engineering a driver sends "Move scan head" and, to their astonishment, it falls off its rail and their scanner is broken. Oops. Now, who feels comfortable shipping that to users knowing if your finished driver didn't catch every edge case you might destroy their scanner?
- bigbubba 6y ago
  Sounds like a nightmare, I guess SANE is an ironic name?
  - wahern 6y ago
    IIUC, that example seems more like an indictment of the scanner manufacturers, not the developers of SANE. SANE includes that code because some manufacturers didn't implement such a simple, obvious, and crucial constraint in the hardware. Unless maybe the poster's point was that the SANE developers shouldn't try to support such fundamentally broken hardware?
    - bigbubba 6y ago
      I didn't mean to suggest that SANE was a poor project, I guess I just supposed it was sort of gallows humor from developers working on a hard problem.
  - 6y ago
fxtentacle 6y ago
A big risk with audio hardware is that buggy os drivers might lead to noise being output. One can attempt to detect and block this in hardware, but a compressed EDM track with reduced dynamics can look pretty close to loud noise at some short moments. Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears. My experience writing kernel drivers for audio software is that Windows will accept the click sound and then stop processing if the buffer runs dry. OS X used to have issues that it'll continue playing, meaning it'll reinterpret random memory as sound. Not sure if that was fixed in recent Mac versions, as their approach does have memory & performance benefits. But it means that audio driver glitches on Mac can be physically painful for the user.
- tarsinge 6y ago
  > Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears. I experienced one glitch like that while mixing with headphones, it's hard to describe how loud it was, a bang in my ears that made me fall and left me shackling for a few minutes. If you have ever be surprised by headphones at max volume, imagine it's even (way much) louder (because music at max volume is not a full 0db white noise). To this day I now avoid playing with plugins with the headphones and only put them for the final mix/mastering.

TaylorAlexander 6y ago

The device that can be damaged is a DJ controller with haptic feedback. So it has motors in it, and some kind of audio outputs. If the audio levels get turned to maximum or the motors get sent invalid commands, it could cause the device to damage itself. I’d call it a firmware problem if the motors can be commanded to move too fast, but anyway it may be reason for them to warn their customers. The editorialized hacker news headline makes it look like Big Sur is to blame, but it could easily be written as “Native Instruments Hardware does not fully support Big Sur and could be damaged if run on Big Sur.”

sqldba 6y ago
Or, depending on the cause, “Bugs in Native Instruments hardware / drivers can damage their hardware with Big Sur”.
- mijoharas 6y ago
  To be fair to the person you're replying to they say: > I’d call it a firmware problem if the motors can be commanded to move too fast So it sounds like they agree with you. (Edit: typo)
- sneak 6y ago
  It seems that the rule the crowd likes to go with is “last change broke it!”, which is something I don’t like very much.
morpheuskafka 6y ago
Yeah, that is an issue of the device IMO. It should prevent itself from being run in a destructive manner so long as the bus itself is in spec (ie no overvoltage, reverse polarity, etc). Unless it is clearly labelled as not to be connected to any system that hasn't been specifically evaluated and qualified by them, this shouldn't be the customers fault. Also, I initially misread this as National Instruments and imagined a DJ programming in LabView, LMAO.
- pySSK 6y ago
  > Also, I initially misread this as National Instruments and imagined a DJ programming in LabView, LMAO. This made my day. This is one of the funniest things I have ever read.
hungryforcodes 6y ago
I’m not sure why you’re getting downvoted. This is a totally succinct summary of the situation.

marcan_42 6y ago

It's definitely a buggy device/firmware. There is no way an OS update can cause this (barring some massive Apple bug which is unlikely); more likely the device firmware mishandles some valid standard USB commands that older OSes didn't issue. In general, it's quite common for USB device firmware to be of extremely poor quality; it'll be tested and bugs fixed until it works with the target OSes and drivers, but no comprehensive testing of whether it can deal with all possible standard request patterns is done.

tialaramex 6y ago

As I understand it the Kontrol S4 has moving parts (essentially motors) under USB control. Obviously you could design this sensibly so that no legal inputs result in malfunction let alone damage, but that might cost more, so, do it all in software right? And then you're at the mercy of the software and anything (such as the OS kernel) which that software depends on. We do teach Computer Science / Software Engineering students not to do this, showing them e.g. the Therac-25 incident as an example of why software control isn't enough - but well, check out how many HN regulars are proud that they either didn't pay any attention in class or never attended and are "self-taught". SANE (the Free Software document scanner software) has run into cases where it's just cheaper to have code that checks "Is this the end of the bed? If so, turn off the motor" than spend five cents on a limit switch or one cent adding a stop so that the scan head physically can't fall off. Somebody reverse engineering a driver sends "Move scan head" and, to their astonishment, it falls off its rail and their scanner is broken. Oops. Now, who feels comfortable shipping that to users knowing if your finished driver didn't catch every edge case you might destroy their scanner?

bigbubba 6y ago
Sounds like a nightmare, I guess SANE is an ironic name?
- wahern 6y ago
  IIUC, that example seems more like an indictment of the scanner manufacturers, not the developers of SANE. SANE includes that code because some manufacturers didn't implement such a simple, obvious, and crucial constraint in the hardware. Unless maybe the poster's point was that the SANE developers shouldn't try to support such fundamentally broken hardware?
  - bigbubba 6y ago
    I didn't mean to suggest that SANE was a poor project, I guess I just supposed it was sort of gallows humor from developers working on a hard problem.
- 6y ago

fxtentacle 6y ago

A big risk with audio hardware is that buggy os drivers might lead to noise being output. One can attempt to detect and block this in hardware, but a compressed EDM track with reduced dynamics can look pretty close to loud noise at some short moments. Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears. My experience writing kernel drivers for audio software is that Windows will accept the click sound and then stop processing if the buffer runs dry. OS X used to have issues that it'll continue playing, meaning it'll reinterpret random memory as sound. Not sure if that was fixed in recent Mac versions, as their approach does have memory & performance benefits. But it means that audio driver glitches on Mac can be physically painful for the user.

tarsinge 6y ago
> Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears. I experienced one glitch like that while mixing with headphones, it's hard to describe how loud it was, a bang in my ears that made me fall and left me shackling for a few minutes. If you have ever be surprised by headphones at max volume, imagine it's even (way much) louder (because music at max volume is not a full 0db white noise). To this day I now avoid playing with plugins with the headphones and only put them for the final mix/mastering.