Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#39186 - [pulseaudio] certain applications using alsa don't work with pulseaudio 5.0 / alsa

Attached to Project: Arch Linux
Opened by Daniel Jenssen (Daerandin) - Wednesday, 05 March 2014, 16:26 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 22:34 GMT
Task Type Bug Report
Category Upstream Bugs
Status Waiting on Response
Assigned To Jan Steffens (heftig)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 7
Private No

Details

Description:

After the update to Pulseaudio 5.0, PlayOnLinux can no longer launch installed applications. In terminal is the output:

ALSA lib dlmisc.c:252:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so

Other applications that are also affected, but don't give any indication of problems in terminal output, are Timidity++ and Munt from AUR.

Timidity just give some very choppy sounds, and mt32emu-qt (from the Munt package) simply fail to start the sound mixing when Alsa is set at the output device.


Additional info:

Downgrading pulseaudio, along with libpulse and lib32-libpulse, to version 4.0-6 make everything work as intended.

If PlayOnLinux is set to using the System wine version, then it works. But other specific wine versions in PlayOnLinux crash on start.


Steps to reproduce:

Start PlayOnLinux, and start an application that does not use System wine setting.
This task depends upon

Comment by Jan Steffens (heftig) - Wednesday, 05 March 2014, 17:19 GMT
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.
Comment by Daniel Jenssen (Daerandin) - Wednesday, 05 March 2014, 17:36 GMT
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
Comment by Jan Steffens (heftig) - Wednesday, 05 March 2014, 17:48 GMT
Did you reboot or at least restart PulseAudio after the upgrade?
Comment by Daniel Jenssen (Daerandin) - Wednesday, 05 March 2014, 17:54 GMT
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.
Comment by Carlos Palma (LithiumPT) - Wednesday, 05 March 2014, 20:13 GMT
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... :\
Comment by Daniel Jenssen (Daerandin) - Thursday, 06 March 2014, 21:26 GMT
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.
Comment by Soul (soulhuntor) - Sunday, 09 March 2014, 04:30 GMT
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.
Comment by Soul (soulhuntor) - Sunday, 09 March 2014, 08:20 GMT
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.
Comment by Hugh Smalley (hsmalley) - Monday, 10 March 2014, 14:01 GMT
I can confirm the problem too and downgrading does fix it.
Comment by Carlo Teubner (carlo) - Thursday, 13 March 2014, 18:53 GMT
I've had problems with choppy sound in linphone that goes away when downgrading.
Comment by Daniel Jenssen (Daerandin) - Monday, 17 March 2014, 17:13 GMT
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.
Comment by Silvan Jegen (Shugyousha) - Monday, 17 March 2014, 22:10 GMT
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.
Comment by Filip Volejnik (volca) - Tuesday, 15 April 2014, 20:59 GMT
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)
Comment by Tom (tAsk) - Sunday, 18 May 2014, 19:13 GMT
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.
Comment by Benoit Pierre (bpierre) - Sunday, 06 July 2014, 16:31 GMT
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).
Comment by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 22:33 GMT
bpierre, did you report this upstream?
Comment by Benoit Pierre (bpierre) - Friday, 15 May 2015, 06:01 GMT
I have not.

Loading...