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

Angus Ainslie angus at akkea.ca
Wed Dec 4 18:47:46 UTC 2019


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


More information about the pulseaudio-discuss mailing list