On Wed, Jan 20, 2016 at 02:26:08PM +0100, Arnaud Pouliquen wrote: > > > On 01/19/2016 05:54 PM, Russell King - ARM Linux wrote: > > However, some of the values given in the HDMI specs for CTS are actually > > two values, because a single value does not specify the audio clock even > > with the N values given. For these, the values returned will not give > > an accurate clock - this should also be noted. > > In HDMI specs i only see a double value for 32 kHz with TMDS clock at > 74.324 MHz. I can add a alt_CTS params in hdmi_audio_n_cts that will > be not null if alternate a value is needed. Is this something reasonable > for you? They aren't "alternatives". They give two values because, in order to generate that audio sample rate, you need to switch between the two values to achieve an average audio sample rate that matches the requested rate. I suspect that unless you have special hardware which does that for you automatically, these values are less than ideal. For example, for 32kHz: 74.25 / 1.001 11648 210937-210938* which is: 74250000 / (1.001 * 210937 * 128) * 11648 = 32000.076 74250000 / (1.001 * 210938 * 128) * 11648 = 31999.924 So, alternating between each for 50% of the time gives 32kHz. For my other points: Section 7.2.3: It is recommended that Sources with non-coherent clocks use the values listed for a TMDS clock of "Other". As you have non-coherent clocks, and your CTS value is measured by the hardware, using the "Other" N values seems to be recommended by the standard. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
