fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: la Fleur
Subject: Re: [fluid-dev] alsa audio driver only accepting huge period size
Date: Sat, 08 May 2021 18:03:37 +0200
User-agent: Evolution 3.40.1

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]