Hi Tanu,
On 2019-12-02 08:49, Angus Ainslie wrote:
Hi Tanu,
On 2019-11-30 12:02, Tanu Kaskinen wrote:
On Thu, 2019-11-28 at 16:44 -0700, Angus Ainslie wrote:
Hi,
The modem sink is passing audio so that's good. The issue with the
sink
is there is about 3 seconds of latency. I can see ~1 second of that
due
to the cellular network.
How would I check the latency through pulseaudio ?
I assume you use module-loopback to route the modem audio to the phone
speakers. I use module-loopback to route audio from an electric piano
to the computer speakers (actually just USB sound card input to the
same card's output), so I can explain how I would check the loopback
latency in my case:
$ pactl list source-outputs
Source Output #11
Driver: module-loopback.c
[...]
Buffer Latency: 0 usec
Source Latency: 0 usec
[...]
Properties:
[...]
media.name = "Loopback to PreSonus AudioBox iTwo Analog
Stereo"
[...]
So here we see that I have a recording stream created by module-
loopback with zero latency from the source and zero internal latency.
$ pactl list sink-inputs
Sink Input #959
Driver: module-loopback.c
[...]
Buffer Latency: 12607 usec
Sink Latency: 15778 usec
[...]
Properties:
[...]
media.name = "Loopback from PreSonus AudioBox iTwo
Analog Stereo"
[...]
Here we see that I have a playback stream created by module-loopback
with 15.8 ms latency from the sink and 12.6 ms internal latency. So
far
28.4 ms in total.
What these commands don't show is the latency introduced by module-
loopback's internal buffer. The fill level of that buffer is not
currently shown anywhere. However, the module arguments show what
total
latency the loopback is trying to achieve:
$ pactl list modules
Module #41
Name: module-loopback
Argument:
source=alsa_input.usb-PreSonus_PreSonus_AudioBox_iTwo_AB5C18071273-00.analog-stereo
sink=alsa_output.usb-PreSonus_PreSonus_AudioBox_iTwo_AB5C18071273-00.analog-stereo
latency_msec=10 adjust_time=0
Usage counter: n/a
Properties:
module.author = "Pierre-Louis Bossart"
module.description = "Loopback from source to sink"
module.version = "13.0-8-gd72a3"
The module is loaded with argument "latency_msec=10", and that target
apparently isn't being met (this is interesting news to me!). 10 ms is
probably unnecessarily low target, since I haven't noticed while
playing that the piano would have too high latency. In any case, since
I care about latency more than avoiding dropouts, I should use the
"max_latency_msec" argument instead (new in PulseAudio 13.0).
"latency_msec" relaxes the initial target if there are buffer
underruns, but "max_latency_msec" sets a hard ceiling for the total
latency.
I hope this helps. 3 seconds of latency sounds weird, because even if
you don't configure any latency with module-loopback, the default
latency isn't that high. The latency handling in module-loopback was
very bad prior to 11.0, but I hope you're not using that old
PulseAudio.
Your modem seems to have a fixed latency of 100 ms (maybe you've set
tched=0?), which sounds a bit high for something that is used for call
audio.
Dropping the alternate rate caused pulse audio to use 48K which
allowed the sound to flow through the loopbacks and the latency
disappeared at the same time.
So it didn't actually disappear I was just getting too good at my
testing cycle and was answering calls as quickly as they came in.
Whats causing the latency is that the audio starts recording as soon as
the call is placed and gets buffered until that call connects. Once the
call connects there are x seconds ( however long it took to pick up the
call ) of audio buffered that starts playing out.
So I need to figure out how to drop that audio until the call connects.
If we were using pulseaudio 13 your suggestion sounds like a great idea.
As we're using PA 12 I'm going to see if I can adjust the buffers and
latency_msec to get rid of it.
Angus
Thanks for your help.
Angus
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
