This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AUDK2G: Setting sample rate for AUDK2G

Part Number: AUDK2G

Hello,

A lot of these questions come from the threads here:



But I think these questions are separate, and probably a little easier to answer

1) Does the AUXCLK pin (on the McASP TX/RX Clock Generator Block Diagram) come from the audio oscillator on the K2G, similar to the AIC codec on the EVMK2G board?

a) If so, does that mean that since the EVMK2G board has the 22.5792 MHz crystal, I'm only capable of 22.050kHz, 44.1kHz, 82.2kHz, etc, sample rates on the audio daughtercard as well?

b) If that is true, can you provide a link or instructions for switching out the crystal?  I'm not a hardware guy, personally, but I can forward it to the hardware guys on my team.

2) In a previous thread, it was pointed out that to calculate the sample rate from the bit sample clock, it's "each audio data sample(I2S format) has 2 channels and each channel is 16 bits in our configuration. So to send a data sample(2 channels) you will need 44.1*2*16 = 1411.2 Khz bit clock.", for the example of 44.1kHz audio.

Is the number of "audio data sample" channels the same regardless of how many serializers you use?

3) Given the 22.5792MHz crystal oscillator we have now, I'm trying to achieve 88.2kHz audio (I would like 96kHz after switching crystals, but the clock divider settings should remain the same).

Here are the settings I have for the Mcasp_HwSetupData structs in mcasp_cfg.c:

/* McASP HW setup for receive */
Mcasp_HwSetupData mcaspRcvSetup = {
        /* .rmask    = */ 0xFFFFFFFF, /* 16 bits are to be used     */
        /* .rfmt     = */ 0x000180F2, /*
                                       * 0 bit delay from framesync
                                       * MSB first
                                       * No extra bit padding
                                       * Padding bit (ignore)
                                       * slot Size is 32
                                       * Reads from DMA port
                                       * NO rotation
                                       */
        /* .afsrctl  = */ 0X00000112, /* I2S mode - 2 slot TDM
                                       * Frame sync is one word
                                       * Internally generated frame sync
                                       * Rising edge is start of frame
                                       */
        /* .rtdm     = */ 0x00000003, /* slot 1 and 2 are active (I2S)        */
        /* .rintctl  = */ 0x00000000, /* sync error and overrun error         */
        /* .rstat    = */ 0x000001FF, /* reset any existing status bits       */
        /* .revtctl  = */ 0x00000000, /* DMA request is enabled               */
        {
             /* .aclkrctl  = */ 0x000000A7,
             /* .ahclkrctl = */ 0x0000C000,
             /* .rclkchk   = */ 0x00000000
        }
};

/* McASP HW setup for transmit */
Mcasp_HwSetupData mcaspXmtSetup = {
        /* .xmask    = */ 0xFFFFFFFF, /* 16 bits are to be used     */
        /* .xfmt     = */ 0x000180F6, /*
                                       * 0 bit delay from framesync
                                       * MSB first
                                       * No extra bit padding
                                       * Padding bit (ignore)
                                       * slot Size is 32
                                       * Reads from DMA port
                                       * NO rotation
                                       */
        /* .afsxctl  = */ 0x00000112, /* I2S mode - 2 slot TDM
                                       * Frame sync is one word
                                       * Rising edge is start of frame
                                       * Internally generated frame sync
                                       */
        /* .xtdm     = */ 0x00000003, /* slot 1 and 2 are active (I2S)               */
        /* .xintctl  = */ 0x00000000, /* sync error,overrun error,clK error   */
        /* .xstat    = */ 0x000001FF, /* reset any existing status bits       */
        /* .xevtctl  = */ 0x00000000, /* DMA request is enabled or disabled   */
        {
             /* .aclkxctl  = */ 0X000000A7,
             /* .ahclkxctl = */ 0x0000C000,
             /* .xclkchk   = */ 0x00000000
        },

};

The relevant parts being aclkrctl, ahclkrctl, and aclkxctl, ahclkxctl.

The settings indicate the the HF clock divider, and regular clock divider are set to 1 and 8, respectively.  Which would give us a final transmit clock rate of 2822400Hz (22.5792MHz / 8).

This means the audio sample rate is 2822400 / 2(channels) / 16(bits per channel) = 88.2kHz, correct? (I just wanted to make sure on this point).

4) If I wanted to set my sample rate higher, I would have to then modify the regular (non HF) clock divider to have smaller divisor.  For instance, if I wanted 176.4kHz audio rate, I would need to change the clock divider to 4, as in

  /* .aclkxctl  = */ 0X000000A3, // should be divisor of 4.

However, when I try that, I get no audio whatsoever.  If I try to set the clock divider to 0xAF (divisor of 16), I get what sounds like white noise at the output.  What am I doing wrong?

  • Hi,

    I've notified the sw team.
    In the mean time, could you share is this RTOS? Which SDK version is it?

    Best Regards,
    Yordan
  • It's the Linux SDK, but I'm programming straight to the metal through CCS. The SDK version is 3.2.
    PDK is version 1.0.4.

  • Justyn Bell said:

    1) Does the AUXCLK pin (on the McASP TX/RX Clock Generator Block Diagram) come from the audio oscillator on the K2G, similar to the AIC codec on the EVMK2G board?

    a) If so, does that mean that since the EVMK2G board has the 22.5792 MHz crystal, I'm only capable of 22.050kHz, 44.1kHz, 82.2kHz, etc, sample rates on the audio daughtercard as well?

    b) If that is true, can you provide a link or instructions for switching out the crystal?  I'm not a hardware guy, personally, but I can forward it to the hardware guys on my team.

    Audio clocking for this device has been described in the block diagram 5.4.4 in the Technical reference manual. On the EVM, we have a connected a Audio OSC, and set the MCASP[0:2]_AUXCLK_SEL[2:0] so it does seem that the MCASP clocks on the daughter card are sourced using the Audio oscillator which acts as the AUX clock 

    MCASP-AIC codec are connected so that MCASP is the master and drives the clock to the AIC. With 22.579 as I explained earlier this means that you can only set the clocking to sample data at 44.1 and 88.2 KHz. This configuration only applies to the base board and not to the Audio daughter card which uses a difference codec. When you connect the audio daughter card on the EVM, there is a hardware implementation which will disconnect the AIC interface from the signal path using a MUX so please note that ones the audio daughter card is connected, you will not be able to use the AIC3106 interface.

    On the audio daughtercard,  has the following interfaces connected in following configuration:

    you can check the connections in the EVM Schematics. I checked the AUDK2G driver in the software and it does setup the MCASP clock source to be AUDIO_OSCCLK  (check function  audk2g_AudioInit) which means that as in case of AIC codec the PCM codec also receives the bit clk from MCASPs so you will only be able to set the clocks to 44.1 and 88.2 when MCASP is driving the clocks on the system. 

    One way to resolve this as I mentioned earlier would be to swap out the AUDIO clock with 24.576 crystal. the AUdio Oscillator crystal is on the bottom of the board at location Y5 which you should be able tot swap out. 

    Justyn Bell said:

    2) In a previous thread, it was pointed out that to calculate the sample rate from the bit sample clock, it's "each audio data sample(I2S format) has 2 channels and each channel is 16 bits in our configuration. So to send a data sample(2 channels) you will need 44.1*2*16 = 1411.2 Khz bit clock.", for the example of 44.1kHz audio.

    Is the number of "audio data sample" channels the same regardless of how many serializers you use?

    This is configurable option on the MCASP. you can take input data in 8 bit, 16 bit, 24 bit and 32 bit format. Please refer to MCASP_RFMT and MCASP_XMT registers. This configurable option option on each MCASP instance  which means all serializers with configured MCASP instance will use same slot/data size.

    Justyn Bell said:

    3) Given the 22.5792MHz crystal oscillator we have now, I'm trying to achieve 88.2kHz audio (I would like 96kHz after switching crystals, but the clock divider settings should remain the same).

    Here are the settings I have for the Mcasp_HwSetupData structs in mcasp_cfg.c:

    Yes, your assessment is correct. To confirm after you configure it you can put a scope of TP193, TP205, TP206.

    Justyn Bell said:

    4) If I wanted to set my sample rate higher, I would have to then modify the regular (non HF) clock divider to have smaller divisor.  For instance, if I wanted 176.4kHz audio rate, I would need to change the clock divider to 4, as in

      /* .aclkxctl  = */ 0X000000A3, // should be divisor of 4.

    Yes, changing this should setup the bit clock and frame sync accordingly to the higher frequency. have you checked to confirm the clock has changed correctly to 176KHz. Have you changed any thing on the DAC. Are you recieving at 88.2 and transmitting at 176.4 ? Are there any MCASP errors reported in MCASP_XSTAT and MCASP_RSTAT.

    Regards,

    Rahul

     

     

  • I will review this in further details over the weekend and respond next week, but for now it says I don't have permission to access the image in your post.

    Thank you again
  • Hello, I've had time to review the response and do a little more work:

    Rahul Prabhu said:
    One way to resolve this as I mentioned earlier would be to swap out the AUDIO clock with 24.576 crystal. the AUdio Oscillator crystal is on the bottom of the board at location Y5 which you should be able tot swap out. 

    Can you provide a part number that would be an exact-fit 24.576MHz replacement so I can be as verbose as possible to the hardware guys?

    Rahul Prabhu said:
    Justyn Bell

    2) In a previous thread, it was pointed out that to calculate the sample rate from the bit sample clock, it's "each audio data sample(I2S format) has 2 channels and each channel is 16 bits in our configuration. So to send a data sample(2 channels) you will need 44.1*2*16 = 1411.2 Khz bit clock.", for the example of 44.1kHz audio.

    Is the number of "audio data sample" channels the same regardless of how many serializers you use?

    This is configurable option on the MCASP. you can take input data in 8 bit, 16 bit, 24 bit and 32 bit format. Please refer to MCASP_RFMT and MCASP_XMT registers. This configurable option option on each MCASP instance  which means all serializers with configured MCASP instance will use same slot/data size.



    Just to be clear, I think I have a grasp on the MCASP_RFMT/MCASP_XMT registers but what I'm not clear on is if the number of serializers would change the number of "channels" of each data sample.  Since, in my case, I'm using two serializers for receive, and 1 serializer for transmit.  Do the values of the clock dividers have to be different?

    Another way:  if the equation is <sample_rate> * <number_of_channels> * <bit_format> = <bit clock>.  If I'm using two serializers for input and one for output in which the sample_rate is the same, and the bit_format is the same, does the number_of_channels change when using more than one serializer?  Because that would affect how I set the bit_clock accordingly.

    Rahul Prabhu said:
    Justyn Bell

    4) If I wanted to set my sample rate higher, I would have to then modify the regular (non HF) clock divider to have smaller divisor.  For instance, if I wanted 176.4kHz audio rate, I would need to change the clock divider to 4, as in

      /* .aclkxctl  = */ 0X000000A3, // should be divisor of 4.

    Yes, changing this should setup the bit clock and frame sync accordingly to the higher frequency. have you checked to confirm the clock has changed correctly to 176KHz. Have you changed any thing on the DAC. Are you recieving at 88.2 and transmitting at 176.4 ? Are there any MCASP errors reported in MCASP_XSTAT and MCASP_RSTAT.

    If the question is if I'm setting aclkxctl and aclkrctl the same values, I am.  As well as ahclkxctl, and ahclkrctl.

    --

    Justyn