HDMI Audio pitch not consistent between video modes

[maxj]

On an i.MX6Q embedded Linux device, I have an application with two different video modes available: 1280x1024 and 800x600.  Here are the mode specs from /etc/fb.modes:

mode "1280x1024 60Hz 24bit"

    # D: 107.99 MHz, H: 64.281 KHz, V: 60.08 Hz

    geometry 1280 1024 1280 5120 24

    timings 9260 128 128 40 2 144 4

    hsync high

    vsync high

endmode

mode "800x600 59Hz 24bit"

    # D: 41.38 MHz, H: 37.754 kHz, V: 59.93 Hz

    geometry 800 600 1280 5120 24

    timings 22727 128 96 24 2 144 4

    hsync high

    vsync high

endmode

When I use the speaker test to generate a sine wave, e.g. using:

speaker-test -D plughw:0,0 --test sine

(Note: in my hardware/kernel HDMI is the only audio device.)

I get a different tone (pitch/frequency) depending on which video mode is selected, even though the speaker test is supposed to generate a default frequency of 440 Hz (music note A4) for the sine wave.  The difference between the two in the different video modes is easily noticeable.  Off hand, I'm not sure if or which one is correct.

Does anyone know why different frequencies are being output?

[EricNelson]

Hi Max,

Neither 1280x1024 or 800x600 is a CEA video mode, so neither is likely to have a proper audio divisor.

     linux-imx6/drivers/video/mxc/mxc_edid.c at boundary-imx_3.0.35_4.1.0 · boundarydevices/linux-im...

The CEA mode indexes are used in a relatively long chain to calculate some divisors in the HDMI PHY:

     linux-imx6/drivers/mfd/mxc-hdmi-core.c at boundary-imx_3.0.35_4.1.0 · boundarydevices/linux-imx6 · G...

[maxj]

Thanks Eric.  These changes have been applied to mxc-hdmi-core.c in order to get the audio for these video modes.

diff -Naur '--exclude=compile*' '--exclude=mxc_hdmi.c' linux-3.0.35.orig/drivers/mfd/mxc-hdmi-core.c linux-3.0.35/drivers/mfd/mxc-hdmi-core.c

--- linux-3.0.35.orig/drivers/mfd/mxc-hdmi-core.c 2013-09-11 13:04:35.000000000 -0700

+++ linux-3.0.35/drivers/mfd/mxc-hdmi-core.c 2013-11-05 13:34:05.000000000 -0800

@@ -502,15 +502,32 @@

  clk_n = hdmi_compute_n(sample_rate, pixel_clk_rate, hdmi_ratio);

  clk_cts = hdmi_compute_cts(sample_rate, pixel_clk_rate, hdmi_ratio);

+        // If pixel-clock isn't one of the Freescale out-of-the-box ones,

+        // estimate cts and n values

+        if( clk_cts == 0 ){

+            //

+            // From ADV7511 Programming guide:

+            // 128 *Fs = Ftmds_clk * (n/cts)

+            //

+            unsigned int temp;

+            clk_n = 6272;

+            clk_cts = clk_n * (pixel_clk_rate / (128 * sample_rate));

+

+            // known working values for 99MHz pixel_clk_rate:

+            //clk_cts = 110000;

+            //clk_n = 6272;

+        }

+

+ pr_info("%s: samplerate=%d  ratio=%d  pixelclk=%d  N=%d  cts=%d\n",

+ __func__, sample_rate, hdmi_ratio, (int)pixel_clk_rate,

+ clk_n, clk_cts);

+

  if (clk_cts == 0) {

- pr_debug("%s: pixel clock not supported: %d\n",

+ pr_info("%s: pixel clock not supported: %d\n",

  __func__, (int)pixel_clk_rate);

  return;

  }

(Please ignore the unused variable.)

I know in advance that the sample rate is 44100 Hz, which is why (so I believe) I can get away with the hard-coded 6272.

There are also some changes to mxc_edid.c that have been made, but I'm not sure if they're significant.  Please let me know if you need to see that as well.

Perhaps this change is also causing the problem?

Anything else that might be missing?

[YixingKong]

Max

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,
Yixing