Apple Airpods’ deafening Amber Alert lawsuit

Continuing the discussion from News Story Dump Thread - Stories Only; its source: USA Today
Other sources: KDFW/Fox4 - NBC - KPRC/Click2Houston - KSAT

Lawsuit alleges that the loud volume level of an “Amber Alert” on an iOS caused hearing damage.

I have used iOS enough to know that there at least three independent volume levels that iOS

  • Ringer volume
  • Telephone volume
  • Other/music volume

So unexpectedly loud volume does appear to be possible, but that it could be loud enough to cause immediate eardrum damage, not just ringing in one’s ears and progressive hearing loss, is especially unexpected. I wonder if this was some kind of hardware failute.

In addition to this particular news item, this could be a thread in which to discuss other possibilities for hearing damage from audio hardware and the prevention thereof. For example,


I do not trust software with volume control anymore.
Since I began programming, I was interested in yanking the lid of all the software around me.
All the stinking garbage pulling the strings on shiny silicon was cobbled together by the intern and cleaning lady while drunk on the company Christmas party!

Put a good old potentiometer between anything that runs software and your ears!


I believe this is also true on Android, and in my opinion this incident could have just as easily occurred with an Android device. Neither iOS nor Android has a way to customize the volume level for emergency alerts.

In my opinion I don’t actually think Apple (or Google) are at fault for anything here. I think their hands are tied by FCC regulations that govern implementation of the Wireless Emergency Alerts and the Emergency Alert System. On Android, it’s not actually possible to receive AMBER alerts silently in a sensible way (such as a push notification with the normal push notification sound), and I’ve also noticed when I have received them in the past they always play at full volume even when I have my ringer volume turned down.

I had a surreal experience about 4 months ago. I was eating in a restaurant with my wife when an AMBER alert activated. About 30-40 phones all went off within seconds of each other with the cacophonous noise of the emergency alert sound.

The challenge is safely making people aware of a real issue they should know about while also respecting their preferences. Flexibility should be afforded to the software implementers so that alerts can be managed in a less intrusive manner, but the challenge currently is that all these requirements have likely been codified into law either by bureaucrats or by congress critters, neither of which have adequate amounts of technical expertise, and it only leads people to do what I’ve done on my own phone, and that was to disable AMBER alerts entirely. Because when the choice is being awakened at 4AM by an AMBER alert or hearing about it later when I wake up through other channels, I’d rather just disable them.

1 Like

Hear, hear! :wink:

Though the trouble with such hardware solutions is that a good setting or limit on the line-output of a DAC/amp. for one pair of headphones or speakers could be too high for another.

I may have mentioned it before, but I would prefer having each speaker/headphone equipped with a calibrated fuse or circuit breaker to remove any possibility of hearing damage, even during abnormal operation or in the case of a surge or short circuit.

With the increasing popularity of wireless headphones/speakers—and forced transition away from analogue TRS/TRRS connectors—many consumer devices will already need complex ICs to handle the incoming digital signal—be it via Bluetooth, Lightning, or USB—as well as a DAC. According to @MazeFrame in a thread about DACs and amplifiers, few consumer devices (if any) use digitally controlled amplifiers to adjust volume. Therefore most devices are adjusting volume by sacrificing bit depth—“taking the axe to the bits”—of the digital signal that is fed to the DAC.

For such devices, it seems entirely possible to add circuitry—or more likely: software—to achieve safe volume limiting within the headphones/speakers’ ICs. A software solution here (within the ICs of the headphones/speakers themselves) could be more reliable than in the audio source device’s OS.

While I would prefer an analogue fuse-like solution, this IC method would still be an improvement.

A final point regarding @MazeFrame’s trust in potentiometers

While a potentiometer is clearly electrically simpler than digitally decreasing the volume of a bitstream, it could have its own issues: do potentiometers reliably fail safe?

A Small Upside to Non-TRRS Headphones on iOS

I have not looked very exhaustively on Android, but on iOS devices, I know there is a dB-measured volume limiting feature located at:

Settings > Sounds > Headphone Safety > Reduce Loud Sounds

Before this current incarnation of the feature, the Music app had an option to simply limit iOS volume to a percentage of its full range. Instead of this, the current Reduce Loud Sounds feature allows a volume limit to be set to between 75 dB and 100 dB.

For unknown audio devices, iOS probably has a default mapping of volume output levels to dB.

However, for certain devices, iOS appears to use information from the Lightning connexion to precisely map its volume to a dB rating. You can see evidence of this in Control Centre’s “Hearing” control; it uses this information to show the moment-to-moment dB rating of what is currently being played under a digital volume meter.


Having worked in the audio repair/service industry since 1969, I can not ever recall a potentiometer cause too high a volume. I sure had too low sound, intermittent sound, crackling sound, no sound, tight to turn; but never ever too loud.

My 2c worth!

So a failing potentiometer will usually short safely to a lower voltage/volume than it is set to, rather than higher? That is excellent.

I’m not an audio guy - I just share some rough ideas as someone who owns about 1-1.5 grand of audio stuff. Look away if you want an exact explanation, this is guesswork and a consideration.

I’m picturing the sound signature of some quiet music, played very faintly.

  • The alert sound plays during the quiet playback.
  • For the first few audio samples, the alert sounds are electrically playing over top of the faint music. ++The playback hardware has no idea during this period this is occurring.
  • The alert continues to play, the music’s playback (even if it stopped playing, sometimes it is - still actively modulating the signal for a moment) is now stopped in all forms (electrical, physical, chemical, spiritual, nuclear…)
  • The audio of the alert comes to an end.

One thing I consider possible is when the audio signal of the alert is passed along with the original track audio (chewing eachother’s ears - track head/tail), is that while this can usually just result in garbage-bag ruffling-crackle and clipping - if the playback digital hardware is unexcepted in respect to such events there may be a remote chance electrically tripping the digital converter in the earpiece to play sound out of its designated range.
That could mean this is a hardware failure mode, where the hardware was always capable of producing this form of energy - but the physical logic was never in its designed nature instructed to produce something so far out of its performance zone.

Excluding the possibility of PDM/DSD playback…
How would this be possible?

If a DAC receives a much-louder signal in PCM audio, the digital value of the sample will be (regardless of +/-) much farther from zero. There is no way not to notice that the sample volume is increasing, unless I am severely misunderstanding something.

I’ve misspoken.
I’m making an assumption there could be a bluetooth ‘handshake’ or some form of event passed to the wireless earpiece when there is a track change or significant adjustment to audio.
But I’m also being very vague, to consider the event none of this hapens (and that this information is only used on the device).

An anecdotal tangent - before coming back on subject.

In Apple music and Itunes(windows) I’ve noticed the ‘seek’ functionality plays the next section of the track directly against the old audio, causing minor audio roughness momentarily.
On android it’s pretty bad, during track changes with no crossfade it actually is uncomfortable on songs that don’t end in very quiet sounds.

I’ve assumed that it’s possible even in iOS and native Apple devices this can occur more rarely, but during events like an emergency notification - which may do the same thing, playing over one source with another.

“Electrically” was meant to be vague, but I was mistaken in that. I’ve misused the word.
The idea was to say the possibility of two things:

    1. The audio signal may be clipped, because of the transition (or, if possible - the brief transition period switching from music to alert)
    1. The hardware may play the song + alert(loud) simultaneously, and if the earpiece expected to be informed of a significant audio change for dynamic range purposes, but, instead received some of the loudness during the song’s playback; I’ve taken a moonshot and guessed it could have made the earpiece glitch into something unexpected.

Hopefully that is a bit better. I’m struggling to put it into words.
In reflection; I’ve seen crappy audio hardware do this type of thing, but it’s fairly silly for me to assume that all hardware can do that when there’s a million things hardware can do.

1 Like

The only two failure modes I encountered with potentiometers so far are “corroded” and “burnt out in operator error on the test bench”.
There can be crackling when dust makes it onto the tracks, is usually annoying at worst.


Not intending to be directly to you but it is relevant.

I use android and no matter the headphonees I have used, 3.5mm, USB, or BT the system is aware of general notifications no matter where they originate from, and quietens music apps or youtube videos or spotify regardless of music app, youtube app or website or spotify both too.

So in that regard this is definitely something apple should have better control over, if the complaint is real anyway.

This has been figured out long ago, unless apple in their need to be different have set up some sort of exclusive pairing mode that 3.5mm, USB, or standard BT don’t use and the audio system is separate from just for the earpods.

I suspect that the “government alert” handling is probably handled at a much lower level than any other audio. It might even bypass the audio mixer, making it the only audio at all being played at the time.

  1. Maybe this is necessary for some sort of compliance purposes?
  2. If not necessary, maybe there is an internal-to-Apple concern that accessing the audio system as “just another app” leaves open the possibility of the mixer crashing, running out of channels, or in some other way failing to play the sound?
  3. Maybe due to the sensitive nature of government alerts, especially for natural disasters (flooding, tsunami, tornado, etc.) no one inside Apple is willing to modify the code, and it uses an older audio interface, perhaps dating back to the first version of iPhone OS?

Whether this is at heart a regulation issue (“devices must play alerts at max volume”) or an actual bug (“interface _ bypasses volume controls, and we did not anticipate that”) I am eager to see this lawsuit encourage some fixes, and bring more emphasis to hearing preservation.

1 Like

Apple sometimes oversteps the bounds of reason

I have literally blown large monitor speakers from the crackle from a dirty POT. It is also ear splitting on these speakers when it happened.

That is the one big downside, especially when manufacturers cheap out on the pot. And bad/old/dirty pots will result in harsh crackle (which can be dampened by putting a limiter between Pre-Amp and power amp section, but again, cost cutting).

And quality in this case does not mean Alps RK501-series, just not “fell of a truck in the desert”-tier.