[pulseaudio-discuss] problem with webrtc and pulseaudio

Tanu Kaskinen tanuk at iki.fi
Tue Feb 28 13:27:17 UTC 2017

On Fri, 2017-02-24 at 23:52 -0300, Fatima Castiglione Maldonado 发
> > 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

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.



More information about the pulseaudio-discuss mailing list