From: David Henningsson <david.henningsson@canonical.com>
To: Eliot Blennerhassett <eliot@blennerhassett.gen.nz>,
"Nikita N." <nikitan@operamail.com>,
Clemens Ladisch <clemens@ladisch.de>,
alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.de>
Subject: Re: Speaker burnout
Date: Tue, 07 Apr 2015 09:09:00 +0200 [thread overview]
Message-ID: <5523828C.8060301@canonical.com> (raw)
In-Reply-To: <55236B93.9070504@blennerhassett.gen.nz>
On 2015-04-07 07:30, Eliot Blennerhassett wrote:
> On 31/03/15 23:43, 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?
>
> I'm not sure about this (though in the end it doesn't affect me). Just
> running some experiments on my laptop. (HDA intel PCH sound)
>
> Playing some ordinary music, the level from the internal speakers is
> comfortable when master and PCM gains are set to maximum.
>
> At this setting, enabling the internal mic feedthrough with mic boost
> set to maximum, feedback happens when mic playback gain is at -6dB
> (max=+12dB).
> The signal when recorded is 1325Hz rail to rail square wave.
>
> My point is that in this case for normal usage the maximum output is
> fine, I'd even say it is required. So limiting output would not be a
> good idea.
> Also when using the mic for speech capture (with headphones for output),
> a gain greater than the 'feedback inducing' one is likely to be useful.
>
> So it is (only?) the pathological case of feeding mic direct to speakers
> that is problematic.
>
> Given that we can't fix the hardware or wacky user behaviour,
> My suggestion would be to either limit, or hide completely the various
> "Mic Playback" controls that enable direct feed from input to output.
> What is the use case for this anyway? - karaoke?
>
> Given that this goes against the "expose everything in the hardware",
> maybe have a module option that can unhide these controls if anybody
> actually wants to use them.
On one hand I find your arguments convincing, because limiting internal
mic playback volume is far less of a limitation (almost no people use
it), compared to limiting the internal speaker volume.
What bothers me is the following reasoning: If it is possible to burn
your speakers out by having the speakers outputting some tone caused by
feedback, would it not be possible to also burn your speakers out by
simply having a wave file with the same tone and playing it back?
E g, imagine a malicious web page that starts playing this tone back as
soon as you visit it. Would it be able to cause hardware damage to your
speakers, if you happened to have the speaker volume at maximum when you
visited that web page?
Or is there something that causes the feedback tone to be of a larger
amplitude than could ever be produced by the wave file?
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
next prev parent reply other threads:[~2015-04-07 7:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-28 14:03 bug Nikita N.
2015-03-30 7:19 ` bug Clemens Ladisch
2015-03-30 10:27 ` bug Nikita N.
2015-03-30 11:13 ` bug Clemens Ladisch
2015-03-30 14:37 ` bug Nikita N.
2015-03-31 7:18 ` bug Eliot Blennerhassett
2015-03-31 8:19 ` bug Nikita N.
2015-03-31 8:38 ` bug Clemens Ladisch
2015-03-31 9:05 ` bug Nikita N.
2015-03-31 12:42 ` bug Clemens Ladisch
2015-03-31 8:41 ` potential speaker burnout Eliot Blennerhassett
2015-03-31 8:24 ` bug Ricard Wanderlof
2015-03-31 8:56 ` bug Nikita N.
2015-03-31 9:14 ` bug Ricard Wanderlof
2015-03-31 10:26 ` bug Maarten de Boer
2015-03-31 10:49 ` bug Nikita N.
2015-03-31 11:05 ` bug Maarten de Boer
2015-03-31 11:44 ` bug Ricard Wanderlof
2015-03-31 8:54 ` bug Eliot Blennerhassett
2015-03-31 9:34 ` Speaker burnout David Henningsson
2015-03-31 10:06 ` Nikita N.
2015-03-31 10:43 ` David Henningsson
2015-03-31 10:57 ` Alexander E. Patrakov
2015-03-31 11:23 ` Nikolay Dimitrov
2015-03-31 11:31 ` Ricard Wanderlof
2015-03-31 11:45 ` David Henningsson
2015-03-31 13:47 ` Torsten Schenk
2015-03-31 19:14 ` Nikita N.
2015-04-05 16:36 ` Takashi Iwai
2015-04-05 16:11 ` Takashi Iwai
2015-04-07 5:30 ` Eliot Blennerhassett
2015-04-07 7:09 ` David Henningsson [this message]
2015-04-07 7:26 ` Clemens Ladisch
2015-04-07 7:49 ` Eliot Blennerhassett
2015-04-07 10:55 ` David Henningsson
2015-04-07 11:29 ` Ricard Wanderlof
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5523828C.8060301@canonical.com \
--to=david.henningsson@canonical.com \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=eliot@blennerhassett.gen.nz \
--cc=nikitan@operamail.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.