On Fri, 2017-02-24 at 23:52 -0300, Fatima Castiglione Maldonado å?? wrote: > > At this point I don't expect this problem to get solved, but if you want > > to still continue debugging, you could try one more time to get a > > PulseAudio log. Based on the earlier experiments it looks like chrome > > doesn't create a recording stream if you start pulseaudio manually, but > > you can enable verbose logging of the automatically started pulseaudio > > instance by putting this to ~/.config/pulse/client.conf: > > > > extra-arguments = -vvvv --log-target=newfile:/tmp/pulseverbose.log --log-time=1 > > > > The log files are in the /tmp directory. You might see more than one file > > (pulseverbose.log, puolseverbose.log.1, pulseverbose.log.2, etc). In case > > you don't know which file is the right one, attach all of them. > > Done. Log as attachment. Ok, this log shows recording streams from Chrome. Unfortunately, I don't find any obvious problems in the log. The stream creation pattern looks a bit weird, though. Multiple streams get created, and some of them run simultaneously. This shows when recording streams are created and freed: grep -e "Created output" -e "Freeing output" pulseverbose.log First stream #0 is created with sample spec "s16le 2ch 48000Hz". 13 seconds later stream #1 is created with sample spec "s16le 1ch 44100Hz". 14 seconds later there's a burst of activity: another mono stream (#2) is created, but it's immediately freed, and #1 gets freed roughly at the same time, and then another mono stream (#3) is created. A second later #3 is freed and #4 is created. 10 seconds later #4 is freed and #5 is created. 2 seconds later streams #0 (which has been running all this time) and #5 are freed. 70 seconds later a quite similar pattern repeats. I don't know if this information is helpful at all. -- Tanu https://www.patreon.com/tanuk
