libcubeb ALSA no sound due to spin and constant recovers

RESOLVED FIXED

Status

()

Core
Audio/Video: cubeb
P2
normal
Rank:
28
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: Maciej S. Szmigiero, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 826302 [details] [diff] [review]
libcubeb-alsa-zero-return.patch

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.34 Safari/537.36

Steps to reproduce:

On my system (with alsa-lib-1.0.27.2) I get no sound from HTML5 audio/video files.

libcubeb ALSA module module spins when poll() returns revents != POLLOUT.
poll() can and does return multiple events as a bit mask (in my case it returns POLLOUT | POLLERR).

When the check is changed to !(revents & POLLOUT) it no longer spins, but still there is no proper sound - there are only short bursts of sound when seeking, then silence.

This is caused by constant recovers when snd_pcm_avail_update() returns 0.
When I change this to simply return instead of calling recovery the sound works perfectly.

Relevant patch is attached.

Also, I see that there is an assert() that snd_pcm_writei() will write the whole requested data and that it won't fail (there is only one recovery retry on EPIPE).
According to ALSA docs this call can fail, especially considering that there is no guarantee that after stream recovery it will immediately be writable with the same available buffer space.

I see that in bug #780531 somebody has actually hit this issue in libcubeb.

I didn't change this because it does not cause any problems on my system.
Thanks for digging into the problem, and the patch.  I think those changes are going to result in snd_pcm_writei blocking, which what the current logic is trying to avoid.  Can you please attach the output from http://www.alsa-project.org/alsa-info.sh to the bug?
Flags: needinfo?(mail)
(Reporter)

Comment 2

4 years ago
Created attachment 827651 [details]
alsa-info.txt.zK3u9qmJxf

alsa-info output
Flags: needinfo?(mail)
(Reporter)

Comment 3

4 years ago
Thanks for looking at this.

> I think those changes are going to result in snd_pcm_writei blocking,
> which what the current logic is trying to avoid.

I see that the snd_pcm_open() is called with SND_PCM_NONBLOCK flag,
and again later the non-blocking mode is set explicitly again via a snd_pcm_nonblock() call.

According to ALSA docs for snd_pcm_writei():
"If the non-blocking behaviour is selected, then routine doesn't wait at all."
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Component: Audio/Video: MediaStreamGraph → Audio/Video: cubeb

Updated

2 years ago
Status: UNCONFIRMED → NEW
Rank: 28
Ever confirmed: true
Priority: -- → P2
Can you please retest this in a current Nightly build?
Flags: needinfo?(mail)
(Reporter)

Comment 5

2 years ago
I don't have this exact setup anymore, but I was able to make a similar setup with SB Audigy2 (2.5 years ago it was SB Live; they use the same kernel driver) and old asound.conf.

The result was that on FF 24.0 I was able to reproduce "no proper sound, just short bursts of sound when seeking" problem but wasn't able to reproduce poll() spinning issue.

Then I have tested 2016-08-26-03-02-26-mozilla-central/firefox-51.0a1.en-US.linux-x86_64.tar.bz2 and
everything was fine there (with regard to sound output, naturally).

While I wasn't able to reproduce the poll() spinning issue from quick glance at current cubeb_alsa.c code at mozilla-central it seems to me it shouldn't be a problem anymore.
Flags: needinfo?(mail)
Great, thanks for testing again.  I'll mark this as fixed by bug 1279125.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Depends on: 1279125
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.