On Fri, Mar 1, 2019 at 7:36 AM Mark Brown broonie@kernel.org wrote:
As Russell outlined there's quite a bit of hopeful assumption in how ASoC handles the mapping of memory formats onto wire formats which works almost all the time but not always and definitely not through robust design
Yes, many of the painful tradeoffs in this discussion would go away, if the alsa negotiation infrastructure was 'bclk_ratio aware'.
They say that a 100-line patch is often better than 1000 words. To help kick- start a discussion, I offer a simple patch which adds bclk_ratio to hw_params, which lets alsa 'negotiate' it the same way as the format, channels, etc.
Obviously this is completely flawed, as it exposes bclk_ratio to userspace thru snd_pcm_hw_params. Userspace has no business even knowing about this on-wire property.
It may be flawed in a lot of other ways I can't see rn :)
As far as a flawed suggestion goes, it seems to behave quite well on my system. The bclk_ratio is nicely constrained within the cpu and codec's supported ranges and rules, and the lowest supported value is picked before hw_params() gets called. Which is at least channels * sample_width.
Would there be a way to hide the bclk_ratio from userspace?
Is it even worth taking this forward? How likely is it for alsa components to care about the bclk_ratio? Maybe this is a tda998x one-off?
Sven