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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
