Comment 103 for bug 371897

Seems that there are two bugs people are reporting here: the stuttering and the total loss of sound from wine. I don't get the stuttering but I do get the complete stops. I have been investigating for a while now and this one has got me beat. I do have this random collection of things I discovered though:

Right after a reboot sound from wine works OK for several hours at least.

When the sound stops in a wine app, restarting the app will make sound work again, but only for a very short time, which decreases each time the app is restarted until eventually sound will only work for a few seconds before a restart is needed.

Restarting pulseaudio makes the sound work again for a few days/hours.

The problem happens with both ALSA emulation and esound emulation by pulseaudio. I have not tried with winepulse.

I've never seen it happen with direct ALSA access (disabling pulseaudio) - but I have not really tested for long enough to be sure it NEVER happens.

If multiple programs are running in Wine, they don't all necessarily stop making sound at the same time.

The bug doesn't just affect Windows programs running in Wine: it also affects Windows programs running inside Virtualbox. It is not necessary to restart Virtualbox to fix the sound output, restarting just the affected program is enough. This part is really weird, and might be unrelated. Virtualbox uses ALSA emulation through pulse.

Pulseaudio does not output any error messages when the bug happens, and neither does wine, even with maximum tracing.

I added a lot of debugging code to winealsa.drv.so and it was not particularly helpful. It appears that the sound sink just ... stops... like it has been paused somehow, but it is still marked as "playing". The buffer gets filled up and never empties, so wine just waits forever for more space to appear in it. No underrun/overrun condition is apparently triggered, although they do sometimes happen at other times and are handled correctly.

Once the problem happens for the first time I can reproduce it at will by opening the wine sound prefs and spamming the "test sound" button. Sound freezes and the the whole dialog locks up after about 10-20 clicks. After restarting pulse or rebooting the computer, this method of reproducing the bug does not work any more until the next time the bug happens "randomly."

I have a simple test program that can also reproduce the bug, based on the code from the control panel. It calls the Win32 function PlaySound() on a loop. It will hang after about 10-20 loops. Again, this method of reproduction only works after the problem has already happened "randomly" and stops working after restarting pulse.

I have a quad core CPU, and I tried disabling 3 of the cores. When I did this, my test program would hang on the first loop, every time (until I restarted pulse).

The problem seems to happen only if I have my USB external hard drive connected to my computer. My soundcard is an on board hda_intel and shares two IRQs with the USB controllers. I normally have the drive plugged in all the time. I had it unplugged for 5 days and had no sound problems. When I plugged it in, sound problems started again within 2 hours. My working theory is that sometimes an interrupt can get "lost" because of IRQ sharing, which masks an underrun event, which subsequently does not get passed up the chain to Wine, so Wine just waits for ever for the buffer to empty.