[LAU] JACK and Sound OpenFirmware?

[Kai Vehmanen]

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