* bug @ 2015-03-28 14:03 Nikita N. 2015-03-30 7:19 ` bug Clemens Ladisch 0 siblings, 1 reply; 36+ messages in thread From: Nikita N. @ 2015-03-28 14:03 UTC (permalink / raw) To: alsa-devel is any programmer listening here? -- http://www.fastmail.com - A no graphics, no pop-ups email service ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-28 14:03 bug Nikita N. @ 2015-03-30 7:19 ` Clemens Ladisch 2015-03-30 10:27 ` bug Nikita N. 0 siblings, 1 reply; 36+ messages in thread From: Clemens Ladisch @ 2015-03-30 7:19 UTC (permalink / raw) To: Nikita N., alsa-devel Nikita N. wrote: > is any programmer listening here? No. But several are reading here. Regards, Clemens ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-30 7:19 ` bug Clemens Ladisch @ 2015-03-30 10:27 ` Nikita N. 2015-03-30 11:13 ` bug Clemens Ladisch 0 siblings, 1 reply; 36+ messages in thread From: Nikita N. @ 2015-03-30 10:27 UTC (permalink / raw) To: Clemens Ladisch, alsa-devel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-30 10:27 ` bug Nikita N. @ 2015-03-30 11:13 ` Clemens Ladisch 2015-03-30 14:37 ` bug Nikita N. 0 siblings, 1 reply; 36+ messages in thread From: Clemens Ladisch @ 2015-03-30 11:13 UTC (permalink / raw) To: Nikita N., alsa-devel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-30 11:13 ` bug Clemens Ladisch @ 2015-03-30 14:37 ` Nikita N. 2015-03-31 7:18 ` bug Eliot Blennerhassett ` (3 more replies) 0 siblings, 4 replies; 36+ messages in thread From: Nikita N. @ 2015-03-30 14:37 UTC (permalink / raw) To: Clemens Ladisch, alsa-devel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-30 14:37 ` bug Nikita N. @ 2015-03-31 7:18 ` Eliot Blennerhassett 2015-03-31 8:19 ` bug Nikita N. 2015-03-31 8:24 ` bug Ricard Wanderlof ` (2 subsequent siblings) 3 siblings, 1 reply; 36+ messages in thread From: Eliot Blennerhassett @ 2015-03-31 7:18 UTC (permalink / raw) To: Nikita N., alsa-devel; +Cc: Clemens Ladisch 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 7:18 ` bug Eliot Blennerhassett @ 2015-03-31 8:19 ` Nikita N. 2015-03-31 8:38 ` bug Clemens Ladisch 2015-03-31 8:41 ` potential speaker burnout Eliot Blennerhassett 0 siblings, 2 replies; 36+ messages in thread From: Nikita N. @ 2015-03-31 8:19 UTC (permalink / raw) To: Eliot Blennerhassett, alsa-devel; +Cc: Clemens Ladisch > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 8:19 ` bug Nikita N. @ 2015-03-31 8:38 ` Clemens Ladisch 2015-03-31 9:05 ` bug Nikita N. 2015-03-31 8:41 ` potential speaker burnout Eliot Blennerhassett 1 sibling, 1 reply; 36+ messages in thread From: Clemens Ladisch @ 2015-03-31 8:38 UTC (permalink / raw) To: Nikita N.; +Cc: alsa-devel, Eliot Blennerhassett 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 8:38 ` bug Clemens Ladisch @ 2015-03-31 9:05 ` Nikita N. 2015-03-31 12:42 ` bug Clemens Ladisch 0 siblings, 1 reply; 36+ messages in thread From: Nikita N. @ 2015-03-31 9:05 UTC (permalink / raw) To: Clemens Ladisch; +Cc: alsa-devel, Eliot Blennerhassett > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 9:05 ` bug Nikita N. @ 2015-03-31 12:42 ` Clemens Ladisch 0 siblings, 0 replies; 36+ messages in thread From: Clemens Ladisch @ 2015-03-31 12:42 UTC (permalink / raw) To: Nikita N.; +Cc: alsa-devel, Eliot Blennerhassett 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: potential speaker burnout 2015-03-31 8:19 ` bug Nikita N. 2015-03-31 8:38 ` bug Clemens Ladisch @ 2015-03-31 8:41 ` Eliot Blennerhassett 1 sibling, 0 replies; 36+ messages in thread From: Eliot Blennerhassett @ 2015-03-31 8:41 UTC (permalink / raw) To: Nikita N., alsa-devel; +Cc: Clemens Ladisch 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-30 14:37 ` bug Nikita N. 2015-03-31 7:18 ` bug Eliot Blennerhassett @ 2015-03-31 8:24 ` Ricard Wanderlof 2015-03-31 8:56 ` bug Nikita N. 2015-03-31 8:54 ` bug Eliot Blennerhassett 2015-03-31 9:34 ` Speaker burnout David Henningsson 3 siblings, 1 reply; 36+ messages in thread From: Ricard Wanderlof @ 2015-03-31 8:24 UTC (permalink / raw) To: Nikita N.; +Cc: alsa-devel, Clemens Ladisch 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 8:24 ` bug Ricard Wanderlof @ 2015-03-31 8:56 ` Nikita N. 2015-03-31 9:14 ` bug Ricard Wanderlof 0 siblings, 1 reply; 36+ messages in thread From: Nikita N. @ 2015-03-31 8:56 UTC (permalink / raw) To: Ricard Wanderlof; +Cc: alsa-devel, Clemens Ladisch > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 8:56 ` bug Nikita N. @ 2015-03-31 9:14 ` Ricard Wanderlof 2015-03-31 10:26 ` bug Maarten de Boer 0 siblings, 1 reply; 36+ messages in thread From: Ricard Wanderlof @ 2015-03-31 9:14 UTC (permalink / raw) To: Nikita N.; +Cc: alsa-devel, Clemens Ladisch 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 9:14 ` bug Ricard Wanderlof @ 2015-03-31 10:26 ` Maarten de Boer 2015-03-31 10:49 ` bug Nikita N. 0 siblings, 1 reply; 36+ messages in thread From: Maarten de Boer @ 2015-03-31 10:26 UTC (permalink / raw) To: Nikita N.; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 10:26 ` bug Maarten de Boer @ 2015-03-31 10:49 ` Nikita N. 2015-03-31 11:05 ` bug Maarten de Boer 2015-03-31 11:44 ` bug Ricard Wanderlof 0 siblings, 2 replies; 36+ messages in thread From: Nikita N. @ 2015-03-31 10:49 UTC (permalink / raw) To: Maarten de Boer; +Cc: 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 > -- 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 10:49 ` bug Nikita N. @ 2015-03-31 11:05 ` Maarten de Boer 2015-03-31 11:44 ` bug Ricard Wanderlof 1 sibling, 0 replies; 36+ messages in thread From: Maarten de Boer @ 2015-03-31 11:05 UTC (permalink / raw) To: Nikita N.; +Cc: 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-31 10:49 ` bug Nikita N. 2015-03-31 11:05 ` bug Maarten de Boer @ 2015-03-31 11:44 ` Ricard Wanderlof 1 sibling, 0 replies; 36+ messages in thread From: Ricard Wanderlof @ 2015-03-31 11:44 UTC (permalink / raw) To: Nikita N.; +Cc: alsa-devel, Maarten de Boer 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: bug 2015-03-30 14:37 ` bug Nikita N. 2015-03-31 7:18 ` bug Eliot Blennerhassett 2015-03-31 8:24 ` bug Ricard Wanderlof @ 2015-03-31 8:54 ` Eliot Blennerhassett 2015-03-31 9:34 ` Speaker burnout David Henningsson 3 siblings, 0 replies; 36+ messages in thread From: Eliot Blennerhassett @ 2015-03-31 8:54 UTC (permalink / raw) To: alsa-devel (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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-30 14:37 ` bug Nikita N. ` (2 preceding siblings ...) 2015-03-31 8:54 ` bug Eliot Blennerhassett @ 2015-03-31 9:34 ` David Henningsson 2015-03-31 10:06 ` Nikita N. 3 siblings, 1 reply; 36+ messages in thread From: David Henningsson @ 2015-03-31 9:34 UTC (permalink / raw) To: Nikita N., Clemens Ladisch, alsa-devel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 9:34 ` Speaker burnout David Henningsson @ 2015-03-31 10:06 ` Nikita N. 2015-03-31 10:43 ` David Henningsson 0 siblings, 1 reply; 36+ messages in thread From: Nikita N. @ 2015-03-31 10:06 UTC (permalink / raw) To: David Henningsson, Clemens Ladisch, alsa-devel > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 10:06 ` Nikita N. @ 2015-03-31 10:43 ` David Henningsson 2015-03-31 10:57 ` Alexander E. Patrakov ` (4 more replies) 0 siblings, 5 replies; 36+ messages in thread From: David Henningsson @ 2015-03-31 10:43 UTC (permalink / raw) To: Nikita N., Clemens Ladisch, alsa-devel, Takashi Iwai 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 10:43 ` David Henningsson @ 2015-03-31 10:57 ` Alexander E. Patrakov 2015-03-31 11:23 ` Nikolay Dimitrov ` (3 subsequent siblings) 4 siblings, 0 replies; 36+ messages in thread From: Alexander E. Patrakov @ 2015-03-31 10:57 UTC (permalink / raw) To: David Henningsson, Nikita N., Clemens Ladisch, alsa-devel, Takashi Iwai 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 10:43 ` David Henningsson 2015-03-31 10:57 ` Alexander E. Patrakov @ 2015-03-31 11:23 ` Nikolay Dimitrov 2015-03-31 11:31 ` Ricard Wanderlof ` (2 subsequent siblings) 4 siblings, 0 replies; 36+ messages in thread From: Nikolay Dimitrov @ 2015-03-31 11:23 UTC (permalink / raw) To: David Henningsson; +Cc: Takashi Iwai, Clemens Ladisch, alsa-devel, Nikita N. 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 10:43 ` David Henningsson 2015-03-31 10:57 ` Alexander E. Patrakov 2015-03-31 11:23 ` Nikolay Dimitrov @ 2015-03-31 11:31 ` Ricard Wanderlof 2015-03-31 11:45 ` David Henningsson 2015-04-05 16:11 ` Takashi Iwai 2015-04-07 5:30 ` Eliot Blennerhassett 4 siblings, 1 reply; 36+ messages in thread From: Ricard Wanderlof @ 2015-03-31 11:31 UTC (permalink / raw) To: David Henningsson; +Cc: Takashi Iwai, Clemens Ladisch, alsa-devel, Nikita N. 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 11:31 ` Ricard Wanderlof @ 2015-03-31 11:45 ` David Henningsson 2015-03-31 13:47 ` Torsten Schenk 0 siblings, 1 reply; 36+ messages in thread From: David Henningsson @ 2015-03-31 11:45 UTC (permalink / raw) To: Ricard Wanderlof; +Cc: Takashi Iwai, Clemens Ladisch, alsa-devel, Nikita N. 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 11:45 ` David Henningsson @ 2015-03-31 13:47 ` Torsten Schenk 2015-03-31 19:14 ` Nikita N. 0 siblings, 1 reply; 36+ messages in thread From: Torsten Schenk @ 2015-03-31 13:47 UTC (permalink / raw) To: David Henningsson Cc: Takashi Iwai, Clemens Ladisch, alsa-devel, Ricard Wanderlof, Nikita N. 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 13:47 ` Torsten Schenk @ 2015-03-31 19:14 ` Nikita N. 2015-04-05 16:36 ` Takashi Iwai 0 siblings, 1 reply; 36+ messages in thread From: Nikita N. @ 2015-03-31 19:14 UTC (permalink / raw) To: Torsten Schenk, David Henningsson Cc: Takashi Iwai, Clemens Ladisch, alsa-devel, Ricard Wanderlof 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 19:14 ` Nikita N. @ 2015-04-05 16:36 ` Takashi Iwai 0 siblings, 0 replies; 36+ messages in thread From: Takashi Iwai @ 2015-04-05 16:36 UTC (permalink / raw) To: Nikita N. Cc: Clemens Ladisch, alsa-devel, Torsten Schenk, Ricard Wanderlof, David Henningsson 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 10:43 ` David Henningsson ` (2 preceding siblings ...) 2015-03-31 11:31 ` Ricard Wanderlof @ 2015-04-05 16:11 ` Takashi Iwai 2015-04-07 5:30 ` Eliot Blennerhassett 4 siblings, 0 replies; 36+ messages in thread From: Takashi Iwai @ 2015-04-05 16:11 UTC (permalink / raw) To: David Henningsson; +Cc: Clemens Ladisch, alsa-devel, Nikita N. 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-03-31 10:43 ` David Henningsson ` (3 preceding siblings ...) 2015-04-05 16:11 ` Takashi Iwai @ 2015-04-07 5:30 ` Eliot Blennerhassett 2015-04-07 7:09 ` David Henningsson 2015-04-07 11:29 ` Ricard Wanderlof 4 siblings, 2 replies; 36+ messages in thread From: Eliot Blennerhassett @ 2015-04-07 5:30 UTC (permalink / raw) To: David Henningsson, Nikita N., Clemens Ladisch, alsa-devel, Takashi Iwai 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-04-07 5:30 ` Eliot Blennerhassett @ 2015-04-07 7:09 ` David Henningsson 2015-04-07 7:26 ` Clemens Ladisch 2015-04-07 11:29 ` Ricard Wanderlof 1 sibling, 1 reply; 36+ messages in thread From: David Henningsson @ 2015-04-07 7:09 UTC (permalink / raw) To: Eliot Blennerhassett, Nikita N., Clemens Ladisch, alsa-devel, Takashi Iwai 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-04-07 7:09 ` David Henningsson @ 2015-04-07 7:26 ` Clemens Ladisch 2015-04-07 7:49 ` Eliot Blennerhassett 0 siblings, 1 reply; 36+ messages in thread From: Clemens Ladisch @ 2015-04-07 7:26 UTC (permalink / raw) To: David Henningsson Cc: Takashi Iwai, alsa-devel, Nikita N., Eliot Blennerhassett 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-04-07 7:26 ` Clemens Ladisch @ 2015-04-07 7:49 ` Eliot Blennerhassett 2015-04-07 10:55 ` David Henningsson 0 siblings, 1 reply; 36+ messages in thread From: Eliot Blennerhassett @ 2015-04-07 7:49 UTC (permalink / raw) To: Clemens Ladisch, David Henningsson; +Cc: Takashi Iwai, alsa-devel, Nikita N. 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? ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-04-07 7:49 ` Eliot Blennerhassett @ 2015-04-07 10:55 ` David Henningsson 0 siblings, 0 replies; 36+ messages in thread From: David Henningsson @ 2015-04-07 10:55 UTC (permalink / raw) To: Eliot Blennerhassett, Clemens Ladisch; +Cc: Takashi Iwai, alsa-devel, Nikita N. 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Speaker burnout 2015-04-07 5:30 ` Eliot Blennerhassett 2015-04-07 7:09 ` David Henningsson @ 2015-04-07 11:29 ` Ricard Wanderlof 1 sibling, 0 replies; 36+ messages in thread From: Ricard Wanderlof @ 2015-04-07 11:29 UTC (permalink / raw) To: Eliot Blennerhassett Cc: Takashi Iwai, Clemens Ladisch, alsa-devel, Nikita N., David Henningsson 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2015-04-07 11:29 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-28 14:03 bug Nikita N. 2015-03-30 7:19 ` bug Clemens Ladisch 2015-03-30 10:27 ` bug Nikita N. 2015-03-30 11:13 ` bug Clemens Ladisch 2015-03-30 14:37 ` bug Nikita N. 2015-03-31 7:18 ` bug Eliot Blennerhassett 2015-03-31 8:19 ` bug Nikita N. 2015-03-31 8:38 ` bug Clemens Ladisch 2015-03-31 9:05 ` bug Nikita N. 2015-03-31 12:42 ` bug Clemens Ladisch 2015-03-31 8:41 ` potential speaker burnout Eliot Blennerhassett 2015-03-31 8:24 ` bug Ricard Wanderlof 2015-03-31 8:56 ` bug Nikita N. 2015-03-31 9:14 ` bug Ricard Wanderlof 2015-03-31 10:26 ` bug Maarten de Boer 2015-03-31 10:49 ` bug Nikita N. 2015-03-31 11:05 ` bug Maarten de Boer 2015-03-31 11:44 ` bug Ricard Wanderlof 2015-03-31 8:54 ` bug Eliot Blennerhassett 2015-03-31 9:34 ` Speaker burnout David Henningsson 2015-03-31 10:06 ` Nikita N. 2015-03-31 10:43 ` David Henningsson 2015-03-31 10:57 ` Alexander E. Patrakov 2015-03-31 11:23 ` Nikolay Dimitrov 2015-03-31 11:31 ` Ricard Wanderlof 2015-03-31 11:45 ` David Henningsson 2015-03-31 13:47 ` Torsten Schenk 2015-03-31 19:14 ` Nikita N. 2015-04-05 16:36 ` Takashi Iwai 2015-04-05 16:11 ` Takashi Iwai 2015-04-07 5:30 ` Eliot Blennerhassett 2015-04-07 7:09 ` David Henningsson 2015-04-07 7:26 ` Clemens Ladisch 2015-04-07 7:49 ` Eliot Blennerhassett 2015-04-07 10:55 ` David Henningsson 2015-04-07 11:29 ` Ricard Wanderlof
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.