On 04/03/2019 18:59, Sven Van Asbroeck wrote:
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?
I am not the right person say if this should be taken forward.
However, if we are going forward, I think we need to add bclk_rate to snd_pcm_hw_params too, since the available bclks affects the choice of bclk_ratios that are available. For instance if the bclk is generated from static clock with a simple divider then following equatios should always be satisfied:
bclk_rate = clk_source_rate / clk_divider, where clk_divider = 0, 1, ..n sample_rate = bclk_rate / bclk_ratio
The good news is that snd_pcm_hw_rule_add() should be able to cope with such cross dependencies.
BR, Jyri