[alsa-devel] [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware'

Sven Van Asbroeck thesven73 at gmail.com
Tue Mar 5 15:23:46 CET 2019


Hi Takashi,

On Mon, Mar 4, 2019 at 11:42 PM Takashi Sakamoto
<o-takashi at sakamocchi.jp> wrote:
>
> Anyway, when posting to change UAPI of Linux sound subsystem, it's
> better to describe the reason fot new stuffs; what they're designed for,
> and the reason to require them. Wnen posting in a result of series of
> discussion done previously, it's better to add any reference to it.

My apologies for not linking in previous discussions, I'll certainly make
sure to link in the future.

The original problem was that the fsl_ssi did not appear to work with the
tda998x hdmi codec. This codec seems to be 'unique' in the sense that it
needs to know the number of clocks per frame on the wire, i.e. the bclk_ratio,
which no-one in alsa is providing or using at the moment.

I first made the error of conflating the physical width and the bclk_ratio,
and posted this patch - Russell King quickly pointed out my error:
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/145916.html

This then led to the following discussions:
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/thread.html#145985
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/thread.html#145947

Most of the discussion is about a mechanism to convey bclk_ratio from
the frame master
to the tda998x. We don't yet seem to have a consensus on how to do this best.

My rfc patch was only intended to provoke discussion, and to allow
people to experiment
with a flawed solution that would allow the alsa core to negotiate
bclk_ratio between
components. The uapi change is a serious flaw. bclk_ratio negotiation should be
invisible to userspace. But I cannot see a way to accomplish this.

Sven


More information about the Alsa-devel mailing list