PulseAudio can crash for many different reasons, so it is not certain all reporters have the same root cause.
Looking at the latest log (from jcolton), it seems to get stuck in an endless loop of rewinds. After a while, this crazy thing happens:
After yet some time, PulseAudio is probably being killed by the kernel for taking up too much RT prio time.
It would be interesting to know is the latest stable-queue rewind patch would help against this issue. I have a feeling it won't, but it could be worth checking.
PulseAudio can crash for many different reasons, so it is not certain all reporters have the same root cause.
Looking at the latest log (from jcolton), it seems to get stuck in an endless loop of rewinds. After a while, this crazy thing happens:
( 40.601| 0.000) D: source.c: Processing rewind... 18446744073709. 551) W: asyncq.c: q overrun, queuing locally
( 40.602| 0.001) W: asyncq.c: q overrun, queuing locally
( 40.602| 0.000) W: asyncq.c: q overrun, queuing locally
( 40.604| 0.001) W: asyncq.c: q overrun, queuing locally
( 40.604| 0.000) D: protocol-native.c: Requesting rewind due to rewrite.
( 40.604| 0.000) D: alsa-sink.c: Requested to rewind 103408 bytes.
( 40.604|
^^^^ <- hmm, memory overwrite?
( 40.604| 0.000) D: alsa-sink.c: Limited to 11708 bytes.
( 40.605| 0.000) D: alsa-sink.c: before: 2927
( 40.605| 0.000) D: alsa-sink.c: after: 2927
( 40.605| 0.000) D: alsa-sink.c: Rewound 11708 bytes.
( 40.605| 0.000) D: sink.c: Processing rewind...
After yet some time, PulseAudio is probably being killed by the kernel for taking up too much RT prio time.
It would be interesting to know is the latest stable-queue rewind patch would help against this issue. I have a feeling it won't, but it could be worth checking.