Re: [PATCH RFC 2/3] ASoC: hdmi-codec: add support for bclk_ratio

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 1, 2019 at 7:36 AM Mark Brown <broonie@xxxxxxxxxx> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux