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.