bug

bug

[Mattia Bertoni]

finally I can report a bug which I encountered some time ago; I send you 
the important part of the entire log, which is to much big to be posted:

Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: snd_pcm_avail() returned a value that is exceptionally 
large: 420736 bytes (2191 ms).
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: Most likely this is a bug in the ALSA driver 
'snd_intel8x0'. Please report this issue to the ALSA developers.
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: snd_pcm_dump():
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: Hardware PCM card 0 'NVidia CK804' device 0 subdevice 0
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: Its setup is:
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   stream       : PLAYBACK
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   access       : MMAP_INTERLEAVED
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   format       : S16_LE
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   subformat    : STD
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   channels     : 2
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   rate         : 48000
Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   exact rate   : 48000 (48000/1)
Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   msbits       : 16
Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   buffer_size  : 16384
Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   period_size  : 16384
Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   period_time  : 341333
Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   tstamp_mode  : ENABLE
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   period_step  : 1
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   avail_min    : 16384
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   period_event : 0
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   start_threshold  : -1
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   stop_threshold   : 4611686018427387904
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   silence_threshold: 0
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   silence_size : 0
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   boundary     : 4611686018427387904
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   appl_ptr     : 26406104
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   hw_ptr       : 26494904
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: snd_pcm_delay() returned a value that is exceptionally 
large: -465056 bytes (-2422 ms).
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: Most likely this is a bug in the ALSA driver 
'snd_intel8x0'. Please report this issue to the ALSA developers.
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: snd_pcm_dump():
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: Hardware PCM card 0 'NVidia CK804' device 0 subdevice 0
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c: Its setup is:
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   stream       : PLAYBACK
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   access       : MMAP_INTERLEAVED
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   format       : S16_LE
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   subformat    : STD
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   channels     : 2
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   rate         : 48000
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   exact rate   : 48000 (48000/1)
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   msbits       : 16
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   buffer_size  : 16384
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   period_size  : 16384
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   period_time  : 341333
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   tstamp_mode  : ENABLE
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   period_step  : 1
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   avail_min    : 16384
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   period_event : 0
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   start_threshold  : -1
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   stop_threshold   : 4611686018427387904
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   silence_threshold: 0
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   silence_size : 0
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   boundary     : 4611686018427387904
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   appl_ptr     : 26569944
Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
alsa-util.c:   hw_ptr       : 26686208

Re: bug

[Mattia Bertoni]

I uploaded the full log on pastebin:           http://pastebin.com/4whbdz79

I hope this help you!




On 08/07/13 19:14, Mattia Bertoni wrote:
> finally I can report a bug which I encountered some time ago; I send 
> you the important part of the entire log, which is to much big to be 
> posted:
>
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: snd_pcm_avail() returned a value that is exceptionally 
> large: 420736 bytes (2191 ms).
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: Most likely this is a bug in the ALSA driver 
> 'snd_intel8x0'. Please report this issue to the ALSA developers.
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: snd_pcm_dump():
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: Hardware PCM card 0 'NVidia CK804' device 0 subdevice 0
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: Its setup is:
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   stream       : PLAYBACK
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   access       : MMAP_INTERLEAVED
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   format       : S16_LE
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   subformat    : STD
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   channels     : 2
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   rate         : 48000
> Jun 15 18:18:00 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   exact rate   : 48000 (48000/1)
> Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   msbits       : 16
> Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   buffer_size  : 16384
> Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   period_size  : 16384
> Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   period_time  : 341333
> Jun 15 18:18:03 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   tstamp_mode  : ENABLE
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   period_step  : 1
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   avail_min    : 16384
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   period_event : 0
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   start_threshold  : -1
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   stop_threshold   : 4611686018427387904
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   silence_threshold: 0
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   silence_size : 0
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   boundary     : 4611686018427387904
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   appl_ptr     : 26406104
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   hw_ptr       : 26494904
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: snd_pcm_delay() returned a value that is exceptionally 
> large: -465056 bytes (-2422 ms).
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: Most likely this is a bug in the ALSA driver 
> 'snd_intel8x0'. Please report this issue to the ALSA developers.
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: snd_pcm_dump():
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: Hardware PCM card 0 'NVidia CK804' device 0 subdevice 0
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c: Its setup is:
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   stream       : PLAYBACK
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   access       : MMAP_INTERLEAVED
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   format       : S16_LE
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   subformat    : STD
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   channels     : 2
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   rate         : 48000
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   exact rate   : 48000 (48000/1)
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   msbits       : 16
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   buffer_size  : 16384
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   period_size  : 16384
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   period_time  : 341333
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   tstamp_mode  : ENABLE
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   period_step  : 1
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   avail_min    : 16384
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   period_event : 0
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   start_threshold  : -1
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   stop_threshold   : 4611686018427387904
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   silence_threshold: 0
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   silence_size : 0
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   boundary     : 4611686018427387904
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   appl_ptr     : 26569944
> Jun 15 18:18:04 arch-dekstop pulseaudio[776]: [alsa-sink-Intel ICH] 
> alsa-util.c:   hw_ptr       : 26686208

Re: bug

[Takashi Iwai]

At Wed, 07 Aug 2013 19:14:40 +0200,
Mattia Bertoni wrote:
> 
> finally I can report a bug which I encountered some time ago; I send you 
> the important part of the entire log, which is to much big to be posted:

You didn't write what's your problem at all, so no one understands
what to do with it.

In addition, the fundamental information is missing: which machine,
which distro, which kernel and sound systems, and how to reproduce the
problem.  The first few items can be covered by providing the
alsa-info.sh output taken from your machine (at best take it after the
problem appears).


thanks,

Takashi

Re: bug

[Mattia Bertoni]

fortunately I have had this problem only once and more than one month 
ago (15 Jun)
but unfortunately I can't reproduce it because it appeared casually

I'm not a newbie and I knowthis is not the right way to report an issue, 
but these are the all and only information that I have;
anyway other important info are (with the hope you can fix this issue):

Asus A8N-E with nForce4 ultra - CK804 AC'97 Audio Controller (rev a2)
Realtek ALC850 rev 0 at irq 20
snd_intel8x0


archlinux x86_64
kernel3.9.5-1
alsa 1.0.27.1-2
pulseaudio 4.0-2
jack2 1.9.9.5-3

finally I uploaded the output of alsa-info.sh
BUT because I can't reproduce the bug I don't know if this is useful, 
also because it's the output of today in which software is newer:

http://pastebin.com/5SsiVh2u





On 08/08/13 11:00, Takashi Iwai wrote:
> At Wed, 07 Aug 2013 19:14:40 +0200,
> Mattia Bertoni wrote:
>> finally I can report a bug which I encountered some time ago; I send you
>> the important part of the entire log, which is to much big to be posted:
> You didn't write what's your problem at all, so no one understands
> what to do with it.
>
> In addition, the fundamental information is missing: which machine,
> which distro, which kernel and sound systems, and how to reproduce the
> problem.  The first few items can be covered by providing the
> alsa-info.sh output taken from your machine (at best take it after the
> problem appears).
>
>
> thanks,
>
> Takashi

Re: bug

[Takashi Iwai]

At Thu, 08 Aug 2013 11:55:50 +0200,
Mattia Bertoni wrote:
> 
> fortunately I have had this problem only once and more than one month 
> ago (15 Jun)
> but unfortunately I can't reproduce it because it appeared casually

I have no idea *what* problem you're talking about.  (And your mail
subject says only "bug".  Yes, there must be lots of bugs in the
world, virtually and really...)

Please begin with describing what's the problem at first.


Takashi

Re: bug

[Mattia Bertoni]

user-side there is no problem

because alsa logs this issue I report it....




On 08/08/13 12:12, Takashi Iwai wrote:
> At Thu, 08 Aug 2013 11:55:50 +0200,
> Mattia Bertoni wrote:
>> fortunately I have had this problem only once and more than one month
>> ago (15 Jun)
>> but unfortunately I can't reproduce it because it appeared casually
> I have no idea *what* problem you're talking about.  (And your mail
> subject says only "bug".  Yes, there must be lots of bugs in the
> world, virtually and really...)
>
> Please begin with describing what's the problem at first.
>
>
> Takashi

Re: bug

[Takashi Iwai]

At Thu, 08 Aug 2013 12:44:24 +0200,
Mattia Bertoni wrote:
> 
> user-side there is no problem
> 
> because alsa logs this issue I report it....

Ah, so you took the chatty words in the pulseaudio log seriously.
Now I got it.  It's been mostly harmless as long as you don't see any
obvious problems, especially on the old hardware :)


Takashi

> On 08/08/13 12:12, Takashi Iwai wrote:
> > At Thu, 08 Aug 2013 11:55:50 +0200,
> > Mattia Bertoni wrote:
> >> fortunately I have had this problem only once and more than one month
> >> ago (15 Jun)
> >> but unfortunately I can't reproduce it because it appeared casually
> > I have no idea *what* problem you're talking about.  (And your mail
> > subject says only "bug".  Yes, there must be lots of bugs in the
> > world, virtually and really...)
> >
> > Please begin with describing what's the problem at first.
> >
> >
> > Takashi
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

bug

[Nikita N.]

is any programmer listening here?

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

Re: bug

[Clemens Ladisch]

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

No.

But several are reading here.


Regards,
Clemens

Re: bug

[Nikita N.]

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


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

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

Re: bug

[Clemens Ladisch]

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

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

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

What is the bug?


Regards,
Clemens

Re: bug

[Nikita N.]

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

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

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


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

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

Re: bug

[Eliot Blennerhassett]

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

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

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

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

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

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

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

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

regards

Eliot

Re: bug

[Nikita N.]

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

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

-- 
  Nikita N.
  nikitan@operamail.com


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

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

Re: bug

[Ricard Wanderlof]

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

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

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

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

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

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

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

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

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

Re: bug

[Clemens Ladisch]

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

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

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

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


Regards,
Clemens

Re: potential speaker burnout

[Eliot Blennerhassett]

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

You talk about finding the person who is "guilty"

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

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

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

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

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

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

Re: bug

[Eliot Blennerhassett]

(Note - this email now off-list)

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

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

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

Re: bug

[Nikita N.]

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

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

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

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

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

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


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

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

Re: bug

[Nikita N.]

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

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

-- 
  Nikita N.
  nikitan@operamail.com


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

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

Re: bug

[Ricard Wanderlof]

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

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

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

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

Re: Speaker burnout

[David Henningsson]

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

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

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

If you have any concrete examples (alsa-info please!) of speakers that 
can be burned out, and you know a maximum speaker volume where this 
never happens, I think we should artifically lower the max volume to 
this level so that no mixer application can set the speaker volume 
higher than that.

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

Re: Speaker burnout

[Nikita N.]

> If you have any concrete examples (alsa-info please!) of speakers that 
> can be burned out, and you know a maximum speaker volume where this 
As we said, that is not our bug, we are not audio experts, nor any of us
is interested in audio matters.
Nevertheless, we all embrace the Debian/Ubuntu philosophy and Manifesto,
to help in creating a better world, in our small.
For this reason, we feel like we can't just ignore this issue, so
something has to be done to fix it - by who has the proper expertise.
"Ubuntu" is an ancient African word, meaning "humanity to others". The
Ubuntu distribution brings the spirit of Ubuntu to the software world.
We don't bring "humanity to others", programming or distributing any
software which can damage the hardware.


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

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

Re: bug

[Maarten de Boer]

Hello,

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

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

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

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

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

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

Maarten


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

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

Re: Speaker burnout

[David Henningsson]

On 2015-03-31 12:06, Nikita N. wrote:
>> If you have any concrete examples (alsa-info please!) of speakers that
>> can be burned out, and you know a maximum speaker volume where this
> As we said, that is not our bug, we are not audio experts, nor any of us
> is interested in audio matters.

Here's my suggestion how to move forward on this:

  1) Gather consensus that limit the maximum volume on internal speakers 
is the right way forward. Takashi, Clemens, anyone against that strategy?

  2) From the person with the hardware, we will need alsa-info ( 
https://wiki.ubuntu.com/Audio/AlsaInfo ), and also the max volume where 
this does not happen. Is -6 dB good enough? -12 dB? I don't know - this 
is something someone with the hardware must tell us, it cannot simply be 
guessed.

  3) I or someone else can write a kernel patch that limits the maximum 
volume of the speakers to the amount deducted from point 2). Considering 
that we're actually dealing with hardware breakage, this should be sent 
to stable as well. Then no userspace application can set the volume 
higher than our limit.

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

Re: bug

[Nikita N.]

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

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

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

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

Re: Speaker burnout

[Alexander E. Patrakov]

31.03.2015 15:43, David Henningsson wrote:
>   2) From the person with the hardware, we will need alsa-info (
> https://wiki.ubuntu.com/Audio/AlsaInfo ), and also the max volume where
> this does not happen. Is -6 dB good enough? -12 dB? I don't know - this
> is something someone with the hardware must tell us, it cannot simply be
> guessed.

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

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

-- 
Alexander E. Patrakov

Re: bug

[Maarten de Boer]

Hi,

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

Maarten

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

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

Re: Speaker burnout

[Nikolay Dimitrov]

Hi David,

On 03/31/2015 01:43 PM, David Henningsson wrote:
>
>
> On 2015-03-31 12:06, Nikita N. wrote:
>>> If you have any concrete examples (alsa-info please!) of speakers
>>> that can be burned out, and you know a maximum speaker volume
>>> where this
>> As we said, that is not our bug, we are not audio experts, nor any
>> of us is interested in audio matters.
>
> Here's my suggestion how to move forward on this:
>
> 1) Gather consensus that limit the maximum volume on internal
> speakers is the right way forward. Takashi, Clemens, anyone against
> that strategy?
>
> 2) From the person with the hardware, we will need alsa-info (
> https://wiki.ubuntu.com/Audio/AlsaInfo ), and also the max volume
> where this does not happen. Is -6 dB good enough? -12 dB? I don't
> know - this is something someone with the hardware must tell us, it
> cannot simply be guessed.
>
> 3) I or someone else can write a kernel patch that limits the maximum
>  volume of the speakers to the amount deducted from point 2).
> Considering that we're actually dealing with hardware breakage, this
> should be sent to stable as well. Then no userspace application can
> set the volume higher than our limit.

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

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

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

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

...something like this.

Kind regards,
Nikolay

Re: Speaker burnout

[Ricard Wanderlof]

On Tue, 31 Mar 2015, David Henningsson wrote:

> On 2015-03-31 12:06, Nikita N. wrote:
> >> If you have any concrete examples (alsa-info please!) of speakers that
> >> can be burned out, and you know a maximum speaker volume where this
> > As we said, that is not our bug, we are not audio experts, nor any of us
> > is interested in audio matters.
> 
> Here's my suggestion how to move forward on this:
> 
>   1) Gather consensus that limit the maximum volume on internal speakers 
> is the right way forward. Takashi, Clemens, anyone against that strategy?
> 
>   2) From the person with the hardware, we will need alsa-info ( 
> https://wiki.ubuntu.com/Audio/AlsaInfo ), and also the max volume where 
> this does not happen. Is -6 dB good enough? -12 dB? I don't know - this 
> is something someone with the hardware must tell us, it cannot simply be 
> guessed.
> 
>   3) I or someone else can write a kernel patch that limits the maximum 
> volume of the speakers to the amount deducted from point 2). Considering 
> that we're actually dealing with hardware breakage, this should be sent 
> to stable as well. Then no userspace application can set the volume 
> higher than our limit.

While we could technically limit the output level in a driver, the output 
level at which the speakers get damaged must surely depend not only on the 
codec but also on the particular analog output stage driving the speakers 
(assuming it's not built into the codec), the speakers themselves, as well 
as any other hardware on the board, for instance coupling capacitors, or 
potential overload protection circuitry, most of which are components 
which we cannot identify in the driver.

My point is that unless this is a problem with a very specific hardware, 
there's no way the software can actually know what a "dangerous" level 
would be, and hence we cannot limit it in software. What is a "dangerous" 
level in one setup could be an unusably low level in another setup, where 
both setups look identical from a driver point of view.

I'm thinking that any limits must be dependent on a particular hardware 
setup, which means in order to be successful, we would have to extract 
some sort of model name of the system we're actually running on, to be 
compared against some sort of graylist. With the proliferation of model 
names of PC:s, such a list would be sketchy at best.

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

Re: bug

[Ricard Wanderlof]

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

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

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

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

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

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

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

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

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

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

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

Re: Speaker burnout

[David Henningsson]

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

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


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

Re: bug

[Clemens Ladisch]

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

This is the last known link.

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

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

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

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


Regards,
Clemens

Re: Speaker burnout

[Torsten Schenk]

Hi everyone,

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

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

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

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

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

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

Regards,
Torsten

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

Re: Speaker burnout

[Nikita N.]

Dear Torsten,

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

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

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

-- 
  Nikita N.
  nikitan@operamail.com


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

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

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

Re: Speaker burnout

[Takashi Iwai]

At Tue, 31 Mar 2015 12:43:25 +0200,
David Henningsson wrote:
> 
> 
> 
> On 2015-03-31 12:06, Nikita N. wrote:
> >> If you have any concrete examples (alsa-info please!) of speakers that
> >> can be burned out, and you know a maximum speaker volume where this
> > As we said, that is not our bug, we are not audio experts, nor any of us
> > is interested in audio matters.
> 
> Here's my suggestion how to move forward on this:
> 
>   1) Gather consensus that limit the maximum volume on internal speakers 
> is the right way forward. Takashi, Clemens, anyone against that strategy?

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


Takashi

Re: Speaker burnout

[Takashi Iwai]

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

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

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

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

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


Takashi

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

Re: Speaker burnout

[Eliot Blennerhassett]

On 31/03/15 23:43, David Henningsson wrote:
> 
> 
> On 2015-03-31 12:06, Nikita N. wrote:
>>> If you have any concrete examples (alsa-info please!) of speakers that
>>> can be burned out, and you know a maximum speaker volume where this
>> As we said, that is not our bug, we are not audio experts, nor any of us
>> is interested in audio matters.
> 
> Here's my suggestion how to move forward on this:
> 
>  1) Gather consensus that limit the maximum volume on internal speakers
> is the right way forward. Takashi, Clemens, anyone against that strategy?

I'm not sure about this (though in the end it doesn't affect me).  Just
running some experiments on my laptop. (HDA intel PCH sound)

Playing some ordinary music, the level from the internal speakers is
comfortable when master and PCM gains are set to maximum.

At this setting, enabling the internal mic feedthrough with mic boost
set to maximum,  feedback happens when mic playback gain is at -6dB
(max=+12dB).
The signal when recorded is 1325Hz rail to rail square wave.

My point is that in this case for normal usage the maximum output is
fine, I'd even say it is required.  So limiting output would not be a
good idea.
Also when using the mic for speech capture (with headphones for output),
a gain greater than the 'feedback inducing' one is likely to be useful.

So it is (only?) the pathological case of feeding mic direct to speakers
that is problematic.

Given that we can't fix the hardware or wacky user behaviour,
My suggestion would be to either limit, or hide completely the various
"Mic Playback" controls that enable direct feed from input to output.
What is the use case for this anyway? - karaoke?

Given that this goes against the "expose everything in the hardware",
maybe have a module option that can unhide these controls if anybody
actually wants to use them.
--
Eliot

Re: Speaker burnout

[David Henningsson]

On 2015-04-07 07:30, Eliot Blennerhassett wrote:
> On 31/03/15 23:43, David Henningsson wrote:
>>
>>
>> On 2015-03-31 12:06, Nikita N. wrote:
>>>> If you have any concrete examples (alsa-info please!) of speakers that
>>>> can be burned out, and you know a maximum speaker volume where this
>>> As we said, that is not our bug, we are not audio experts, nor any of us
>>> is interested in audio matters.
>>
>> Here's my suggestion how to move forward on this:
>>
>>   1) Gather consensus that limit the maximum volume on internal speakers
>> is the right way forward. Takashi, Clemens, anyone against that strategy?
>
> I'm not sure about this (though in the end it doesn't affect me).  Just
> running some experiments on my laptop. (HDA intel PCH sound)
>
> Playing some ordinary music, the level from the internal speakers is
> comfortable when master and PCM gains are set to maximum.
>
> At this setting, enabling the internal mic feedthrough with mic boost
> set to maximum,  feedback happens when mic playback gain is at -6dB
> (max=+12dB).
> The signal when recorded is 1325Hz rail to rail square wave.
>
> My point is that in this case for normal usage the maximum output is
> fine, I'd even say it is required.  So limiting output would not be a
> good idea.
> Also when using the mic for speech capture (with headphones for output),
> a gain greater than the 'feedback inducing' one is likely to be useful.
>
> So it is (only?) the pathological case of feeding mic direct to speakers
> that is problematic.
>
> Given that we can't fix the hardware or wacky user behaviour,
> My suggestion would be to either limit, or hide completely the various
> "Mic Playback" controls that enable direct feed from input to output.
> What is the use case for this anyway? - karaoke?
>
> Given that this goes against the "expose everything in the hardware",
> maybe have a module option that can unhide these controls if anybody
> actually wants to use them.

On one hand I find your arguments convincing, because limiting internal 
mic playback volume is far less of a limitation (almost no people use 
it), compared to limiting the internal speaker volume.

What bothers me is the following reasoning: If it is possible to burn 
your speakers out by having the speakers outputting some tone caused by 
feedback, would it not be possible to also burn your speakers out by 
simply having a wave file with the same tone and playing it back?

E g, imagine a malicious web page that starts playing this tone back as 
soon as you visit it. Would it be able to cause hardware damage to your 
speakers, if you happened to have the speaker volume at maximum when you 
visited that web page?
Or is there something that causes the feedback tone to be of a larger 
amplitude than could ever be produced by the wave file?

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

Re: Speaker burnout

[Clemens Ladisch]

David Henningsson wrote:
> On 2015-04-07 07:30, Eliot Blennerhassett wrote:
>> The signal when recorded is 1325Hz rail to rail square wave.
>> [...]
>
> If it is possible to burn your speakers out by having the speakers
> outputting some tone caused by feedback, would it not be possible to
> also burn your speakers out by simply having a wave file with the same
> tone and playing it back?

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

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

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

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


Regards,
Clemens

Re: Speaker burnout

[Eliot Blennerhassett]

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

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


Dear testers, please perform the following steps:

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

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

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

Re: Speaker burnout

[David Henningsson]

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

I think Alexander had a good idea:

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

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

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

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

Re: Speaker burnout

[Ricard Wanderlof]

On Tue, 7 Apr 2015, Eliot Blennerhassett wrote:

> At this setting, enabling the internal mic feedthrough with mic boost
> set to maximum,  feedback happens when mic playback gain is at -6dB
> (max=+12dB).
> The signal when recorded is 1325Hz rail to rail square wave.
> 
> My point is that in this case for normal usage the maximum output is
> fine, I'd even say it is required.  So limiting output would not be a
> good idea.
> Also when using the mic for speech capture (with headphones for output),
> a gain greater than the 'feedback inducing' one is likely to be useful.
> 
> So it is (only?) the pathological case of feeding mic direct to speakers
> that is problematic.
> 
> Given that we can't fix the hardware or wacky user behaviour,
> My suggestion would be to either limit, or hide completely the various
> "Mic Playback" controls that enable direct feed from input to output.
> What is the use case for this anyway? - karaoke?

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

> Given that this goes against the "expose everything in the hardware",
> maybe have a module option that can unhide these controls if anybody
> actually wants to use them.

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

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

bug

[liebrecht]

Clearly a problem with Alsa.
Alsa reports  "Most likely this is a bug in the ALSA driver 
'snd_usb_audio'."

Alsa used to work great.
howevere recently it takes 1/2-1hour for pulseaudio to convince alsa to 
make the 1818VSL available.
Jack is not involved at all.
Pulseaudio connects straight to alsa.
Pulseaudio is my saving grace roight now as it perpetually tries to 
initialize and get alsa to present the audio interface, which it 
eventually after an hour does "waking up"

Also sorts of decides to "wake up" and then suddenly the 1818vsl is 
found.

How do I "wake up" alsa so that I can use soundcards.
I cannot wait an hour after reboot or logout to get alsa to work again.


See below


What  happens after starting pulseaudio is that it cycles the 1818 for 
about 1/2 hour to get a link to the 181vsl soundcard. That is the first 
paragraph (1) below which is perpetually cycled by pulseaudio.
Eventually it succeeds which gives the BUG comment as below in paragraph 
(2)
-------------------------------------------------------
1)
E: [pulseaudio] udev-util.c: Failed to get card object.
E: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
E: [pulseaudio] module.c: Failed to load module "module-alsa-card" 
(argument: "device_id="3" name="usb-PreSonus_AudioBox_1818_VSL_2209-00" 
card_name="alsa_card.usb-PreSonus_Audio.Box_1818_VSL_2209-00" 
namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no 
deferred_volume=yes use_ucm=yes 
card_properties="module-udev-detect.discovered=1""): initialization 
failed.
(**Note this message is cycled for an hour**)

2)
(**Then miraculously....Alsa wakes up and pulseaudio can connect to 
1818vsl **)
E: [alsa-sink-USB Audio] alsa-sink.c: ALSA woke us up to write new data 
to the device, but there was actually nothing to write.
E: [alsa-sink-USB Audio] alsa-sink.c: Most likely this is a bug in the 
ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA 
developers.
E: [alsa-sink-USB Audio] alsa-sink.c: We were woken up with POLLOUT set 
-- however a subsequent snd_pcm_avail() returned 0 or another value < 
min_avail.

------------------------------------------------------


Dont know what happened top Also to behave this way.
Maybe someone has an idea ?





upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.64
!!################################

!!Script ran on: Mon Sep  2 03:27:26 UTC 2019


!!Linux Distribution
!!------------------

^[[1;36mWelcome to ^[[1;33mMX Linux^[[1;36m! Powered by 
^[[1;33mDebian^[[1;36m.^[[0m PRETTY_NAME="Debian GNU/Linux 9 (stretch)" 
NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/" 
SUPPORT_URL="https://www.debian.org/support" 
BUG_REPORT_URL="https://bugs.debian.org/" MX-18.3_x64 Continuum Dec 20, 
2018 MX-18.3_x64 Continuum Dec 20, 2018


!!DMI Information
!!---------------

Manufacturer:      Supermicro
Product Name:      H8DGU
Product Version:   1234567890
Firmware Version:  3.5c
Board Vendor:      Supermicro
Board Name:        H8DGU


!!ACPI Device Status Information
!!---------------

/sys/bus/acpi/devices/PNP0103:00/status 	 15
/sys/bus/acpi/devices/PNP0501:00/status 	 15
/sys/bus/acpi/devices/PNP0501:01/status 	 15
/sys/bus/acpi/devices/PNP0C0C:00/status 	 11
/sys/bus/acpi/devices/PNP0C0F:00/status 	 9
/sys/bus/acpi/devices/PNP0C0F:01/status 	 9
/sys/bus/acpi/devices/PNP0C0F:02/status 	 9
/sys/bus/acpi/devices/PNP0C0F:03/status 	 9
/sys/bus/acpi/devices/PNP0C0F:04/status 	 9
/sys/bus/acpi/devices/PNP0C0F:05/status 	 9
/sys/bus/acpi/devices/PNP0C0F:06/status 	 9
/sys/bus/acpi/devices/PNP0C0F:07/status 	 9
/sys/bus/acpi/devices/device:1e/status 	 15
/sys/bus/acpi/devices/device:1f/status 	 15
/sys/bus/acpi/devices/device:21/status 	 15
/sys/bus/acpi/devices/device:22/status 	 15


!!Kernel Information
!!------------------

Kernel release:    4.19.0-5-amd64
Operating System:  GNU/Linux
Architecture:      x86_64
Processor:         unknown
SMP Enabled:       Yes


!!ALSA Version
!!------------

Driver version:     k4.19.0-5-amd64
Library version:    1.1.9
Utilities version:  1.1.3


!!Loaded ALSA modules
!!-------------------

snd_hda_intel
snd_usb_audio
snd_usb_audio


!!Sound Servers on this system
!!----------------------------

Pulseaudio:
       Installed - Yes (/usr/bin/pulseaudio)
       Running - Yes

Jack:
       Installed - Yes (/usr/bin/jackd)
       Running - No


!!Soundcards recognised by ALSA
!!-----------------------------

  0 [HDMI           ]: HDA-Intel - HDA ATI HDMI
                       HDA ATI HDMI at 0xfebfc000 irq 46
  1 [Interface      ]: USB-Audio - USB Uno MIDI Interface
                       M-Audio USB Uno MIDI Interface at 
usb-0000:00:12.2-1.2.3, full speed
  2 [M1x1           ]: USB-Audio - MidiSport 1x1
                       M-Audio MidiSport 1x1 at usb-0000:00:12.2-1.2.2, 
full speed


!!PCI Soundcards installed in the system
!!--------------------------------------

03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aae0


!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!-------------------------------------------------------

03:00.1 0403: 1002:aae0
	Subsystem: 1462:aae0


!!Modprobe options (Sound related)
!!--------------------------------

snd_pcsp: index=-2
snd_usb_audio: index=-2
snd_atiixp_modem: index=-2
snd_intel8x0m: index=-2
snd_via82xx_modem: index=-2


!!Loaded sound module options
!!---------------------------

!!Module: snd_hda_intel
	align_buffer_size : -1
	bdl_pos_adj : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	beep_mode : 
Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
	enable : 
Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
	enable_msi : -1
	id : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	index : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	jackpoll_ms : 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	model : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	patch : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	pm_blacklist : Y
	position_fix : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	power_save : 0
	power_save_controller : N
	probe_mask : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	probe_only : 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	single_cmd : -1
	snoop : -1

!!Module: snd_usb_audio
	autoclock : Y
	device_setup : 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	enable : 
Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
	id : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	ignore_ctl_error : N
	index : 
-2,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	pid : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	quirk_alias : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	use_vmalloc : Y
	vid : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1

!!Module: snd_usb_audio
	autoclock : Y
	device_setup : 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	enable : 
Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
	id : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	ignore_ctl_error : N
	index : 
-2,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	pid : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	quirk_alias : 
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	use_vmalloc : Y
	vid : 
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1


!!HDA-Intel Codec information
!!---------------------------
--startcollapse--

Codec: ATI R6xx HDMI
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x1002aa01
Subsystem Id: 0x00aa0100
Revision Id: 0x100700
No Modem Function Group found
Default PCM:
     rates [0x70]: 32000 44100 48000
     bits [0x2]: 16
     formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
   Power states:  D0 D3 CLKSTOP EPSS
   Power: setting=D0, actual=D0, Clock-stop-OK
GPIO: io=0, o=0, i=0, unsolicited=0, wake=0
Node 0x02 [Audio Output] wcaps 0x221: Stereo Digital Stripe
   Converter: stream=0, channel=0
   Digital: Enabled
   Digital category: 0x0
   IEC Coding Type: 0x0
Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital
   Control: name="IEC958 Playback Con Mask", index=0, device=0
   Control: name="IEC958 Playback Pro Mask", index=0, device=0
   Control: name="IEC958 Playback Default", index=0, device=0
   Control: name="IEC958 Playback Switch", index=0, device=0
   Pincap 0x00000094: OUT Detect HDMI
   Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
     Conn = Digital, Color = Unknown
     DefAssociation = 0xf, Sequence = 0x0
   Pin-ctls: 0x40: OUT
   Unsolicited: tag=01, enabled=1
   Connection: 1
      0x02
Node 0x04 [Audio Output] wcaps 0x221: Stereo Digital Stripe
   Converter: stream=0, channel=0
   Digital: Enabled
   Digital category: 0x0
   IEC Coding Type: 0x0
Node 0x05 [Pin Complex] wcaps 0x400381: Stereo Digital
   Control: name="IEC958 Playback Con Mask", index=1, device=0
   Control: name="IEC958 Playback Pro Mask", index=1, device=0
   Control: name="IEC958 Playback Default", index=1, device=0
   Control: name="IEC958 Playback Switch", index=1, device=0
   Pincap 0x00000094: OUT Detect HDMI
   Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
     Conn = Digital, Color = Unknown
     DefAssociation = 0xf, Sequence = 0x0
   Pin-ctls: 0x40: OUT
   Unsolicited: tag=02, enabled=1
   Connection: 1
      0x04
Node 0x06 [Audio Output] wcaps 0x221: Stereo Digital Stripe
   Converter: stream=0, channel=0
   Digital: Enabled
   Digital category: 0x0
   IEC Coding Type: 0x0
Node 0x07 [Pin Complex] wcaps 0x400381: Stereo Digital
   Control: name="IEC958 Playback Con Mask", index=2, device=0
   Control: name="IEC958 Playback Pro Mask", index=2, device=0
   Control: name="IEC958 Playback Default", index=2, device=0
   Control: name="IEC958 Playback Switch", index=2, device=0
   Pincap 0x00000094: OUT Detect HDMI
   Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
     Conn = Digital, Color = Unknown
     DefAssociation = 0xf, Sequence = 0x0
   Pin-ctls: 0x40: OUT
   Unsolicited: tag=03, enabled=1
   Connection: 1
      0x06
Node 0x08 [Audio Output] wcaps 0x221: Stereo Digital Stripe
   Converter: stream=0, channel=0
   Digital: Enabled
   Digital category: 0x0
   IEC Coding Type: 0x0
Node 0x09 [Pin Complex] wcaps 0x400381: Stereo Digital
   Control: name="IEC958 Playback Con Mask", index=3, device=0
   Control: name="IEC958 Playback Pro Mask", index=3, device=0
   Control: name="IEC958 Playback Default", index=3, device=0
   Control: name="IEC958 Playback Switch", index=3, device=0
   Pincap 0x00000094: OUT Detect HDMI
   Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
     Conn = Digital, Color = Unknown
     DefAssociation = 0xf, Sequence = 0x0
   Pin-ctls: 0x40: OUT
   Unsolicited: tag=04, enabled=1
   Connection: 1
      0x08
Node 0x0a [Audio Output] wcaps 0x221: Stereo Digital Stripe
   Converter: stream=1, channel=0
   Digital: Enabled
   Digital category: 0x0
   IEC Coding Type: 0x0
Node 0x0b [Pin Complex] wcaps 0x400381: Stereo Digital
   Control: name="IEC958 Playback Con Mask", index=4, device=0
   Control: name="IEC958 Playback Pro Mask", index=4, device=0
   Control: name="IEC958 Playback Default", index=4, device=0
   Control: name="IEC958 Playback Switch", index=4, device=0
   Pincap 0x00000094: OUT Detect HDMI
   Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
     Conn = Digital, Color = Unknown
     DefAssociation = 0xf, Sequence = 0x0
   Pin-ctls: 0x40: OUT
   Unsolicited: tag=05, enabled=1
   Connection: 1
      0x0a
Node 0x0c [Audio Output] wcaps 0x221: Stereo Digital Stripe
   Converter: stream=0, channel=0
   Digital:
   Digital category: 0x0
   IEC Coding Type: 0x0
Node 0x0d [Pin Complex] wcaps 0x400381: Stereo Digital
   Pincap 0x00000094: OUT Detect HDMI
   Pin Default 0x585600f0: [N/A] Digital Out at Int HDMI
     Conn = Digital, Color = Unknown
     DefAssociation = 0xf, Sequence = 0x0
   Pin-ctls: 0x40: OUT
   Unsolicited: tag=00, enabled=0
   Connection: 1
      0x0c
--endcollapse--


!!USB Mixer information
!!---------------------
--startcollapse--

USB Mixer: usb_id=0x07630150, ctrlif=0, ctlerr=0
Card: M-Audio USB Uno MIDI Interface at usb-0000:00:12.2-1.2.3, full 
speed
--endcollapse--


!!ALSA Device nodes
!!-----------------

crw-rw---- 1 root audio 116,  8 Sep  1 04:44 /dev/snd/controlC0
crw-rw---- 1 root audio 116, 10 Sep  1 06:36 /dev/snd/controlC1
crw-rw---- 1 root audio 116, 12 Sep  1 06:36 /dev/snd/controlC2
crw-rw---- 1 root audio 116,  7 Sep  1 04:44 /dev/snd/hwC0D0
crw-rw---- 1 root audio 116,  9 Sep  1 06:36 /dev/snd/midiC1D0
crw-rw---- 1 root audio 116, 11 Sep  1 06:36 /dev/snd/midiC2D0
crw-rw---- 1 root audio 116,  6 Sep  1 23:17 /dev/snd/pcmC0D10p
crw-rw---- 1 root audio 116,  2 Sep  1 23:17 /dev/snd/pcmC0D3p
crw-rw---- 1 root audio 116,  3 Sep  1 23:17 /dev/snd/pcmC0D7p
crw-rw---- 1 root audio 116,  4 Sep  1 23:17 /dev/snd/pcmC0D8p
crw-rw---- 1 root audio 116,  5 Sep  1 23:17 /dev/snd/pcmC0D9p
crw-rw---- 1 root audio 116,  1 Sep  1 05:13 /dev/snd/seq
crw-rw---- 1 root audio 116, 33 Sep  1 04:44 /dev/snd/timer

/dev/snd/by-id:
total 0
drwxr-xr-x 2 root root  80 Sep  1 22:40 .
drwxr-xr-x 4 root root 340 Sep  1 22:40 ..
lrwxrwxrwx 1 root root  12 Sep  1 06:36 usb-0763_1011-00 -> ../controlC2
lrwxrwxrwx 1 root root  12 Sep  1 06:36 
usb-M-Audio_USB_Uno_MIDI_Interface-00 -> ../controlC1

/dev/snd/by-path:
total 0
drwxr-xr-x 2 root root 100 Sep  1 22:40 .
drwxr-xr-x 4 root root 340 Sep  1 22:40 ..
lrwxrwxrwx 1 root root  12 Sep  1 06:36 pci-0000:00:12.2-usb-0:1.2.2:1.0 
-> ../controlC2
lrwxrwxrwx 1 root root  12 Sep  1 06:36 pci-0000:00:12.2-usb-0:1.2.3:1.0 
-> ../controlC1
lrwxrwxrwx 1 root root  12 Sep  1 04:44 pci-0000:03:00.1 -> ../controlC0


!!ALSA configuration files
!!------------------------

!!System wide config file (/etc/asound.conf)

# v4.0
# Requires alsa-utils libasound2-plugin-equal



# ***** Defaults *******************************************************

# Audio card/chip and device to use and control
# In most cases these settings should remain commented (#)
# When commented, card and device 0 are usually automatically selected
# When uncommented, the item corresponding to the number is selected
#defaults.pcm.card 0
#defaults.pcm.device 0
#defaults.ctl.card 0



# ***** Reset **********************************************************

# override the existing definition of the default device
pcm.!default
{
    type plug

    # point output to the equalizer device
    slave.pcm plugequal
}



# ***** Equalizer ******************************************************

# set up the control interface of the equalizer device
ctl.equalizer
{
    type equal
}


# set up the equalizer device
pcm.plugequal
{
    type equal

    # point output to device named preamp
    slave.pcm  "plug:preamp"
}



# ***** Pre-Amp ********************************************************

# set up the preamp device
pcm.preamp
{
    type softvol

    # name of slider control to display in alsamixer interface
    control.name Pre-Amp

    # minimum dB when slider is at 0%
    min_dB -5.0

    # maximum dB when slider is at 100%
    max_dB 40.0

    # point output to device named duplex
    slave.pcm "duplex"
}



# ***** Playback and Capture *******************************************

# set up the playback/capture device
pcm.duplex
{
    type asym

    # point playback output to use dmix
    playback.pcm "dmix"

    # point capture input record to use dsnoop
    capture.pcm "dsnoop"
}


!!Aplay/Arecord output
!!--------------------

APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 8: HDMI 2 [HDMI 2]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 9: HDMI 3 [HDMI 3]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 10: HDMI 4 [HDMI 4]
   Subdevices: 1/1
   Subdevice #0: subdevice #0

ARECORD

**** List of CAPTURE Hardware Devices ****

!!Amixer output
!!-------------

!!-------Mixer controls for card 0 [HDMI]

Card hw:0 'HDMI'/'HDA ATI HDMI at 0xfebfc000 irq 46'
   Mixer name	: 'ATI R6xx HDMI'
   Components	: 'HDA:1002aa01,00aa0100,00100700'
   Controls      : 35
   Simple ctrls  : 5
Simple mixer control 'IEC958',0
   Capabilities: pswitch pswitch-joined
   Playback channels: Mono
   Mono: Playback [on]
Simple mixer control 'IEC958',1
   Capabilities: pswitch pswitch-joined
   Playback channels: Mono
   Mono: Playback [on]
Simple mixer control 'IEC958',2
   Capabilities: pswitch pswitch-joined
   Playback channels: Mono
   Mono: Playback [on]
Simple mixer control 'IEC958',3
   Capabilities: pswitch pswitch-joined
   Playback channels: Mono
   Mono: Playback [on]
Simple mixer control 'IEC958',4
   Capabilities: pswitch pswitch-joined
   Playback channels: Mono
   Mono: Playback [on]

!!-------Mixer controls for card 1 [Interface]

Card hw:1 'Interface'/'M-Audio USB Uno MIDI Interface at 
usb-0000:00:12.2-1.2.3, full speed'
   Mixer name	: 'USB Mixer'
   Components	: 'USB0763:0150'
   Controls      : 1
   Simple ctrls  : 0

!!-------Mixer controls for card 2 [M1x1]

Card hw:2 'M1x1'/'M-Audio MidiSport 1x1 at usb-0000:00:12.2-1.2.2, full 
speed'
   Mixer name	: ''
   Components	: 'USB0763:1011'
   Controls      : 0
   Simple ctrls  : 0


!!Alsactl output
!!--------------

--startcollapse--
state.HDMI {
	control.1 {
		iface CARD
		name 'HDMI/DP,pcm=3 Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.2 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		value 
'0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.3 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		value 
'0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.4 {
		iface MIXER
		name 'IEC958 Playback Default'
		value 
'0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write'
			type IEC958
			count 1
		}
	}
	control.5 {
		iface MIXER
		name 'IEC958 Playback Switch'
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.6 {
		iface PCM
		device 3
		name ELD
		value ''
		comment {
			access 'read volatile'
			type BYTES
			count 0
		}
	}
	control.7 {
		iface CARD
		name 'HDMI/DP,pcm=7 Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.8 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		index 1
		value 
'0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.9 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		index 1
		value 
'0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.10 {
		iface MIXER
		name 'IEC958 Playback Default'
		index 1
		value 
'0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write'
			type IEC958
			count 1
		}
	}
	control.11 {
		iface MIXER
		name 'IEC958 Playback Switch'
		index 1
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.12 {
		iface PCM
		device 7
		name ELD
		value ''
		comment {
			access 'read volatile'
			type BYTES
			count 0
		}
	}
	control.13 {
		iface CARD
		name 'HDMI/DP,pcm=8 Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.14 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		index 2
		value 
'0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.15 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		index 2
		value 
'0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.16 {
		iface MIXER
		name 'IEC958 Playback Default'
		index 2
		value 
'0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write'
			type IEC958
			count 1
		}
	}
	control.17 {
		iface MIXER
		name 'IEC958 Playback Switch'
		index 2
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.18 {
		iface PCM
		device 8
		name ELD
		value ''
		comment {
			access 'read volatile'
			type BYTES
			count 0
		}
	}
	control.19 {
		iface CARD
		name 'HDMI/DP,pcm=9 Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.20 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		index 3
		value 
'0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.21 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		index 3
		value 
'0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.22 {
		iface MIXER
		name 'IEC958 Playback Default'
		index 3
		value 
'0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write'
			type IEC958
			count 1
		}
	}
	control.23 {
		iface MIXER
		name 'IEC958 Playback Switch'
		index 3
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.24 {
		iface PCM
		device 9
		name ELD
		value ''
		comment {
			access 'read volatile'
			type BYTES
			count 0
		}
	}
	control.25 {
		iface CARD
		name 'HDMI/DP,pcm=10 Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.26 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		index 4
		value 
'0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.27 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		index 4
		value 
'0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.28 {
		iface MIXER
		name 'IEC958 Playback Default'
		index 4
		value 
'0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write'
			type IEC958
			count 1
		}
	}
	control.29 {
		iface MIXER
		name 'IEC958 Playback Switch'
		index 4
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.30 {
		iface PCM
		device 10
		name ELD
		value ''
		comment {
			access 'read volatile'
			type BYTES
			count 0
		}
	}
	control.31 {
		iface PCM
		device 3
		name 'Playback Channel Map'
		value.0 0
		value.1 0
		value.2 0
		value.3 0
		value.4 0
		value.5 0
		value.6 0
		value.7 0
		comment {
			access 'read write'
			type INTEGER
			count 8
			range '0 - 36'
		}
	}
	control.32 {
		iface PCM
		device 7
		name 'Playback Channel Map'
		value.0 0
		value.1 0
		value.2 0
		value.3 0
		value.4 0
		value.5 0
		value.6 0
		value.7 0
		comment {
			access 'read write'
			type INTEGER
			count 8
			range '0 - 36'
		}
	}
	control.33 {
		iface PCM
		device 8
		name 'Playback Channel Map'
		value.0 0
		value.1 0
		value.2 0
		value.3 0
		value.4 0
		value.5 0
		value.6 0
		value.7 0
		comment {
			access 'read write'
			type INTEGER
			count 8
			range '0 - 36'
		}
	}
	control.34 {
		iface PCM
		device 9
		name 'Playback Channel Map'
		value.0 0
		value.1 0
		value.2 0
		value.3 0
		value.4 0
		value.5 0
		value.6 0
		value.7 0
		comment {
			access 'read write'
			type INTEGER
			count 8
			range '0 - 36'
		}
	}
	control.35 {
		iface PCM
		device 10
		name 'Playback Channel Map'
		value.0 0
		value.1 0
		value.2 0
		value.3 0
		value.4 0
		value.5 0
		value.6 0
		value.7 0
		comment {
			access 'read write'
			type INTEGER
			count 8
			range '0 - 36'
		}
	}
}
state.Interface {
	control.1 {
		iface CARD
		name 'Keep Interface'
		value false
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
}
state.M1x1 {
	control {
	}
}
--endcollapse--


!!All Loaded Modules
!!------------------

Module
snd_seq_dummy
snd_seq_midi
snd_seq_midi_event
snd_seq
bnep
rpcsec_gss_krb5
nfsv4
dns_resolver
nfs
fscache
cpufreq_userspace
cpufreq_conservative
cpufreq_powersave
bluetooth
pci_stub
vboxpci
drbg
ansi_cprng
vboxnetadp
ecdh_generic
rfkill
vboxnetflt
vboxdrv
ftdi_sio
usbserial
binfmt_misc
snd_usb_audio
snd_usbmidi_lib
snd_rawmidi
snd_seq_device
joydev
snd_hda_codec_hdmi
snd_hda_intel
snd_hda_codec
amd64_edac_mod
edac_mce_amd
amdgpu
snd_hda_core
snd_hwdep
snd_pcm_oss
kvm_amd
ccp
mgag200
rng_core
snd_mixer_oss
kvm
irqbypass
chash
snd_pcm
gpu_sched
ipmi_si
crct10dif_pclmul
evdev
crc32_pclmul
serio_raw
ghash_clmulni_intel
ipmi_devintf
snd_timer
ttm
ipmi_msghandler
drm_kms_helper
k10temp
sg
snd
fam15h_power
sp5100_tco
drm
soundcore
button
nfsd
auth_rpcgss
nfs_acl
lockd
grace
sunrpc
loop
vhba
ecryptfs
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
sr_mod
cdrom
ext4
crc16
mbcache
jbd2
fscrypto
ecb
uas
usb_storage
hid_generic
usbhid
hid
btrfs
xor
zstd_decompress
zstd_compress
xxhash
sd_mod
raid6_pq
libcrc32c
crc32c_generic
vmd
crc32c_intel
ohci_pci
ata_generic
aesni_intel
aes_x86_64
ahci
crypto_simd
ehci_pci
ohci_hcd
pata_atiixp
libahci
cryptd
glue_helper
ehci_hcd
psmouse
libata
igb
usbcore
i2c_piix4
i2c_algo_bit
scsi_mod
usb_common
dca


!!Sysfs Files
!!-----------

/sys/class/sound/hwC0D0/init_pin_configs:
0x03 0x185600f0
0x05 0x185600f0
0x07 0x185600f0
0x09 0x185600f0
0x0b 0x185600f0
0x0d 0x585600f0

/sys/class/sound/hwC0D0/driver_pin_configs:

/sys/class/sound/hwC0D0/user_pin_configs:

/sys/class/sound/hwC0D0/init_verbs:

/sys/class/sound/hwC0D0/hints:


!!ALSA/HDA dmesg
!!--------------