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; }
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
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 */ +
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
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?
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 ?
(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
-- 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.