On Wed, 2019-12-04 at 11:47 -0700, Angus Ainslie wrote: > 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. I suspect you're going to need this patch, which is included in PulseAudio 13: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/e794d0a21af24ae3d2afae000ad67b17ef56ada2 The latency_msec option won't prevent the buffer from growing if the sink isn't consuming the data that the source is producing. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
