Arch Linux

Works for me. Tested the ALSA pulse plugin using wine (32-bit), zsnes (32-bit), timidity++ (64-bit), speaker-test (64-bit) and various Steam games (32-bit and 64-bit, with and without the Steam Runtime).

Please find a way to reproduce this without involving packages from the AUR.

PlayOnLinux is available in community repository. It allows you to use specific wine versions, everything handled from PlayOnLinux.

The issues with PlayOnLinux are noted by several people in the forum. As for Timidity, I run it with:

timidity -iA -Os

so it handles midi sound for DosBox games.

Forum topic:

https://bbs.archlinux.org/viewtopic.php?id=177979

Did you reboot or at least restart PulseAudio after the upgrade?

Yes, I rebooted. I am honestly a bit baffled myself at this because the only output that indicated the problem is when running PlayOnLinux.

Edit: Timidity work properly if I set my laptop's internal speakers as default, instead of the headset I normally have set as default. I can then change the output for Timidity to the headset after it has started, and it works. I attempted the same with PlayOnLinux, but it did not help.

I'm having the same issues and I'm using an USB Headset too!

I tried switching the output to the onboard soundcard and the problem went away!.. I think it's something related to resampling as my USB Headset seems to only support 48000Hz output while the onboard soundcard supports multiple rates.

Also tried uncommenting: default-sample-rate = 48000 in /etc/pulse/daemon.conf, but the issue remains... :\

Today I tried downgrading just lib32-libpulse to 4.0-6, and PlayOnLinux no longer crashes. Sound is extremely garbled if my USB headset is specified as default in pavucontrol. In the terminal I see:

ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

If I set speakers to default output, then sound works properly and I can even switch the output over to headset after starting applications from PlayOnLinux.

I was having the same problem with PlayOnLinux programs not working after upgrading to pulse 5.0 downgrading pulseaudio, libpulse, and lib32-libpulse fixed the problem for me.

I was having the same problem with PlayOnLinux programs not working after upgrading to pulse 5.0 downgrading pulseaudio, libpulse, and lib32-libpulse fixed the problem for me.

I can confirm the problem too and downgrading does fix it.

I've had problems with choppy sound in linphone that goes away when downgrading.

Following a recently posted tip in the forum topic I linked to in an earlier comment, I now have sound working perfectly with Timidity when using my USB headset.

Editing /etc/pulse/daemon.conf adding the line:

default-fragment-size-msec = 5

Solves the problems I had with Timidity and Munt. However, PlayOnLinux still don't work unless either downgrade or use .asoundrc to prevent Pulseaudio from handling all sound output so that Alsa applications can output to my audio devices without going through Pulse.

I use a USB wireless headset and had no problems with Pulseaudio 5.0 until I installed bluez* 5.16-1. After that I got the same

ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

error when running Star Craft II in Wine (which worked flawlessly before) together with the garbled sound mentioned by Daerandin. Downgrading bluez* to 5.15-1 seems to fix the issue with Wine (I did not have any problems with other programs). Since the problem seems to be the bluez* tools in my case, I am not sure whether this is the same issue or not.

Just tell me if you want me to open another issue or if I should provide more debugging output.

*EDIT*: After the issue popped up again once I rebooted, I did some testing and it seems that the underrun error occurs when using pulseaudio 5.0-1 regardless of which bluez* packages you have installed. As far as I can tell the issue seems to be indeed with pulseaudio 5.0-1. pulseaudio 4.0-6 works fine with wine and Star Craft II.

I experience this issue as well. Some facts that I found out so far:

1. Mocp plays really fast, 1 minute only takes about 5 seconds (unchanged pitch, as if only chunks of the sound played). During this, when running pulseaudio in terminal, I get this:

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.

When running with debug verbosity, it loops in a series of underruns and resets. I'm attaching the log for your eyes, it is rather long.

2. Youtube client in HTML5 mode plays in short bursts, followed by short bursts of silence, periodically (about 3-6 times per second).

3. Many programs play sound okay - Flash player for Youtube is okay, google play music plays well, games play well as far as I tested.

4. mocp, and other programs start to behave as they should after this env var is set: PULSE_LATENCY_MSEC=30
- unfortunately this breaks other things, and doing this on per-application basis is rather tedious

dmesg contains these (in great ammount):
[ 1331.444905] retire_capture_urb: 1873 callbacks suppressed


I also saw some overrun messages from kernel, something in lines of "that usb device cant process the buffer of the given size", but can't find that now.

Edit:
Some other things I found so far:

* on a different PC, the bug acts differently, for example no problem with youtube. I think this is due to a different USB controller
* downgrading to pulseaudio 4.0 resolves this
* my soundcard is ODAC+O2 combo, if that matters (that means Tenor TE7022 USB interface chip and ES9023 DAC)

I experience the same issue. I can play games which I installed dome weeks ago with PlayOnLinux. New installed apps like Steam, which I installed today shows:

ERROR:network_change_notifier_win.cc(126)] WSALookupServiceBegin failed with: 8
ALSA lib dlmisc.c:252:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so

$ ldd /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so shows http://sprunge.us/jCgV

EDIT:
I emptied the /usr/lib32/alsa-lib/ folder completely, because of another issue. Not sure if this helped for this one. Yet someone else might test it.

I have been suffering the same problems with Pulseaudio 5.0: garbled sound with some native applications (like AGS games) and with Wine games. So I decided to take a look, and after some regression testing, I found the culprit:

commit 826c8f69d34ef49e86fe0ab6c93c1ffba8916131
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Sat Nov 30 18:07:24 2013 +0100

alsa: Disable timer-scheduling for PCMs with the BATCH flag

PCM Devices which have the BATCH flag set update the PCM pointer only with
period size granularity. Using timer based scheduling does not have any
advantage in this mode. For one devices which have that flag set usually update
the position pointer in software after getting the period interrupt. So
disabling the period interrupt is not possible for this kind of devices.
Furthermore writing to or reading from the buffer slice for the current period
is not possible since the position inside the buffer is not known. On the other
hand the tsched algorithm seems to get easily confused for this kind of
hardware, which results in garbled audio output. This typically means that timer
based scheduling needs to be manually disabled on systems with such devices.
Auto disabling tsched in this case allows these systems to run with the default
configuration.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>

diff --git a/src/modules/alsa/alsa-util.c b/src/modules/alsa/alsa-util.c
index 75f5858..4b24e47 100644
--- a/src/modules/alsa/alsa-util.c
+++ b/src/modules/alsa/alsa-util.c
@@ -245,6 +245,10 @@ int pa_alsa_set_hw_params(
if (!pa_alsa_pcm_is_hw(pcm_handle))
_use_tsched = false;

+ /* The PCM pointer is only updated with period granularity */
+ if (snd_pcm_hw_params_is_batch(hwparams))
+ _use_tsched = false;
+
#if (SND_LIB_VERSION >= ((1<<16)|(0<<8)|24)) /* API additions in 1.0.24 */
if (_use_tsched) {


Which apparently was made to prevent garbled audio output with some hardware configurations, oh the irony...

Anyway, reverting it fix the problem in my case.

N.B.: I'm using an USB DAC (Epiphany Acoustics EHP-O2).

bpierre, did you report this upstream?

I have not.

Having a bit of trouble digging through their bugtracker to see if this has been reported yet.

is there an easier way to reproduce the bug?