Closed
Bug 934112
Opened 11 years ago
Closed 8 years ago
libcubeb ALSA no sound due to spin and constant recovers
Categories
(Core :: Audio/Video: cubeb, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mail, Unassigned)
References
Details
Attachments
(2 files)
1.18 KB,
patch
|
Details | Diff | Splinter Review | |
116.57 KB,
text/plain
|
Details |
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.
Comment 1•11 years ago
|
||
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?
Updated•11 years ago
|
Flags: needinfo?(mail)
Reporter | ||
Comment 3•11 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."
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Updated•9 years ago
|
Component: Audio/Video: MediaStreamGraph → Audio/Video: cubeb
Updated•9 years ago
|
Status: UNCONFIRMED → NEW
Rank: 28
Ever confirmed: true
Priority: -- → P2
Comment 4•8 years ago
|
||
Can you please retest this in a current Nightly build?
Flags: needinfo?(mail)
Reporter | ||
Comment 5•8 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)
Comment 6•8 years ago
|
||
Great, thanks for testing again. I'll mark this as fixed by bug 1279125.
You need to log in
before you can comment on or make changes to this bug.
Description
•