Bug 96361

Summary: [NEED]Try recover from snd_pcm_avail() -EPIPE
Product: PulseAudio Reporter: IvanXie <cunshangzhishu>
Component: alsaAssignee: pulseaudio-bugs
Status: RESOLVED MOVED QA Contact: pulseaudio-bugs
Severity: normal    
Priority: medium CC: lennart
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description IvanXie 2016-06-04 02:49:30 UTC
ALSA sink has been unloaded due to process_rewind() return -1.

"alsa-sink.c: process_rewind(1754) > [alsa-sink-Multimedia1 (*)] snd_pcm_avail() failed: Broken pipe"
"sink.c: sink_free(843) > [pulseaudio] Freeing sink 2 "alsa_output.0.analog-stereo""
"module.c pa_module_free(183) > [pulseaudio] unloaded "module-alsa-sink" (index: #15)"

Actually, sometimes we may meet snd_pcm_avail() -EPIPE from process_rewind, pa_alsa_safe_avail. But how about do recover for this error case instead of return error and unload sink?

I've tried make a patch for this issue. But I'm not sure about this is a proper solution. Please give me your opinion. Thank you.

if (PA_UNLIKELY((unused = pa_alsa_safe_avail(u->pcm_handle, u->hwbuf_size, &u->sink->sample_spec)) < 0)) {
    pa_log("snd_pcm_avail() failed: %s", pa_alsa_strerror((int) unused));
#ifdef RECOVER_FROM_EPIPE
    /* try recover if we got -EPIPE from snd_pcm_avail */
    if (unsed == -EPIPE) {
        pa_log("snd_pcm_avail() failed of -EPIPE. Try recover!!!");
        if (try_recover(u, "process_rewind", unused) < 0)
            return -1;
        else {
            pa_log_info("Tried rewind, but was apparently not possible.");
            pa_sink_process_rewind(u->sink, 0);
            return 0;
        }
    }
#endif
    return -1;
}
Comment 1 Raymond 2016-06-04 04:57:24 UTC
there are drivers which use compressed format which does not support rewind 


for those driver which have large FIFO, you may need to adjust pulseaudio rewind safeguard
Comment 2 Raymond 2016-06-04 05:15:37 UTC
http://www.google.com/patents/US20100131783

Whenever the amount of stream data in the FIFO is less than 128 bytes (i.e., the threshold), the HDAC 15 will issue a bus mater cycle. As each frame is transported in an interval time of 20.83 micro second (μs) (=1/(48×103)), which is regarded as a “time unit of transportation,” the 128 bytes therefore can keep 32 frames (=128/4) of data for about 666 micro second (=32×20.83) without under run.


https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=4df443bbe682055a41e7c2248877dcc7682a69b8

#define DEFAULT_REWIND_SAFEGUARD_BYTES (256) /* 1.33ms @48kHz, should work for most hardware */
+
Comment 3 Raymond 2016-06-04 08:16:50 UTC
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_hw.c;hb=HEAD

seem most EPIPE related to xrun
Comment 4 IvanXie 2016-06-05 06:46:53 UTC
Yes. Right. 
Most EPIPE related to xrun.
That's why I want to add try_recover for this case.
So, what is the conclusion of this issue?
Is that proper to add try_recover?
Comment 5 Raymond 2016-06-05 09:12:53 UTC
which alsa driver are you using ?


you need to call pa_alsa_dump((PA_LOG_INFO, u->pcm_handle); when EPIPE to find out whether appl_ptr is behind  hw_ptr 


do aplay also xrun when use hw device ,  pulseaudio period size and buffer size ?
Comment 6 Raymond 2016-06-06 01:42:07 UTC
(In reply to IvanXie from comment #4)
> Yes. Right. 
> Most EPIPE related to xrun.
> That's why I want to add try_recover for this case.
> So, what is the conclusion of this issue?
> Is that proper to add try_recover?

in theory , as pulseaudio set stop_threshold to boundary, pcm state won't change to xrun even when appl_ptr is behind hw_ptr
Comment 7 GitLab Migration User 2018-07-30 10:12:56 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/271.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.