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.

[参考译文] CC2564C:使用 SBC/SARC 将48kHz 音频采样转换为44.1kHz 音频采样

Guru**** 2756835 points

Other Parts Discussed in Thread: CC2564C

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/826740/cc2564c-using-sbc-sarc-to-convert-48khz-audio-sampling-to-44-1khz-audio-sampling

器件型号:CC2564C

我们使用 CC2564C 和源应用将音频传输到蓝牙耳机。 我们尝试通过 I2S 向 TI CC2564C 发送48kHz 采样 PCM 音频、但在传输到耳机之前、请 TI 将音频重新采样到44.1kHz。 根据有关 SBC 输入采样频率的 TI 文档、这是可能的。 ' PCM 输入至 SBC 编码器的采样频率。 请注意、当此参数与 PCM 输入采样频率不同时、SARC 用于采样率转换。" 下面的配置会导致耳机上的音频波涛汹涌、我们认为我们必须错过配置步骤。 我们已使用 Ellisys 蓝牙监听器捕获了一条空气轨迹、该监听器显示耳机的44.1kHz 采样率、但音频质量很不连贯。 将下面代码中的所有参考从44.1k 更改为48k 可解决音频问题、但出于射频性能原因、我们更倾向于发送44.1kHz 采样音频。 请提供建议。

http://processors.wiki.ti.com/index.php/CC256x_VS_HCI_Commands#HCI_VS_A3DP_Codec_Configuration_.280xFD8E.29

我们支持的格式列表仅包含44.1k 数据速率。








静态 BTPSCONST AUD_Stream_Format_t AudioSRCSupportedFormats[]={ 
{44100、2、0}
};

在 ReconfigureA3DPStream 中、PCM/I2S 数据速率硬编码为48kHz。 
VS_PCM_Codec_Config_Slave_I2S (Bluetooth_GetStackID ()、I2S_CLK_FREQ_IN_FS_48kHz、48000);

在 ReconfigureA3DPStream 中、我们将 PCM 速率设置为48kHz、但将 SBC 速率设置为44.1kHz 
int AudioFormat =(AVRP_AUDIO_FORMAT_SBC_SAMPLE_RATE 44K1 | AVRP_AUDIO_FORMAT_PCM_SAMPLE_RAM_48K); 
AudioFormat |= AVRP_AUDIO_FORMAT_SBC_MODE_JOING_STEREO; 
int SBCFormat =(AVRP_SBC_FORMAT_allocation_METHOD_ALOUVIND | AVRP_SBC_FORMAT_BLOCK_LENGTH_16); 
VS_A3DP_Codec_Configuration (Bluetooth_GetStackID ()、AudioFormat、SBCFormat、42); 
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    此问题是否已解决?

    我知道、出于射频性能原因、您可能希望将 A2DP 采样率保持在44.1kHz。 在这种情况下、您可以在 PCM 接口上使用相同的44.1kHz 设置吗? 执行采样率转换时、音频性能将不如没有转换的情况(即为相同设置配置的 A2DP 和 PCM 接口)。

    此致、

    Vihang

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、Vihang、感谢大家的跟进。 不、我们还没有解决这个问题的方法。

    遗憾的是、我们无法将 PCM 接口重新配置为44.1kHz。 我们使用一个 I2S 位时钟来驱动多个 I2S 器件。 更改所有器件的 PCM 总线配置意味着我们一侧进行了大量重新设计、我们目前还没有准备好进行这种重新设计。

    也许您可以帮助我们澄清一些问题。 我们注意到、如果 SRCAudioSupportedFormats 更改为48kHz、但上述所有其他代码保持不变、我们似乎在耳机中获得了高质量的音频。 从 Ellisys 的空气迹线可以看到、我们以44.1kHz 的频率发送数据帧、尽管 AVDTP 媒体数据包确实报告了不匹配警告。 由于 AUD_Initialize 使用 AudioSRCSupportedFormats、因此在我看来、可能还会发生其他影响音频质量的事情。

    静态 BTPSCONST AUD_Stream_Format_t AudioSRCSupportedFormats[]={ 
    {48000、2、0}
    };

    尽管我们收到此不匹配警告、但音频数据速率似乎为44.1kHz、并且音频质量是可以接受的(无噼啪或喀哒声)。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Vihang、您好、只需签入即可查看您是否对此问题有任何更新。 谢谢!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Max:

    很抱歉、我一直在尝试重新配置我们的 A3DPDemo_SRC 应用、以复制您的 SARC 整体使用案例。 我将在本周结束时分享我的调查结果。

    此致、

    Vihang

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的、非常好、谢谢 Vihang。 期待您的调查结果。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Max:

    在运行采样率为48kHz 至44.1kHz 的 A3DP 源时、我能够复制毛刺脉冲音频。 从固件日志中、我可以看到一些与 A3DP 缓冲区溢出相关的问题、这些问题直接导致遥控器(A3DP 接收器)上的干扰。  

    我需要做一些进一步的测试、以确定根本原因和可能的解决方案。 我将不断发布有关此问题的更新、因为我将了解有关此问题的更多详细信息。

    此致、

    Vihang

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢 Vihang 的更新、很高兴您能够重现我们看到的问题。 期待您的下一次更新! 谢谢!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Max:

    深入探究 CC2564C 固件中的 A3DP 实现后、可以清楚地看到、您所遇到的是采样率转换器的限制。 由于48kHz (PCM 采样率)和44.1kHz (SBC 采样率)是彼此之间的直接乘法器、因此在当前实施中、上采样或下采样中的周期性干扰是不可避免的。 当前实施方案几乎可以去除(忽略)额外的样本、从而获得 SBC 所需的采样率。 当降采样的音频被发送到 A2DP 接收器时、这些降采样直接导致音频出现波动。 我看到它的方式是、这是 CC2564C 固件中当前 A3DP 实现的限制、而不是应用层配置中缺少的内容。

    因此、为了避免这种限制、我建议不要将采样率转换器(对 PCM 和 SBC 使用相同的采样率)用于 A3DP。 我从您的描述中了解到您无法更改 PCM 参数。 因此、对于 SBC 和 A2DP 配置文件、我建议使用48kHz 采样率。 根据 A2DP 配置文件规范、所有接收器件都必须支持44.1kHz 和48kHz 采样率。 因此互操作性不应成为您的问题。 如上所述、两种设置之间的帧大小会稍有不同、从而导致帧传输中基带层的时序不同。 最终、您必须根据自己的要求权衡这两种场景的利弊。

    我承认这不是你希望得到的答案。 但是、我认为这些结果解决了本主题中的开放式问题。 因此、我要将此帖子标记为已解决。 如果您有后续问题、请随时在下方发帖。

    此致、

    Vihang

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    谢谢 Vihang。 显然不是我们希望得到的答案,而是感谢我们找到了这个问题的最根本。