[pulseaudio-discuss] Sound recording/routing issues on Librem5

[Tanu Kaskinen]

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