Re: [fluid-dev] alsa audio driver only accepting huge period size

[la Fleur]

Turns out it was a driver implementation limit. I changed LPASS_PLATFORM_BUFFER_SIZE to (2 * 1024) and now I get around 5ms theoretical latency at 48KHz. The main drawback of this LPASS implementation is that you can't change the period_size or number of periods ; they're hardcoded in the driver. But now I have what I needed. Thank you very much for your insights, it really helped understanding what was going on. As a result, here is an exerpt of what I said to folks on the postmarketos Matrix room. @Markus I hope you don't mind me quoting you namely. That room is dedicated to making things work on phones running mainline linux, so it's not Facebook either 

A little calculus if you'll excuse the detour :

1latency (ms) = number_of_periods * period_size (s) / samplerate (KHz)

Now in LPASS, as pointed by Marcus Weseloh from the fluid-dev mailing list, the period size is :

1period_size_max = period_size_min = LPASS_PLATFORM_BUFFER_SIZE / ( LPASS_PLATFORM_PERIODS * resolution )

And on most platforms, resolution is 4 (bytes, that is, 32 bits).

With the current mainline settings, LPASS_PLATFORM_BUFFER_SIZE is 49152 and ..._PERIODS is 2, so period_size_min is 6144, which, at a samplerate of 48KHz leads to a theoretical latency of 128ms, which is far above the acceptable 20ms for live instruments.

I changed ..._BUFFER_SIZE to 2048 ; it brings latency down to 5.3ms (this is confirmed by jackd -dalsa -n2 -p256 -r48000, to make sure my calculus is all right).

[...]

I noticed looking at the ULT Audio documentation you gave earlier that the audio hardware on Snapdragon 410E is able to get as high as 96KHz samplerate (which is twice as needed to reproduce human-hearable sounds). That might be how pulseaudio achieved a lower latency than plain alsa. But it just brings latency down from 128 to 64ms, which is still unacceptable in live conditions.

Le dimanche 09 mai 2021 à 19:45 +0200, Ceresa Jean-Jacques a écrit :

 

>I really wonder how pulseaudio manages to have a very low latency with the very same hardware. Any clue ?

 

Did you try the "alsa hardware layer" as explained in https://github.com/FluidSynth/fluidsynth/wiki/LowLatency ?

Example: ./fluidsynth –o audio.alsa.device=hw:0

jjc

 

_______________________________________________

fluid-dev mailing list

fluid-dev@nongnu.org

https://lists.nongnu.org/mailman/listinfo/fluid-dev