[LAU] JACK and Sound OpenFirmware?

[Kai Vehmanen]

Hi folks,

On Wed, 19 Aug 2020, Mario Lang wrote:
> What I'd find much more interesting to think about is: What do we need
> to do to fix sof?  After all, it has "Open Firmware" in its name, so I
> am assuming we should be able to fix bugs even at the firmware level.

uh oh, this is more than a bit embarrasing that SOF doesn't play nice with 
JACK. I nowadays work (long story) in the SOF team and can help you out 
here.

The constraint on PCM period size is set in generic SOF kernel code that 
is shared by all vendors. There's a rule that sets step size constraint 
based on a value read from DSP topology (an ALSA tplg file which is read 
when the driver is loaded and defines the DSP internal topology).

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. 
user-space conf file). And when this is used to set the constraint in 
ALSA, you get the very JACK unfriendly period sizes. There's no 
fundamental limit in hw that would prevent JACK friendy period sizes.

There's been a lengthy debate about this in SOF project and issue is still 
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) -- we don't think these 
should be in the DSP topology files (as that should not declare 
fundamental hw reqs, but rather describe how the DSP should be set up), 
but neither they belong in generic SOF kernel code (which is same for all 
hw and vendors). But yeah, just not done.

To solve this in short term, you can either take the kernel patch from:
https://github.com/thesofproject/linux/pull/1717

Or modify the DSP topology file for your hardware to set minimum period 
size to e.g. 64 or 128 bytes. This is a bit more involved path as you need 
to set up the SOF toolchain (we define DSP topologies in m4, convert to 
ALSA .conf format and then use the ALSA tplg compiler to get the binary 
actually loaded to driver).

PS If you are interested in developing DSP code yourself with SOF, feel
    free to ping me. I do want to make the note that on many Linux/Windows
    laptops, while the DSP firmware sources are public, the DSP has to be
    signed, and it is _not_ possible to load your custom SOF DSP image on
    these systems. This is unfortunate from LAD/LAU perspective, but it's a
    choice out of SOF teams' hands. We do have increasing amount of
    shipping hw (including Chromebooks) where the system allows load of a DSP
    image signed with the community key. I e.g. use an UP2 board myself -- driver,
    firmware and toolchain are all opensource:
    https://up-shop.org/up-squared-series.html
    https://thesofproject.github.io/latest/getting_started/setup/setup_up_2_board.html#

Br, Kai