Summary: | srbchannel: Sound dies after a couple of minutes with wine game and voice chat program. | ||
---|---|---|---|
Product: | PulseAudio | Reporter: | poljar |
Component: | core | Assignee: | pulseaudio-bugs |
Status: | RESOLVED FIXED | QA Contact: | pulseaudio-bugs |
Severity: | normal | ||
Priority: | medium | CC: | lennart |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | pulseaudio log |
: [pulseaudio] source.c: device.product.name = "Audio Device" I: [pulseaudio] source.c: device.serial = "C-Media_INC._USB_Audio" I: [pulseaudio] source.c: device.string = "0" I: [pulseaudio] source.c: module-udev-detect.discovered = "1" I: [pulseaudio] source.c: device.icon_name = "audio-card-usb" I: [pulseaudio] alsa-sink.c: Using 4,0 fragments of size 4796 bytes (24,98ms), buffer size is 19188 bytes (99,94ms) D: [pulseaudio] alsa-sink.c: hwbuf_unused=0 D: [pulseaudio] alsa-sink.c: setting avail_min=1 D: [pulseaudio] alsa-mixer.c: Activating path analog-output D: [pulseaudio] alsa-mixer.c: Path analog-output (Analog Output), direction=1, priority=99, do you get the same result for your usb audio ? seem not exactly 25ms http://mailman.alsa-project.org/pipermail/alsa-devel/2014-December/085579.html http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081501.html you can try Alexander's pcm_avail.c to find out whether your usb audio can report hwptr at 1ms interval? Hmm, looks like the stream stops for some reason. Could you edit src/pulsecore/srbchannel.c and uncomment DEBUG_SRBCHANNEL, like shown below? That will make the log even larger though :-/ After that, make a new verbose log, and also with --log-time=1 as this problem is likely timing dependent. Thanks! diff --git a/src/pulsecore/srbchannel.c b/src/pulsecore/srbchannel.c index 8872a89..4f20516 100644 --- a/src/pulsecore/srbchannel.c +++ b/src/pulsecore/srbchannel.c @@ -28,7 +28,7 @@ #include <pulsecore/atomic.h> #include <pulse/xmalloc.h> -/* #define DEBUG_SRBCHANNEL */ +#define DEBUG_SRBCHANNEL /* This ringbuffer might be useful in other contexts too, but * right now it's only used inside the srbchannel, so let's keep it here So, tried just running a low-latency stream (playback + two recording streams) for 15-20 minutes (through pacat) with srbchannel debug on. I also ran "while :; do src/pactl list; done" in parallel to stress the system even further. But I could not reproduce the problem. Works just fine and I see nothing of the big packets I saw in your bug. All srbchannel packets are 16-40 bytes or so. I seem to have lost your 400 MB log file you pointed me to on IRC - could you link to it from this bug as well? So I suspect that this might have something to do with those occasional big packets. I wonder what is sent in those packets... Hi, I've posted a patch set here that fixes a hopefully related bug: http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-March/023310.html Could you try it and see if it helps your use case too? Thanks. (In reply to David Henningsson from comment #5) > Hi, > > I've posted a patch set here that fixes a hopefully related bug: > http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-March/023310. > html > > Could you try it and see if it helps your use case too? Thanks. Hi, I've tested the patches and couldn't reproduce this anymore, so I guess the bug is fixed. Great work David, closing this now. @Raymond, USB sound cards have a separate class of issues and I couldn't test them with wine applications. |
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.
Created attachment 111926 [details] pulseaudio log While playing a wine game (League of Legends) and using voice chat program (Teamspeak3) the both audio streams start to experience crackling and after a couple minutes sound disappears. The clients are still connected after sound has disappeared. Disabling srbchannel restores normal behaviour. A log is attached albeit trimmed because pulseaudio produced 40MB of logs in 5 to 10 minutes. I have not found a smaller test case to trigger this bug.