Sounds right - my phone's kernel sources (qcom-msm8916-5.12) have the
same features. Is there a way I can workaround this hardware limitation
using alsa's dmix ? I would go for JACK if it could help, but the same
limitations seem to apply.
I find it quite ironic that everybody present pulseaudio as a non-
professional audio system, but it's the only one that achieves low-
latency in this case. I really wonder how pulseaudio manages to have a
very low latency with the very same hardware. Any clue ?
I just spent hours looking for ways to achieve this using dmix. I tried
this in `~/.asoundrc` :
pcm.mixed {
type dmix
ipc_key 1024
slave {
pcm "hw:0"
rate 48000
periods 24
period_size 256
buffer_size 1
}
}
But then `aplay -D plug:mixed /usr/share/sounds/alsa/Front_Center.wav`
just plays half of the file. In fact any setting in `pcm.mixed` turns
out the same.
Le vendredi 07 mai 2021 à 22:14 +0200, Marcus Weseloh a écrit :
> Hi,
>
> my guess is that it's a hardware limitation. It seems like your phone
> is using the QTi LPass ASoC driver, which has a fixed number for
> period size and periods:
> https://gitlab.com/postmarketOS/linux-postmarketos/-/blob/qcom-msm8974-5.11.y/sound/soc/qcom/lpass-platform.c#L46
>
> .period_size_min = .period_size_max = LPASS_PLATFORM_BUFFER_SIZE /
> LPASS_PLATFORM_PERIODS
> So that's 24 * 1024 = 24576. And if you divide that by 4 bytes (max
> 32bit resolution), you get 6144. Seems to fit.
>
> Cheers
> Marcus
>
> _______________________________________________
> fluid-dev mailing list
> fluid-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
