On Tue, 2017-02-21 at 19:39 -0300, Fatima Castiglione Maldonado å?? wrote: > Done. > I have run both browsers and, while doing each audio test, executed pactl > list. Output is attached for both test instances. Chrome and firefox use the same latency configuration and the same sample rate, so neither of those is the problem. Both seem to configure 8 ms latency, although the real source latency seems to be much higher (180 ms). This discrepancy doesn't seem to cause problems for firefox, though. Here's a random thing to try: run chrome from the terminal, and set the PULSE_LATENCY_MSEC environment variable. That should override the latency that chrome configures. In case you're not familiar with how to run a command with an environment variable set, simply add the environment variable to the beginning of the command, like this: PULSE_LATENCY_MSEC=16 chrome You can experiment with different values. 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, pulseverbose.log.1, pulseverbose.log.2, etc). In case you don't know which file is the right one, attach all of them. (By the way, it's very weird if the recording stream creation really succeeds or fails depending on whether you started pulseaudio manually or not. There should be no difference in behaviour.) -- Tanu https://www.patreon.com/tanuk
