On Tue, Jul 18, 2017 at 07:14:04PM -0400, Felipe Sateler wrote: > On Tue, Jul 4, 2017 at 9:39 PM, Adam Borowski <kilob...@angband.pl> wrote: > > > > > Is there any more debugging info I should attach? I have !clue about > > > > pulseaudio hacking. > > . > > > You could attach a verbose log of pulseaudio; > > > > > > $ pulseaudio --kill ; pulseaudio --log-target=file:pa.log --log-time & > > > # suspend, resume and check the problem happens > > > $ pulseaudio --kill ; pulseaudio --start # to get a new pulse daemon > > > > > > That would most certainly help. > > --- > > > Oops, I forgot to add -vvvv to the pa command line. > > > > Ouchie, somehow this bug mail was lost -- and in the meantime I was happy > > with ALSA. Well, I'm still happy, but Firefox is currently w/o audio... > > Sorry for this. Thus, with an, ahem, small delay: > > > > Here's the log. The bug still reliably reproduces, even on 4.12 kernel > > fresh from Linus, and so it does on our official 4.9. > > > > Is this machine particularly slow? 4s to probe alsa looks a bit slow.
A regular amd64 desktop, somewhat long in the tooth now but was quite decent when bought 5 years ago. No non-negligible load at the time of the test. > Anyway, when (relative to the log) did you suspend the machine, and when > did you experience the problem? Started the sample sound using mplayer (visible in the log connecting at 16.667), suspended right after -- at human reaction speed, without special haste, so it should be ~3 seconds, waited around 10 seconds before resuming. The start of errors at 29.281 apparently matches resume. > I see a few Wakeups from alsa, plus some underruns. Possibly tsched does > not work very well on your driver, could you try passing tsched=0 to > module-udev-detect in default.pa ? Will test this when I can reboot with pulse. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄⠀⠀⠀⠀ A master species delegates.