Len <len(a)ovenwerks.net> writes: There is only one way forward: forward. I'd rather not do that. The old driver had its own problems (no mic). -- CYa

On Wed, 19 Aug 2020, Wim Taymans wrote: All out by 8. The next question would be: does 136, 248, 520, 1016 and 2056 work as well? The next question after that, is which applications and plugins choke on non-power of two buffer sizes... -- Len Ovens www.ovenwerks.net

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

Hey, On Thu, 27 Aug 2020, Fons Adriaensen wrote: 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. 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

Kai Vehmanen <kvlists(a)nosignal.fi> writes: Thanks a lot for chiming in and shedding some light on this issue. Also thanks for volunteering to get it fixed. I am looking forward to that fix landing on my system. -- CYa, ⡍⠁⠗⠊⠕

On Thu, 19 Nov 2020, Kai Vehmanen wrote: Good. This is not much different from USB audio devices and in my experience, 64/2 at 48k is sometimes already lower latency than many intel HDA-ish devices can handle anyway. -- Len Ovens www.ovenwerks.net