KB: Asynchronous Sample Rate Converter (ASRC) & Audio Sink Clock Counter (ASCC) Functionality

[RSL10 - Knowledge Base]


The RSL10 comes equipped with an Audio Sink Clock Counter (ASCC) which allows it to accurately measure the frequency of a clock source relative to its own System Clock, and an Asynchronous Sample Rate Converter (ASRC) which can be used to convert Audio Samples from one sampling rate to another using the clocks’ ratios and interpolation.

How does the ASCC measure the frequency of the incoming clock signal, and how can this information be provided to the ASRC so that it can interpolate the samples at the new requested sampling rate?



To understand the functionality of the ASCC, we must first discuss what each of the values in the image below represent.

AUDIOSINK_CNT - Number of audio clock cycles that have been recorded between two RF/BLE frame pulses. The first and final cycles are recorded at the first rising edge of the audio clock following the rising edge of the RF/BLE frame pulse.

AUDIOSINK_PERIODS_CFG - Number of audio clocks cycles over which the AUDIOSINK_PERIOD_CNT is counted. You can accurately estimate the number of System Clock cycles within a single audio clock cycle by dividing the AUDIOSINK_PERIOD_CNT by the AUDIOSINK_PERIODS_CFG (by increasing this value you can ensure a more accurate estimate of the number of System Clock cycles for each audio clock cycle).

AUDIOSINK_PERIOD_CNT - Number of System Clock cycles that occur during the time it takes for the audio clock to repeat AUDIOSINK_PERIODS_CFG times (i,e., if the AUDIOSINK_PERIODS_CFG is set to 16, the AUDIOSINK_PERIOD_CNT register will hold the number of System Clock cycles that pass during 16 audio clock cycles).

AUDIOSINK_PHASE_CNT - Number of System Clock cycles that occur following the RF/BLE frame pulse rising edge, but before the first audio clock rising edges has occurred.

In order to accurately measure the number of audio clock cycles that occur between two RF/BLE frame pulses (including fractions of an audio clock cycle, not just integer values), the equation shared below can be utilized.

The AUDIOSINK_CNT register will contain the integer value of the number of audio clock cycles that were recorded between RF/BLE frame pulse, but because of the shift in clocks, this value will rarely be a perfect integer and will instead have a fraction component. By keeping track of the AUDIOSINK_PHASE_CNT that followed the first RF/BLE frame pulse ([i-1]) and subtracting the AUDIOSINK_PHASE_CNT that trailed after the second RF/BLE frame pulse ([i]). you can determine the number of System Clock cycles that occurred inside/outside of the two RF/BLE frame pulses.

To turn this extra/missing System Clock count into a fraction of an audio clock cycle, we can divide the value by the number of System Clock cycles that occur within a single audio clock cycle (as explained in the AUDIOSINK_PERIODS_CFG section above). The resulting value is then added to the AUDIOSINK_CNT value to add/remove the fraction component of the count.


Once we have accurately determined the number of audio clock cycles that occur between each RF/BLE frame pulse, we must provide the appropriate ratio to the ASRC configurations so that the interpolation can be done properly. The chart below outlines the ASRC modes that can be selected, the associated ratio ranges, and the formula that must be applied to the ASRC_PHASE_INC register.

It is worth noting that because the AUDIOSINK_CNT value now has a fraction component, we must perform left bit-shifts (on all initial values, not the resulting answer) within the variable calculation to ensure that the decimal values are retained accurately. This can be done safely because the ASRC_PHASE_INC value expects a ratio, meaning whatever is done to the Fsrc or Fsink will be ignored as lone as it is done evenly to both values.

As an example, if you expect to output 160 samples from the ASRC between every RF/BLE frame pulse, you must apply a left bit-shift to all the variables used to calculate the AUDIOSINK_CNT above (Fsrc), as well as applying the same left bit-shift to the value of 160 (Fsink). When you perform the calculations above to determine the AUDIOSINK_PHASE_INC, the left bit-shifts will be dropped, but the fractions will be considered during the computation.

sorry this is not enough description or information

is there an other document?

thx sean


Sections 13.3 & 13.4 in RSL10_hardware_reference.pdf, Sections 9.19 - 9.31 in RSL10_firmware_reference.pdf, this KB post, and one of our sample applications (e.g. remote_mic_rx_coex, remote_mic_tx_coex, remote_mic_tx_raw, remote_mic_rx_raw, remote_mic_trx_coded and custom_protocol_trx) are the only available resources we can provide. The sample code will use all of the firmware functions necessary, as well as implementing the hardware process required.

Please note that the SYS_ASRC_CalcPhaseCnt() function will work if both Source and Sink are exact integer frequencies, but more complex methods (outlined in this KB post) will be needed if the ASCC is measuring the input frequency in terms of BLE Packets (not perfectly aligned with the System Clock). We do not recommend using the Sys_ASRC_CalcPhaseCnt() function if the Source and Sink frequencies are not whole integers. This function will only work well if both the Source and Sink are controlled by the RSL10 (ie. SPI Master Audio Input, AudioClock Output). In most audio streaming cases, this is not the best choice.

Thank you for using our Community Forum.