Hey,
On Thu, 27 Aug 2020, Fons Adriaensen wrote:
On Thu, Aug 27, 2020 at 12:51:11PM +0300, Kai Vehmanen wrote:
For reasons that predate my time in the team, the minimum period size for
many Intel platforms has been set to 192 bytes (in the topology file, i.e.
According to which stange rules would this value (192 = 3 * 2^6) lead to
2^k being rejected and 2^k + 8 being accepted ??
the constraint is simply that period size is a multiple of the minimum
value. I think in the examples of this thread (which Wim quoted), JACK was
run with stereo 32bit config, so the values would translate to:
120 frames -> 2*4*120=960 bytes (5*192)
264 frames -> 2*4*264=2112 bytes (11*192)
504 frames -> 2*4*504=4032 bytes (21*192)
2040 frames ->2*4*2048=16320 bytes (85*192)
...
I don't think the constraint makes really sense, but that's what it is now
(for all systems where 192 is the minimum period size). Luckily the param
is read from user-space (ALSA tplg), so it's not hardcoded in kernel nor
in firmware.
unsolved. I'll now promise to kick this forward. The main rub is that we are
missing a place to declare hw specific granularity constraints (i.e. how to
set period_size step site for each hw)
That looks like a serious design error...
We do need to address it, but in practise, the current topology files we
ship (in SOF git tree) are per hardware, so for practical purposes
declaring the values in topology has had the same effect. Still, the issue
remains, not arguing that.
Br, Kai
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
