Re: [LAU] JACK and Sound OpenFirmware?

Hi folks, On Wed, 19 Aug 2020, Mario Lang wrote: 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_boa… Br, Kai