On Mon, Feb 25, 2019 at 10:58:34PM +0200, Jyri Sarha wrote: > I think there are other options too. The obvious one would be passing > the blck_ratio callback trough HDMI-codec to HDMI-bridge-driver, but > yes, I do not like that either. > > The other would be changing the implicit bclk_ratio to 2 x sample-width, > and accepting blck_ratios of 36 and 40 in tda998x, and set CTS_N_M = 3 > and CTS_N_K = 2 for them too. To put a bit of further information out there... I really don't like that idea - what if we have a transmitter that really does use a bclk_ratio of 36 or 40? That would mess up the CTS calculation in the TDA998x. The equation I've come up to fit what we know for TDA998x is: k = m * bclk_ratio / 128 where k and m are parameters that we values we select for TDA998x. This reflects the entire clock regeneration system including the sink. The possible values of k are 1, 2, 3, 4, or 8. m are 1, 2, 4, or 8. I also have this equation which defines the fs regenerated at the sink: fso = bclk_ratio * fsi * m / (128 * k) If we did have a ratio of 36 or 40, the first equation above fails since k is not one of the possible integers. If we round down and use e.g. 2 for the 36fs case, then we'd actually end up with a sample frequency on the sink of 1.125x faster than it should be, and the sink would suffer starvation of audio samples. If we rounded up to 3, then the sample frequency will be 3/4 of it's true value, so the sink will overflow and would have to discard audio samples. We know this happens, because that's the root of the problem at hand: wrongly setting the m and k values for the bclk_ratio being supplied to the TDA998x causes audio to be corrupted when reproduced by the sink. Given that, we do need some way to validate the bclk_ratio when it is set, and not during hw_params which would (a) lead to ALSA devices failing when userspace is negotiating the parameters and (b) gives no way in the kernel for set_bclk_ratio() to discover whether a particular ratio is supported by the codec. So, I think there's three possible ways around this: 1. adding a set_bclk_ratio() method to hdmi_codec_ops 2. calling hw_params() when our set_bclk_ratio() method is called (what if the rest of the format isn't set or incompatible, which may cause the hw_params() method to fail?) 3. adding a list of acceptable bclk_ratio values to hdmi_codec_pdata -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
