Re: Speaker burnout

[David Henningsson <david.henningsson@canonical.com>]

On 2015-03-31 13:31, Ricard Wanderlof wrote:
>
> On Tue, 31 Mar 2015, David Henningsson wrote:
>
>> On 2015-03-31 12:06, Nikita N. wrote:
>>>> If you have any concrete examples (alsa-info please!) of speakers that
>>>> can be burned out, and you know a maximum speaker volume where this
>>> As we said, that is not our bug, we are not audio experts, nor any of us
>>> is interested in audio matters.
>>
>> Here's my suggestion how to move forward on this:
>>
>>    1) Gather consensus that limit the maximum volume on internal speakers
>> is the right way forward. Takashi, Clemens, anyone against that strategy?
>>
>>    2) From the person with the hardware, we will need alsa-info (
>> https://wiki.ubuntu.com/Audio/AlsaInfo ), and also the max volume where
>> this does not happen. Is -6 dB good enough? -12 dB? I don't know - this
>> is something someone with the hardware must tell us, it cannot simply be
>> guessed.
>>
>>    3) I or someone else can write a kernel patch that limits the maximum
>> volume of the speakers to the amount deducted from point 2). Considering
>> that we're actually dealing with hardware breakage, this should be sent
>> to stable as well. Then no userspace application can set the volume
>> higher than our limit.
>
> While we could technically limit the output level in a driver, the output
> level at which the speakers get damaged must surely depend not only on the
> codec but also on the particular analog output stage driving the speakers
> (assuming it's not built into the codec), the speakers themselves, as well
> as any other hardware on the board, for instance coupling capacitors, or
> potential overload protection circuitry, most of which are components
> which we cannot identify in the driver.
>
> My point is that unless this is a problem with a very specific hardware,
> there's no way the software can actually know what a "dangerous" level
> would be, and hence we cannot limit it in software. What is a "dangerous"
> level in one setup could be an unusably low level in another setup, where
> both setups look identical from a driver point of view.
>
> I'm thinking that any limits must be dependent on a particular hardware
> setup, which means in order to be successful, we would have to extract
> some sort of model name of the system we're actually running on, to be
> compared against some sort of graylist. With the proliferation of model
> names of PC:s, such a list would be sketchy at best.

Yes, this is a problem with very specific hardware, and that's why I 
asked for alsa-info - part of what we get from that is somewhat of a 
unique model-ID (in the form of a PCI SSID).


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic