Re: Strange bug in alsa-lib

[David Henningsson <david.henningsson@canonical.com>]

Hi!

This is probably a driver/hardware problem. From the information you 
provided, the computer lost contact with the HDA analog codec (this is bad).

I had a similar problem a year ago, and after some trial-and-error, 
after disabling MSI I could no longer reproduce the problem.

You can edit /etc/modprobe.d/alsa-base.conf and add

options snd-hda-intel enable_msi=0

and then reboot. Does this help?

On 2015-01-18 22:21, plcmn wrote:
> Greetings everyone!
>
> I'm sorry in advance for my poor English.
> Unfortunately your bugtracker is down so I've had to send this bug
> report (or description, huh) here.
> Alsa information about my system is in the attachments.
>
> I've came across this bug a few days ago, it appeared since I've
> installed alsa. Everytime when I try to quickly change the volume on
> Master channel the sound brakes: alsamixer hangs up and some music
> players (for example, Music on Console) play music by fits and starts
> (it's similar to watching hd video on a slow connection). Some music
> players, for example DeadBeeF, or browsers, such as Chromium work quite
> normal. I've searched forums, but I didn't come across anyone with a
> similar problem. So, I've decided to do a little research to find out
> what caused the problems. I've started with a simple script:
>
> plcmn@equestria:~$ cat test.sh
> export i=0
> while [ $i -lt 80 ]
> do
>    amixer set Master $i%
>    let i=$(($i+1))
> done
>
> Here are the results of the execution before the bug appears:
>
> plcmn@equestria:~$ time ./test.sh
> real    0m0.743s
> user    0m0.350s
> sys    0m0.203s
>
> And this how it looks like when the bug comes out (I've just launched
> this script two times in a row):
>
> plcmn@equestria~$ time test.sh
>
> real    4m41.763s
> user    0m0.607s
> sys    0m12.037s
>
> That looked really weird, so I've tried to figure out what caused the
> problem. Checking the source with cppcheck didn't gave any results,
> except some memory leaks (like [src/rawmidi/rawmidi_hw.c:304]: (error)
> Memory leak: hw), but none of them referred to my problem. So I've
> digged into the code and found out the line that caused the error:
>
>   ---
>
>  From src/control/control_hw.c:
> 193 if (ioctl(hw->fd, SNDRV_CTL_IOCTL_ELEM_WRITE, control) < 0) {
>
> ---
>
> I'm a dummy in system programming, so I can't exactly tell what's the
> problem with this line (I know ioctl's purpose, but I don't what to do
> next -- a mess of macros and structures were hard for understanding, so
> I stopped at this point). The delay measured by clock() from time.h was
> about 0.18 ms here.
>
> Here is gdb's output for arguments passed to the problematic function:
>
> Breakpoint 2, snd_ctl_hw_elem_write (handle=<optimized out>,
> control=0x7fffffffd9e0) at control_hw.c:193
> (gdb) n
> 194        snd_ctl_hw_t *hw = handle->private_data;
> (gdb) p handle
> $2 = <optimized out>
> (gdb) p control
> $3 = (snd_ctl_elem_value_t *) 0x7fffffffd9e0
> (gdb) p control->id
> $4 = {numid = 16, iface = 2, device = 0, subdevice = 0,
>        name = "Master Playback Volume", '\000' <repeats 21 times>, index
> = 0}
> (gdb) p control->indirect
> $5 = 0
> (gdb) p control->reserved
> $6 = '\000' <repeats 111 times>
> (gdb) p control->tstamp
> $7 = {tv_sec = 0, tv_nsec = 0}
> (gdb) p control->value
> $8 = {integer = {value = {70, 0 <repeats 127 times>}, value_ptr = 0x46},
> integer64 = {value = {70, 0 <repeats 63 times>}, value_ptr = 0x46},
> enumerated = {item = {70, 0 <repeats 127 times>},
>        item_ptr = 0x46}, bytes = {data = "F", '\000' <repeats 510 times>,
>        data_ptr = 0x46 <error: Cannot access memory at address 0x46>},
> iec958 = {status = "F", '\000' <repeats 22 times>,
>        subcode = '\000' <repeats 146 times>, pad = 0 '\000',
> dig_subframe = "\000\000\000"}}
>
> For some reason this function is called twice, the second call doesn't
> cause such a delay.
>
> I can provide any information you'll need.
>
> I hope that my report will be useful.
> Sorry again for my poor English and sending a bug report to dev mail lists.
>
>
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

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