is any programmer listening here?
is anybody here aware that latest alsamixergui has a bug capable of produce irreversible damage to internal laptop speakers?
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.
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
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. 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
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. wrote:
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
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.
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
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.
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
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
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
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
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
(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.
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.
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
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.
31.03.2015 15:43, David Henningsson wrote:
- 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.
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:
- Gather consensus that limit the maximum volume on internal
speakers is the right way forward. Takashi, Clemens, anyone against that strategy?
- 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.
- 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
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:
- Gather consensus that limit the maximum volume on internal speakers
is the right way forward. Takashi, Clemens, anyone against that strategy?
- 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.
- 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
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:
- Gather consensus that limit the maximum volume on internal speakers
is the right way forward. Takashi, Clemens, anyone against that strategy?
- 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.
- 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).
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-chro...
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
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.
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-chro...
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
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:
- 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
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:
- 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
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:
- 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 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
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?
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:
- 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.
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
participants (10)
-
Alexander E. Patrakov -
Clemens Ladisch -
David Henningsson -
Eliot Blennerhassett -
Maarten de Boer -
Nikita N. -
Nikolay Dimitrov -
Ricard Wanderlof -
Takashi Iwai -
Torsten Schenk