bug

bug

[Nikita N.]

is any programmer listening here?

-- 
http://www.fastmail.com - A no graphics, no pop-ups email service

Re: bug

[Clemens Ladisch]

Nikita N. wrote:
> is any programmer listening here?

No.

But several are reading here.


Regards,
Clemens

Re: bug

[Nikita N.]

is anybody here aware that latest alsamixergui has a bug capable of
produce irreversible damage to internal laptop speakers?
-- 
  Nikita N.
  nikitan@operamail.com


On Mon, Mar 30, 2015, at 12:19 AM, Clemens Ladisch wrote:
> Nikita N. wrote:
> > is any programmer listening here?
> 
> No.
> 
> But several are reading here.
> 
> 
> Regards,
> Clemens

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
                          love email again

Re: bug

[Clemens Ladisch]

Nikita N. wrote:
> is anybody here aware that latest alsamixergui

Despite its name, this program was not written by the ALSA project.

> has a bug capable of
> produce irreversible damage to internal laptop speakers?

What is the bug?


Regards,
Clemens

Re: bug

[Nikita N.]

We are the devs involved in dCore porting, and that is one of our users
report:
http://forum.tinycorelinux.net/index.php/topic,18225

We verified that in few of our legacy laptops.
It didn't reproduce for every laptop, but indeed in a couple of them,
the temperature of the speakers reached extremes levels in few seconds,
only unplugging the AC/DC cable saved them.
This is a serious problem in our opinion, and we would hate to see our
dCore reputation spoiled.
We hate to admit, but it is *NOT* our bug, and would hate to see this
bug reverse engineered into a virus/malware (on Linux, or other OS) and
see ourselves blamed for it.
So we would like to keep the incident quiet, and we are going to remove
that thread from our forum.
On the other side, we would expect any action from ALSA project in
removing that tool and/or exposing the real individual/s guilty of
writing that tool.

Thank you for your attentions and looking forward your feedback.
-- 
  Nikita N.
  nikitan@operamail.com


On Mon, Mar 30, 2015, at 04:13 AM, Clemens Ladisch wrote:
> Nikita N. wrote:
> > is anybody here aware that latest alsamixergui
> 
> Despite its name, this program was not written by the ALSA project.
> 
> > has a bug capable of
> > produce irreversible damage to internal laptop speakers?
> 
> What is the bug?
> 
> 
> Regards,
> Clemens

-- 
http://www.fastmail.com - IMAP accessible web-mail

Re: bug

[Eliot Blennerhassett]

On 31/03/15 03:37, Nikita N. wrote:
> We are the devs involved in dCore porting, and that is one of our users
> report:
> http://forum.tinycorelinux.net/index.php/topic,18225
> 
> We verified that in few of our legacy laptops.
> It didn't reproduce for every laptop, but indeed in a couple of them,
> the temperature of the speakers reached extremes levels in few seconds,
> only unplugging the AC/DC cable saved them.

This is a hardware problem, quite likely reproducible in any OS that
gives control of the

> This is a serious problem in our opinion, and we would hate to see our
> dCore reputation spoiled.
> We hate to admit, but it is *NOT* our bug, and would hate to see this
> bug reverse engineered into a virus/malware (on Linux, or other OS) and
> see ourselves blamed for it.
> So we would like to keep the incident quiet, and we are going to remove
> that thread from our forum.
> On the other side, we would expect any action from ALSA project in
> removing that tool and/or exposing the real individual/s guilty of
> writing that tool.

As Clemens has pointed out, "the ALSA project" cannot remove the tool,
as it is not part of the ALSA project.
However, probably any software that can control all the volumes is
capable of reproducing the same effect.

And in my opinion, you are blaming the wrong party here. As various
posters on your forum thread point out, blame the hardware manufacturer
or the particular user who has done something crazy and now wants to
find some other "guilty" party.

1: User setting ALL volumes to maximum (?) probably causes feedback from
microphone to speakers.   (Yes I can confirm that happens on my laptop
with mic gain set to 20dB below maximum). You can do the same on your
home stereo and blow your speakers, nobody will have any sympathy.

2: The laptop manufacturer has apparently not designed the hardware
robustly, i.e. the speakers are too puny for the maximum output of the
audio amplifier.

3: There is no way for the soundcard driver to know what the limits are,
it just exposes the controls for the user to set.

regards

Eliot

Re: bug

[Nikita N.]

> And in my opinion, you are blaming the wrong party here.
we are not blaming anybody.
We simply want to avoid any more of Our users to damage their speakers.
Most of users are not omniscient, if they are given a tool capable of
creating damage, at least they deserve a warning from the tool/provider.
If ALSA can't fix/remove that tool, we kindly ask you to point us to the
individual who programmed it, and we will contact him/her directly.
Unless that is not a secret.
If that is a secret and/or we will not receive feedback, then we will
expose clearly to the public that tool as a virus/malware, and inform
the antivirus authorities about it.

> (Yes I can confirm that happens on my laptop with mic gain set to 20dB below maximum).
Thank you very much for your confirmation, so in the meantime we start
as blacklisting that tool from our repos.

-- 
  Nikita N.
  nikitan@operamail.com


On Tue, Mar 31, 2015, at 12:18 AM, Eliot Blennerhassett wrote:
> On 31/03/15 03:37, Nikita N. wrote:
> > We are the devs involved in dCore porting, and that is one of our users
> > report:
> > http://forum.tinycorelinux.net/index.php/topic,18225
> > 
> > We verified that in few of our legacy laptops.
> > It didn't reproduce for every laptop, but indeed in a couple of them,
> > the temperature of the speakers reached extremes levels in few seconds,
> > only unplugging the AC/DC cable saved them.
> 
> This is a hardware problem, quite likely reproducible in any OS that
> gives control of the
> 
> > This is a serious problem in our opinion, and we would hate to see our
> > dCore reputation spoiled.
> > We hate to admit, but it is *NOT* our bug, and would hate to see this
> > bug reverse engineered into a virus/malware (on Linux, or other OS) and
> > see ourselves blamed for it.
> > So we would like to keep the incident quiet, and we are going to remove
> > that thread from our forum.
> > On the other side, we would expect any action from ALSA project in
> > removing that tool and/or exposing the real individual/s guilty of
> > writing that tool.
> 
> As Clemens has pointed out, "the ALSA project" cannot remove the tool,
> as it is not part of the ALSA project.
> However, probably any software that can control all the volumes is
> capable of reproducing the same effect.
> 
> And in my opinion, you are blaming the wrong party here. As various
> posters on your forum thread point out, blame the hardware manufacturer
> or the particular user who has done something crazy and now wants to
> find some other "guilty" party.
> 
> 1: User setting ALL volumes to maximum (?) probably causes feedback from
> microphone to speakers.   (Yes I can confirm that happens on my laptop
> with mic gain set to 20dB below maximum). You can do the same on your
> home stereo and blow your speakers, nobody will have any sympathy.
> 
> 2: The laptop manufacturer has apparently not designed the hardware
> robustly, i.e. the speakers are too puny for the maximum output of the
> audio amplifier.
> 
> 3: There is no way for the soundcard driver to know what the limits are,
> it just exposes the controls for the user to set.
> 
> regards
> 
> Eliot

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
                          love email again

Re: bug

[Ricard Wanderlof]

On Mon, 30 Mar 2015, Nikita N. wrote:

> We are the devs involved in dCore porting, and that is one of our users
> report:
> http://forum.tinycorelinux.net/index.php/topic,18225
> 
> We verified that in few of our legacy laptops.
> It didn't reproduce for every laptop, but indeed in a couple of them,
> the temperature of the speakers reached extremes levels in few seconds,
> only unplugging the AC/DC cable saved them.
> This is a serious problem in our opinion, and we would hate to see our
> dCore reputation spoiled.
> We hate to admit, but it is *NOT* our bug, and would hate to see this
> bug reverse engineered into a virus/malware (on Linux, or other OS) and
> see ourselves blamed for it.
> So we would like to keep the incident quiet, and we are going to remove
> that thread from our forum.
> On the other side, we would expect any action from ALSA project in
> removing that tool and/or exposing the real individual/s guilty of
> writing that tool.

First of all, I can't say I'm representing the ALSA project or anyone else 
in this matter, so the following is just my personal opinion. Furthermore 
I have no real experience with the mixer application under discussion 
(alsamixergui), but on the face of it it just looks like any mixer 
application.

>From the thread linked above, it seems that if someone maxes out all 
controls in the mixer, this results in a high-pitched whine in the 
speakers, which on certain laptops seem to cause the destruction of 
something in the machine (likely the speakers themselves). It is further 
speculated in the thread that what might be happening is acoustic feedback 
from the speakers to the microphone, which would make sense given the 
results, but would seem strange from a system design point of view.

First of all, it would seem that this wouldn't be dependent on a 
particular mixer application such as alsamixergui, but should be able to 
happen with any mixer application, given the appropriate settings.

Secondly, if you believe that alsamixergui specifically is missbehaving, 
why don't you just take it out of your distribution (dCore)?

Thirdly, and perhaps most importantly, this seems to be a hardware 
problem. If the drive capability of the laptops's output stage is too much 
for the speakers, then there is a serious design flaw in the hardware. 
Given the proliferation of cheap PC hardware this is not surprising, but 
it is hardly a software problem.

And finally, as Clemens said, alsamixergui is not created by the ALSA 
project, so this mailing list is the wrong place to look if none other 
than for that particular reason.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: bug

[Clemens Ladisch]

Nikita N. wrote:
> If ALSA can't fix/remove that tool, we kindly ask you to point us to the
> individual who programmed it, and we will contact him/her directly.

http://www.iua.upf.es/~mdeboer/projects/alsamixergui/

> If that is a secret and/or we will not receive feedback, then we will
> expose clearly to the public that tool as a virus/malware, and inform
> the antivirus authorities about it.

Please note that _every_ mixer application on _every_ OS might be able
to set the controls to those dangerous values.


Regards,
Clemens

Re: potential speaker burnout

[Eliot Blennerhassett]

On 31/03/15 21:19, Nikita N. wrote:
>> And in my opinion, you are blaming the wrong party here.
> we are not blaming anybody.

You talk about finding the person who is "guilty"

>> (Yes I can confirm that happens on my laptop with mic gain set to 20dB below maximum).

> Thank you very much for your confirmation, so in the meantime we start
> as blacklisting that tool from our repos.

I agree it would be upsetting to have your laptop speakers go up in smoke.

But I reiterate, it is not the alsamixergui tool. ANY tool that is
capable of adjusting the underlying controls of the soundcard is capable
of reproducing the effect.  I.e. commandline "amixer", terminal
"alsamixer', possibly others...

You would be better to blacklist the problematic laptop hardware, not
these control apps.

The one thing maybe worth thinking about is whether there is any useful
purpose for the control that enables direct feed from microphone to
speakers?  This is something that is provided by the underlying sound
driver, and would need to be "fixed" there.
I.e. your distro would have to patch drivers before building the kernel.

Re: bug

[Eliot Blennerhassett]

(Note - this email now off-list)

On 31/03/15 03:37, Nikita N. wrote:
> This is a serious problem in our opinion, and we would hate to see our
> dCore reputation spoiled.

This problem probably exists in all distros, and probably other OSes as
well.  Apparently it hasn't spoiled their reputation yet.

Given that you're building a lightweight distro, I'd suggest you drop
alsamixergui anyway; A terminal with alsamixer will do the same job,
just not as pretty.

Re: bug

[Nikita N.]

> First of all, I can't say I'm representing the ALSA project or anyone else 
> in this matter, so the following is just my personal opinion.
As we already wrote, we are not blaming you or ALSA.

> particular mixer application such as alsamixergui, but should be able to 
> happen with any mixer application, given the appropriate settings.
That is indeed what we are afraid, if anybody will have the brilliant
idea to reverse engineer that tool to a more damaging level in a
virus/malware , and make its effect unstoppable. 

> Secondly, if you believe that alsamixergui specifically is missbehaving, 
> why don't you just take it out of your distribution (dCore)?
as we wrote, we are going to do this.

> Given the proliferation of cheap PC hardware this is not surprising
as you say, given the proliferation of cheap PC hardware, a
proliferation of such virus/malware could upset not only our users.

> it is hardly a software problem.
I personally don't agree with that.
As we wrote, not everybody is omniscient, I personally was not aware of
this issue, before was pointed out.
Without warnings, even a Teddy Bear can be dangerous.

> alsamixergui is not created by the ALSA 
> project, so this mailing list is the wrong place to look if none other 
> than for that particular reason.
Sure, we would be very grateful if you could point that out, so we can
contact the individual who programmed this tool
Unless it's not a secret or there is smtng to hide.
 
-- 
  Nikita N.
  nikitan@operamail.com


On Tue, Mar 31, 2015, at 01:24 AM, Ricard Wanderlof wrote:
> 
> On Mon, 30 Mar 2015, Nikita N. wrote:
> 
> > We are the devs involved in dCore porting, and that is one of our users
> > report:
> > http://forum.tinycorelinux.net/index.php/topic,18225
> > 
> > We verified that in few of our legacy laptops.
> > It didn't reproduce for every laptop, but indeed in a couple of them,
> > the temperature of the speakers reached extremes levels in few seconds,
> > only unplugging the AC/DC cable saved them.
> > This is a serious problem in our opinion, and we would hate to see our
> > dCore reputation spoiled.
> > We hate to admit, but it is *NOT* our bug, and would hate to see this
> > bug reverse engineered into a virus/malware (on Linux, or other OS) and
> > see ourselves blamed for it.
> > So we would like to keep the incident quiet, and we are going to remove
> > that thread from our forum.
> > On the other side, we would expect any action from ALSA project in
> > removing that tool and/or exposing the real individual/s guilty of
> > writing that tool.
> 
> First of all, I can't say I'm representing the ALSA project or anyone
> else 
> in this matter, so the following is just my personal opinion. Furthermore 
> I have no real experience with the mixer application under discussion 
> (alsamixergui), but on the face of it it just looks like any mixer 
> application.
> 
> From the thread linked above, it seems that if someone maxes out all 
> controls in the mixer, this results in a high-pitched whine in the 
> speakers, which on certain laptops seem to cause the destruction of 
> something in the machine (likely the speakers themselves). It is further 
> speculated in the thread that what might be happening is acoustic
> feedback 
> from the speakers to the microphone, which would make sense given the 
> results, but would seem strange from a system design point of view.
> 
> First of all, it would seem that this wouldn't be dependent on a 
> particular mixer application such as alsamixergui, but should be able to 
> happen with any mixer application, given the appropriate settings.
> 
> Secondly, if you believe that alsamixergui specifically is missbehaving, 
> why don't you just take it out of your distribution (dCore)?
> 
> Thirdly, and perhaps most importantly, this seems to be a hardware 
> problem. If the drive capability of the laptops's output stage is too
> much 
> for the speakers, then there is a serious design flaw in the hardware. 
> Given the proliferation of cheap PC hardware this is not surprising, but 
> it is hardly a software problem.
> 
> And finally, as Clemens said, alsamixergui is not created by the ALSA 
> project, so this mailing list is the wrong place to look if none other 
> than for that particular reason.
> 
> /Ricard
> -- 
> Ricard Wolf Wanderlöf                           ricardw(at)axis.com
> Axis Communications AB, Lund, Sweden            www.axis.com
> Phone +46 46 272 2016                           Fax +46 46 13 61 30

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
                          love email again

Re: bug

[Nikita N.]

> http://www.iua.upf.es/~mdeboer/projects/alsamixergui/
this link is broken, please provide a correct one, thanks.

> Please note that _every_ mixer application on _every_ OS might be able
> to set the controls to those dangerous values.
is it "might" or it is? Is also your alsamixer textual version tool,
capable of speakers burnout?
Thanks

-- 
  Nikita N.
  nikitan@operamail.com


On Tue, Mar 31, 2015, at 01:38 AM, Clemens Ladisch wrote:
> Nikita N. wrote:
> > If ALSA can't fix/remove that tool, we kindly ask you to point us to the
> > individual who programmed it, and we will contact him/her directly.
> 
> http://www.iua.upf.es/~mdeboer/projects/alsamixergui/
> 
> > If that is a secret and/or we will not receive feedback, then we will
> > expose clearly to the public that tool as a virus/malware, and inform
> > the antivirus authorities about it.
> 
> Please note that _every_ mixer application on _every_ OS might be able
> to set the controls to those dangerous values.
> 
> 
> Regards,
> Clemens

-- 
http://www.fastmail.com - Does exactly what it says on the tin

Re: bug

[Ricard Wanderlof]

On Tue, 31 Mar 2015, Nikita N. wrote:

> > alsamixergui is not created by the ALSA 
> > project, so this mailing list is the wrong place to look if none other 
> > than for that particular reason.
> Sure, we would be very grateful if you could point that out, so we can
> contact the individual who programmed this tool
> Unless it's not a secret or there is smtng to hide.

I have no idea who wrote it, Clemens posted a link but at to me it seems 
dead, there should be something in the source code (perhaps that's where 
he got it frome?). Could very well be that it was written by someone who 
has since moved on to other things so that any links or email adresses are 
outdated. It's not necessarily a secret, it could just be unknown at this 
point, and if the person who wrote it is not actively maintaining it any 
more there's probably little to be gained from contacting him.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Speaker burnout

[David Henningsson]

On 2015-03-30 16:37, Nikita N. wrote:
> We are the devs involved in dCore porting, and that is one of our users
> report:
> http://forum.tinycorelinux.net/index.php/topic,18225
>
> We verified that in few of our legacy laptops.
> It didn't reproduce for every laptop, but indeed in a couple of them,
> the temperature of the speakers reached extremes levels in few seconds,
> only unplugging the AC/DC cable saved them.
> This is a serious problem in our opinion, and we would hate to see our
> dCore reputation spoiled.
> We hate to admit, but it is *NOT* our bug, and would hate to see this
> bug reverse engineered into a virus/malware (on Linux, or other OS) and
> see ourselves blamed for it.
> So we would like to keep the incident quiet, and we are going to remove
> that thread from our forum.
> On the other side, we would expect any action from ALSA project in
> removing that tool and/or exposing the real individual/s guilty of
> writing that tool.
>
> Thank you for your attentions and looking forward your feedback.

My opinion is that; it would have been better if the laptop had hardware 
protection against these kinds of failures, but now that it apparently 
has not, it should be fixed at the second best level, i e, kernel drivers.

Preferrably by not exposing (at least not by default) the highest levels 
of speaker output.

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 
never happens, I think we should artifically lower the max volume to 
this level so that no mixer application can set the speaker volume 
higher than that.

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

Re: Speaker burnout

[Nikita N.]

> 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.
Nevertheless, we all embrace the Debian/Ubuntu philosophy and Manifesto,
to help in creating a better world, in our small.
For this reason, we feel like we can't just ignore this issue, so
something has to be done to fix it - by who has the proper expertise.
"Ubuntu" is an ancient African word, meaning "humanity to others". The
Ubuntu distribution brings the spirit of Ubuntu to the software world.
We don't bring "humanity to others", programming or distributing any
software which can damage the hardware.


On Tue, Mar 31, 2015, at 02:34 AM, David Henningsson wrote:
> 
> 
> On 2015-03-30 16:37, Nikita N. wrote:
> > We are the devs involved in dCore porting, and that is one of our users
> > report:
> > http://forum.tinycorelinux.net/index.php/topic,18225
> >
> > We verified that in few of our legacy laptops.
> > It didn't reproduce for every laptop, but indeed in a couple of them,
> > the temperature of the speakers reached extremes levels in few seconds,
> > only unplugging the AC/DC cable saved them.
> > This is a serious problem in our opinion, and we would hate to see our
> > dCore reputation spoiled.
> > We hate to admit, but it is *NOT* our bug, and would hate to see this
> > bug reverse engineered into a virus/malware (on Linux, or other OS) and
> > see ourselves blamed for it.
> > So we would like to keep the incident quiet, and we are going to remove
> > that thread from our forum.
> > On the other side, we would expect any action from ALSA project in
> > removing that tool and/or exposing the real individual/s guilty of
> > writing that tool.
> >
> > Thank you for your attentions and looking forward your feedback.
> 
> My opinion is that; it would have been better if the laptop had hardware 
> protection against these kinds of failures, but now that it apparently 
> has not, it should be fixed at the second best level, i e, kernel
> drivers.
> 
> Preferrably by not exposing (at least not by default) the highest levels 
> of speaker output.
> 
> 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 
> never happens, I think we should artifically lower the max volume to 
> this level so that no mixer application can set the speaker volume 
> higher than that.
> 
> -- 
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

-- 
http://www.fastmail.com - The professional email service

Re: bug

[Maarten de Boer]

Hello,

I am the author of alsamixergui. I am not actively maintaining alsamixergui anymore (and haven’t been for years). It is pretty much coincidence that I saw this mail thread; a slightly more informative subject would have helped.

There is not much that I can add to this thread (thanks everyone for your replies), but in short:

- alsamixergui is just a graphical frontend, and exposes the mixer capabilities of the sound card in the same way alsamixer, amixer or any other alsa mixer does, so this is not alsamixergui specific. (strongly based on the alsamixer code (verbatim) with fltk gui code added to it.).

- this is not a software problem, this is a hardware problem. The user adjusts the mixer to cause a feedback between speaker and internal microphone, and leaves this running for >30 seconds, and his hardware can’t deal with it. It is probably not even operating system specific.

Finally, I really don’t like the tone you use, Nikita, particularly your talk of “exposing the individuals guilty” and your accusations of secrecy. And "expose clearly to the public that tool as a virus/malware, and inform the antivirus authorities about it.”, really? Good luck with that.

If you want to blacklist alsamixergui from your distro, please go ahead, but don’t forget to blacklist alsamixer and amixer too, as well as any other alsa mixer front ends.

Maarten


On 31 Mar 2015, at 11:14, Ricard Wanderlof <ricard.wanderlof@axis.com> wrote:

> 
> On Tue, 31 Mar 2015, Nikita N. wrote:
> 
>>> alsamixergui is not created by the ALSA 
>>> project, so this mailing list is the wrong place to look if none other 
>>> than for that particular reason.
>> Sure, we would be very grateful if you could point that out, so we can
>> contact the individual who programmed this tool
>> Unless it's not a secret or there is smtng to hide.
> 
> I have no idea who wrote it, Clemens posted a link but at to me it seems 
> dead, there should be something in the source code (perhaps that's where 
> he got it frome?). Could very well be that it was written by someone who 
> has since moved on to other things so that any links or email adresses are 
> outdated. It's not necessarily a secret, it could just be unknown at this 
> point, and if the person who wrote it is not actively maintaining it any 
> more there's probably little to be gained from contacting him.
> 
> /Ricard
> -- 
> Ricard Wolf Wanderlöf                           ricardw(at)axis.com
> Axis Communications AB, Lund, Sweden            www.axis.com
> Phone +46 46 272 2016                           Fax +46 46 13 61 30
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Speaker burnout

[David Henningsson]

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.

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

Re: bug

[Nikita N.]

Dear Maarten de Boer,
as you read from many voices here, your software is verified can damage
the speakers, if not used somehow correctly.
The definition of correctly is still to us unknown, nor you are giving
us any hope in that.
We were hoping in some form of amend from yourself, about the dangerous
software you produced and distributed to public.
We were hoping in some form of bug fix or any professional approach to
solving that issue.
We were hoping at least in a simple warning popping up from your tool,
when user sets any "hazardous" levels.
We were hoping at least-least in a warning popping up from your tool at
runtime, something like "Warning: improper settings for this level, this
level and this might result in damages to your audio devices".
But, we only see a nice turnaround "There is not much that I can add".
Your program does not respect the minimum requirement for a software to
be published, such as being "reasonably" bug free.
As for "bug" is intended a software which is limited in creating
software problems.
While instead, your tool expands to a whole new, and more dangerous
level - hardware damage.
Hence your software, as is, doesn't respect our Debian/Ubuntu
philosophy.
So, at this point "There is not much that" we can add.
We also wish you "Good luck with that."

On Tue, Mar 31, 2015, at 03:26 AM, Maarten de Boer wrote:
> Hello,
> 
> I am the author of alsamixergui. I am not actively maintaining
> alsamixergui anymore (and haven’t been for years). It is pretty much
> coincidence that I saw this mail thread; a slightly more informative
> subject would have helped.
> 
> There is not much that I can add to this thread (thanks everyone for your
> replies), but in short:
> 
> - alsamixergui is just a graphical frontend, and exposes the mixer
> capabilities of the sound card in the same way alsamixer, amixer or any
> other alsa mixer does, so this is not alsamixergui specific. (strongly
> based on the alsamixer code (verbatim) with fltk gui code added to it.).
> 
> - this is not a software problem, this is a hardware problem. The user
> adjusts the mixer to cause a feedback between speaker and internal
> microphone, and leaves this running for >30 seconds, and his hardware
> can’t deal with it. It is probably not even operating system specific.
> 
> Finally, I really don’t like the tone you use, Nikita, particularly your
> talk of “exposing the individuals guilty” and your accusations of
> secrecy. And "expose clearly to the public that tool as a virus/malware,
> and inform the antivirus authorities about it.”, really? Good luck with
> that.
> 
> If you want to blacklist alsamixergui from your distro, please go ahead,
> but don’t forget to blacklist alsamixer and amixer too, as well as any
> other alsa mixer front ends.
> 
> Maarten
> 
> 
> On 31 Mar 2015, at 11:14, Ricard Wanderlof <ricard.wanderlof@axis.com>
> wrote:
> 
> > 
> > On Tue, 31 Mar 2015, Nikita N. wrote:
> > 
> >>> alsamixergui is not created by the ALSA 
> >>> project, so this mailing list is the wrong place to look if none other 
> >>> than for that particular reason.
> >> Sure, we would be very grateful if you could point that out, so we can
> >> contact the individual who programmed this tool
> >> Unless it's not a secret or there is smtng to hide.
> > 
> > I have no idea who wrote it, Clemens posted a link but at to me it seems 
> > dead, there should be something in the source code (perhaps that's where 
> > he got it frome?). Could very well be that it was written by someone who 
> > has since moved on to other things so that any links or email adresses are 
> > outdated. It's not necessarily a secret, it could just be unknown at this 
> > point, and if the person who wrote it is not actively maintaining it any 
> > more there's probably little to be gained from contacting him.
> > 
> > /Ricard
> > -- 
> > Ricard Wolf Wanderlöf                           ricardw(at)axis.com
> > Axis Communications AB, Lund, Sweden            www.axis.com
> > Phone +46 46 272 2016                           Fax +46 46 13 61 30
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

-- 
http://www.fastmail.com - Access all of your messages and folders
                          wherever you are

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Speaker burnout

[Alexander E. Patrakov]

31.03.2015 15:43, David Henningsson wrote:
>   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.

Another useful piece of information would be what Windows does here.

Please generate a -36 dB 1000 Hz sine wave in Audacity, save as a wav 
file, play at the maximum volume in Windows, record with a mobile phone 
(you can use software such as Tape Machine which turns AGC off in the 
phone). Ideally, the mobile phone should be placed on the table to avoid 
movements. Play the same wav file in linux (with a known safe 
attenuation), also record the sound without moving the mobile phone. 
Compare the recordings in Audacity to find out the attenuation done by 
Windows.

-- 
Alexander E. Patrakov

Re: bug

[Maarten de Boer]

Hi,

As I tried to explain, this is not specific for alsamixergui, and it is not a bug, as it is a hardware problem. There is no way for the software to know what would be these “hazardous” levels, as this is hardware specific. And again, alsamixergui is just a graphical frontend. The command line alsamixer does the same thing.

Maarten

On 31 Mar 2015, at 12:49, Nikita N. <nikitan@operamail.com> wrote:

> Dear Maarten de Boer,
> as you read from many voices here, your software is verified can damage
> the speakers, if not used somehow correctly.
> The definition of correctly is still to us unknown, nor you are giving
> us any hope in that.
> We were hoping in some form of amend from yourself, about the dangerous
> software you produced and distributed to public.
> We were hoping in some form of bug fix or any professional approach to
> solving that issue.
> We were hoping at least in a simple warning popping up from your tool,
> when user sets any "hazardous" levels.
> We were hoping at least-least in a warning popping up from your tool at
> runtime, something like "Warning: improper settings for this level, this
> level and this might result in damages to your audio devices".
> But, we only see a nice turnaround "There is not much that I can add".
> Your program does not respect the minimum requirement for a software to
> be published, such as being "reasonably" bug free.
> As for "bug" is intended a software which is limited in creating
> software problems.
> While instead, your tool expands to a whole new, and more dangerous
> level - hardware damage.
> Hence your software, as is, doesn't respect our Debian/Ubuntu
> philosophy.
> So, at this point "There is not much that" we can add.
> We also wish you "Good luck with that."
> 
> On Tue, Mar 31, 2015, at 03:26 AM, Maarten de Boer wrote:
>> Hello,
>> 
>> I am the author of alsamixergui. I am not actively maintaining
>> alsamixergui anymore (and haven’t been for years). It is pretty much
>> coincidence that I saw this mail thread; a slightly more informative
>> subject would have helped.
>> 
>> There is not much that I can add to this thread (thanks everyone for your
>> replies), but in short:
>> 
>> - alsamixergui is just a graphical frontend, and exposes the mixer
>> capabilities of the sound card in the same way alsamixer, amixer or any
>> other alsa mixer does, so this is not alsamixergui specific. (strongly
>> based on the alsamixer code (verbatim) with fltk gui code added to it.).
>> 
>> - this is not a software problem, this is a hardware problem. The user
>> adjusts the mixer to cause a feedback between speaker and internal
>> microphone, and leaves this running for >30 seconds, and his hardware
>> can’t deal with it. It is probably not even operating system specific.
>> 
>> Finally, I really don’t like the tone you use, Nikita, particularly your
>> talk of “exposing the individuals guilty” and your accusations of
>> secrecy. And "expose clearly to the public that tool as a virus/malware,
>> and inform the antivirus authorities about it.”, really? Good luck with
>> that.
>> 
>> If you want to blacklist alsamixergui from your distro, please go ahead,
>> but don’t forget to blacklist alsamixer and amixer too, as well as any
>> other alsa mixer front ends.
>> 
>> Maarten
>> 
>> 
>> On 31 Mar 2015, at 11:14, Ricard Wanderlof <ricard.wanderlof@axis.com>
>> wrote:
>> 
>>> 
>>> On Tue, 31 Mar 2015, Nikita N. wrote:
>>> 
>>>>> alsamixergui is not created by the ALSA 
>>>>> project, so this mailing list is the wrong place to look if none other 
>>>>> than for that particular reason.
>>>> Sure, we would be very grateful if you could point that out, so we can
>>>> contact the individual who programmed this tool
>>>> Unless it's not a secret or there is smtng to hide.
>>> 
>>> I have no idea who wrote it, Clemens posted a link but at to me it seems 
>>> dead, there should be something in the source code (perhaps that's where 
>>> he got it frome?). Could very well be that it was written by someone who 
>>> has since moved on to other things so that any links or email adresses are 
>>> outdated. It's not necessarily a secret, it could just be unknown at this 
>>> point, and if the person who wrote it is not actively maintaining it any 
>>> more there's probably little to be gained from contacting him.
>>> 
>>> /Ricard
>>> -- 
>>> Ricard Wolf Wanderlöf                           ricardw(at)axis.com
>>> Axis Communications AB, Lund, Sweden            www.axis.com
>>> Phone +46 46 272 2016                           Fax +46 46 13 61 30
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>> 
> 
> -- 
> http://www.fastmail.com - Access all of your messages and folders
>                          wherever you are
> 

Re: Speaker burnout

[Nikolay Dimitrov]

Hi David,

On 03/31/2015 01:43 PM, 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.

Probably a kernel patch is not necessary. asound.conf ans asound.state
can do similar job. If the master volume is fixed to a safe value, the
audio can be routed through softvol plugin, which can be used as a
replacement for the master volume control (the exact levels need to be
confirmed with someone who has access to the problematic hardware).

state.Intel {
	control.1 {
		comment.access 'read'  // read-only
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 64'
		comment.dbmin -6400
		comment.dbmax 0
		iface MIXER
		name 'Speaker Playback Volume'
		value.0 42  // safe volume levels
		value.1 42  //
	}
}

Could be even better if the HW master volume control is hidden (I don't
know how to do this), and the softvol control is exposes as master volume:

pcm.!default {
     type            softvol
     slave.pcm       "default"
     control.name    "Master Volume"
     control.card    0
}

...something like this.

Kind regards,
Nikolay

Re: Speaker burnout

[Ricard Wanderlof]

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.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: bug

[Ricard Wanderlof]

Sorry, I just can't keep silent on this... though I fear this will go 
nowhere ... :-(

On Tue, 31 Mar 2015, Nikita N. wrote:

> [ ... ] software is verified can damage the speakers, if not used 
> somehow correctly.
> ...
> We were hoping in some form of amend from yourself, about the dangerous
> software you produced and distributed to public.
> ...
> We were hoping at least in a simple warning popping up from your tool,
> when user sets any "hazardous" levels.

There is nothing wrong with the software. As MAarten points out, it does 
the same as any other mixer software. There is a problem with the 
hardware. It is akin to turning up the volume control on your stereo 
system and burning out the speakers in your room. If that happens, you 
have a hardware combination that is incorrectly a designed (i.e. your 
amplifier is too powerful for your speakers), it's not your hand with 
which you turned up the volume that is is 'dangerous'.

I appreciate that users might be upset when that happens, and rightly so, 
however, they should be upset with the hardware design, i.e. in this case 
the PC manufacturer.

In essence, a PC that behaves this way is broken, and if it starts 
emitting smoke when this happens it might even be dangerous and should be 
returned to the manufacturer for replacement. Period.

The same thing would apply if the power supply catches fire while playing 
a CPU- and graphic intensive game, because the large amount of power 
needed. Faulty hardware. Replace it, or buy a reputable brand next time.

That said, with some proper input we might be able to minimize the problem 
in software, given the proper help about which levels are considered 
"dangerous". That is something that must be determined for each specific 
hardware, there is no "dangerous" level from a software point of view.

> We were hoping at least-least in a warning popping up from your tool at
> runtime, something like "Warning: improper settings for this level, this
> level and this might result in damages to your audio devices".

There is no such level that the software can know about. Setting the 
output levels to maximum is not necessarily bad, wrong or dangerous. It 
depends on the hardware, and very likely hardware which the software can 
not know about (such as the exact type of speakers).

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Speaker burnout

[David Henningsson]

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

Re: bug

[Clemens Ladisch]

Nikita N. wrote:
>> http://www.iua.upf.es/~mdeboer/projects/alsamixergui/
>
> this link is broken, please provide a correct one

This is the last known link.

>> Please note that _every_ mixer application on _every_ OS might be able
>> to set the controls to those dangerous values.
>
> is it "might" or it is?

I was not able to test all of them.  But I would be surprised if there
is any mixer that knows about this broken hardware and somehow restricts
the mixer ranges.

> Is also your alsamixer textual version tool, capable of speakers
> burnout?

As I already wrote above, on that hardware, I estimate that _every_
mixer tool is capable of that.


Regards,
Clemens

Re: Speaker burnout

[Torsten Schenk]

Hi everyone,

I also followed the discussion.
First of all I have to agree to Maarten that I dont' like your,
Nikita's, tone here on the list. First of all, why are you complaining?
As you can see, many people now are trying to figure out what to do to
fix this. But instead you keep blaming, accusing and offending
Maarten. He is right that a mixer application just allows controlling
those parameters the hardware tells to be manipulatable. So the tool
CANNOT be held responsible. Popping up warnings will be annoying for all
the users that NEED to set the volume to a high level and would be
overkill if just very few devices are to be addressed.

Regarding the technical side of this: Since it interested me if this
happened to other people, I found this post:

http://marcin.juszkiewicz.com.pl/2012/12/10/how-to-fry-speakers-in-your-chromebook/

and the previous post on this site.
So it seems that on a Samsung Chromebook you can definitively burn your
speakers. One comment inside these post I found noticeable:

> I’m guessing that a path was set up from MIC1 (wired to DMIC in) to
> the left speaker output. Playing the digital mic input as analog at
> full volume seems like something that might cause speaker failure, and
> wouldn’t necessarily be audible while it is happening.

So this would indicate that not the volume level causes the damage but
a bad audio routing.

Regards,
Torsten

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Speaker burnout

[Nikita N.]

Dear Torsten,

> Nikita's, tone here on the list. First of all, why are you complaining?

as matter of fact, and as already said, we are not blaming anyone.
Also, our complains are now definitely over.
"The Ubuntu community is built on the ideas enshrined in the Ubuntu
Manifesto: that software should be available free of charge, that
software tools should be usable by people in their local language and
despite any disabilities, and that people should have the freedom to
customize and alter their software in whatever way they see fit."
If Mr. Maarten see fit this software as he really wishes, nobody can
complain, as long as the identity of the owner of the software is well
clear and known.
If further issues will rise, the Linux community will know the owner
identity, and contact him directly in the most appropriate way.

> As you can see, many people now are trying to figure out what to do to fix this.
We are very happy about that, and again we apologize if our tones has
been matter of misunderstanding.
We are now sure a proper solution will be found.
By now, waiting for a more stable solutions, we would like to suggest,
if possible, please add a very simple popup, only a single one when
alsamixer-text and/or alsamixergui are run, with such similar message:
"Caution: incorrect settings might cause damage to your audio devices".
That would save us from doing it ourselves, at import time.
Thank you for your attention, and please keep up with your outstanding
achievements.

-- 
  Nikita N.
  nikitan@operamail.com


On Tue, Mar 31, 2015, at 06:47 AM, Torsten Schenk wrote:
> Hi everyone,
> 
> I also followed the discussion.
> First of all I have to agree to Maarten that I dont' like your,
> Nikita's, tone here on the list. First of all, why are you complaining?
> As you can see, many people now are trying to figure out what to do to
> fix this. But instead you keep blaming, accusing and offending
> Maarten. He is right that a mixer application just allows controlling
> those parameters the hardware tells to be manipulatable. So the tool
> CANNOT be held responsible. Popping up warnings will be annoying for all
> the users that NEED to set the volume to a high level and would be
> overkill if just very few devices are to be addressed.
> 
> Regarding the technical side of this: Since it interested me if this
> happened to other people, I found this post:
> 
> http://marcin.juszkiewicz.com.pl/2012/12/10/how-to-fry-speakers-in-your-chromebook/
> 
> and the previous post on this site.
> So it seems that on a Samsung Chromebook you can definitively burn your
> speakers. One comment inside these post I found noticeable:
> 
> > I’m guessing that a path was set up from MIC1 (wired to DMIC in) to
> > the left speaker output. Playing the digital mic input as analog at
> > full volume seems like something that might cause speaker failure, and
> > wouldn’t necessarily be audible while it is happening.
> 
> So this would indicate that not the volume level causes the damage but
> a bad audio routing.
> 
> Regards,
> Torsten
> 

-- 
http://www.fastmail.com - Access all of your messages and folders
                          wherever you are

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Speaker burnout

[Takashi Iwai]

At Tue, 31 Mar 2015 12:43:25 +0200,
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?

It's the safest (and likely easiest) band aid, yes.


Takashi

Re: Speaker burnout

[Takashi Iwai]

At Tue, 31 Mar 2015 12:14:20 -0700,
Nikita N. wrote:
> 
> Dear Torsten,
> 
> > Nikita's, tone here on the list. First of all, why are you complaining?
> 
> as matter of fact, and as already said, we are not blaming anyone.
> Also, our complains are now definitely over.
> "The Ubuntu community is built on the ideas enshrined in the Ubuntu
> Manifesto: that software should be available free of charge, that
> software tools should be usable by people in their local language and
> despite any disabilities, and that people should have the freedom to
> customize and alter their software in whatever way they see fit."
> If Mr. Maarten see fit this software as he really wishes, nobody can
> complain, as long as the identity of the owner of the software is well
> clear and known.
> If further issues will rise, the Linux community will know the owner
> identity, and contact him directly in the most appropriate way.
> 
> > As you can see, many people now are trying to figure out what to do to fix this.
> We are very happy about that, and again we apologize if our tones has
> been matter of misunderstanding.
> We are now sure a proper solution will be found.
> By now, waiting for a more stable solutions, we would like to suggest,
> if possible, please add a very simple popup, only a single one when
> alsamixer-text and/or alsamixergui are run, with such similar message:
> "Caution: incorrect settings might cause damage to your audio devices".
> That would save us from doing it ourselves, at import time.
> Thank you for your attention, and please keep up with your outstanding
> achievements.

Well, if we were selling a microwave oven and dealing with a customer
who places a poor cat into our product, then we might need to put such
a sticker on it.

However, alsamixer is just a basic tool like a screw driver.  A screw
driver (as far as I know) has no warning sticker showing "this tool
might cause damage to your precious machine."

BTW, Chromebook is essentially a "big" embedded device.  And, the
audio driver for embedded devices usually provides the all possible
buttons and knobs for manual adjustment.  Some of them are known to be
dangerous to play with, and they are usually hidden under some layers
in Android or Chrome OS, only the safe setup are provided via UCM
profile or such.  But once when you play directly with the hardware,
you need to know what you're tweaking.  Something serious like this
can happen.  It's why everywhere a text "at your own risk" is seen.

This is the way we went through over 20 years ago for PC components.
Now it's back as a different form.  Interesting...


Takashi

> 
> -- 
>   Nikita N.
>   nikitan@operamail.com
> 
> 
> On Tue, Mar 31, 2015, at 06:47 AM, Torsten Schenk wrote:
> > Hi everyone,
> > 
> > I also followed the discussion.
> > First of all I have to agree to Maarten that I dont' like your,
> > Nikita's, tone here on the list. First of all, why are you complaining?
> > As you can see, many people now are trying to figure out what to do to
> > fix this. But instead you keep blaming, accusing and offending
> > Maarten. He is right that a mixer application just allows controlling
> > those parameters the hardware tells to be manipulatable. So the tool
> > CANNOT be held responsible. Popping up warnings will be annoying for all
> > the users that NEED to set the volume to a high level and would be
> > overkill if just very few devices are to be addressed.
> > 
> > Regarding the technical side of this: Since it interested me if this
> > happened to other people, I found this post:
> > 
> > http://marcin.juszkiewicz.com.pl/2012/12/10/how-to-fry-speakers-in-your-chromebook/
> > 
> > and the previous post on this site.
> > So it seems that on a Samsung Chromebook you can definitively burn your
> > speakers. One comment inside these post I found noticeable:
> > 
> > > I’m guessing that a path was set up from MIC1 (wired to DMIC in) to
> > > the left speaker output. Playing the digital mic input as analog at
> > > full volume seems like something that might cause speaker failure, and
> > > wouldn’t necessarily be audible while it is happening.
> > 
> > So this would indicate that not the volume level causes the damage but
> > a bad audio routing.
> > 
> > Regards,
> > Torsten
> > 
> 
> -- 
> http://www.fastmail.com - Access all of your messages and folders
>                           wherever you are
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Speaker burnout

[Eliot Blennerhassett]

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.
--
Eliot

Re: Speaker burnout

[David Henningsson]

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

Re: Speaker burnout

[Clemens Ladisch]

David Henningsson wrote:
> On 2015-04-07 07:30, Eliot Blennerhassett wrote:
>> The signal when recorded is 1325Hz rail to rail square wave.
>> [...]
>
> 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?

Of course.  The problem is the speakers, not the feedback itself.

When connecting some random speaker to some random amp, it is quite
possible to burn it out:
<https://www.google.com/search?q=tweeter+burn-out>
However, this should not happen inside a closed system where amp and
speakers were designed for each other.

> Or is there something that causes the feedback tone to be of a larger
> amplitude than could ever be produced by the wave file?

In theory, it would be possible to do the mixing in the analog domain.
But there is no way to find out what the HDA codec actually does except
trying it out.


Regards,
Clemens

Re: Speaker burnout

[Eliot Blennerhassett]

On 07/04/15 19:26, Clemens Ladisch wrote:

> In theory, it would be possible to do the mixing in the analog domain.
> But there is no way to find out what the HDA codec actually does except
> trying it out.


Dear testers, please perform the following steps:

1. Place laptop on heat-resistant surface in a well-ventilated space.
Have a fire extinguisher handy.  Put on your earmuffs.
2. Start stopwatch
3. Set all alsa volumes to maximum
3.1 If screaming noise not already evident, play this full-scale square wave
4.1 If smoke or flames appear from your laptop, stop stopwatch.
Extinguish any flames.
4.2 If 30 seconds elapsed without smoke, terminate the test.
5. Report back to us the results, if necessary borrow a friend's
computer to do so.

Hmmm, why isn't anyone volunteering to do this testing?

Seriously, How is the safe limit going to be determined?

Re: Speaker burnout

[David Henningsson]

On 2015-04-07 09:49, Eliot Blennerhassett wrote:
> On 07/04/15 19:26, Clemens Ladisch wrote:
>
>> In theory, it would be possible to do the mixing in the analog domain.
>> But there is no way to find out what the HDA codec actually does except
>> trying it out.
>
>
> Dear testers, please perform the following steps:
>
> 1. Place laptop on heat-resistant surface in a well-ventilated space.
> Have a fire extinguisher handy.  Put on your earmuffs.
> 2. Start stopwatch
> 3. Set all alsa volumes to maximum
> 3.1 If screaming noise not already evident, play this full-scale square wave
> 4.1 If smoke or flames appear from your laptop, stop stopwatch.
> Extinguish any flames.
> 4.2 If 30 seconds elapsed without smoke, terminate the test.
> 5. Report back to us the results, if necessary borrow a friend's
> computer to do so.
>
> Hmmm, why isn't anyone volunteering to do this testing?
>
> Seriously, How is the safe limit going to be determined?

I think Alexander had a good idea:

http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/089815.html

...now if this is chromebook, and I'm not sure whether that's the case 
or not, maybe "Windows" should be replaced with "Chrome OS", but anyhow 
- check what the supported OS is doing, and I believe Alexander 
suggested a safe way to do so.

Nikita - here's your chance to show that you're actually interested in 
getting the bug fixed, and not only to discuss whether alsamixer is a 
screwdriver or a microwave. On the physical hardware that has this 
problem, please perform the tests as Alexander suggested. And also run 
the alsa-info script on that hardware, and submit the result here.

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

Re: Speaker burnout

[Ricard Wanderlof]

On Tue, 7 Apr 2015, Eliot Blennerhassett wrote:

> 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?

Can it be used to provide a side tone (telephone system terminology for 
feeding back a portion of the microphone signal to the ear piece in a 
telephone; psychologically it helps avoid the impression that the 
telephone is not connected, so all telephone type equipment have it since 
the birth of telephone technology) in telephone applications?

> 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.

This sounds like a useful suggestion to me. Many applications have an 
'advanced' option or button which enables things you normally don't need. 
If the 'mic to playback' function isn't really used normally it would seem 
a reasonable option but I suppose that needs to be researched first 
whether it really is of little use.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30