[参考译文] CC2564MODA：A2DP 数据格式和解码时序

您好 Tashiro、

Tiva 和您的外部 DAC 之间的 I2S 捕捉吗？

您使用的是辅助 A2DP 还是非辅助 A2DP？  

借助无辅助 A2DP、Tiva 将需要对音频流进行解码、而不是依赖 CC2564的硬件。 根据您在系统上运行的其他任务、这可能会导致瓶颈、导致音频不会实时解码、从而导致 SSI 接口无法及时获取数据。 如果您使用的是 RTOS、我建议检查正在运行的线程、以确保解码任务的优先级正确。

此致、

Michael

您好、Michael、

[引用用户="Michael Reymond "]

Tiva 和您的外部 DAC 之间的 I2S 捕捉吗？

[/报价]

是的。 I2S 捕获位于 Tiva 和外部 DAC 之间。


[引用用户="Michael Reymond "]

您使用的是辅助 A2DP 还是非辅助 A2DP？  

[/报价]

使用无辅助 A2DP。

[引用用户="Michael Reymond "]

借助无辅助 A2DP、Tiva 将需要对音频流进行解码、而不是依赖 CC2564的硬件。 根据您在系统上运行的其他任务、这可能会导致瓶颈、导致音频不会实时解码、从而导致 SSI 接口无法及时获取数据。 如果您使用的是 RTOS、我建议检查正在运行的线程、以确保解码任务的优先级正确。

[/报价]

代码是非 RTOS 版本。
在代码中、除了以下任务之外、没有其他任务正在运行：
- PlaybackThread()=>从 CC2564接收新的音频数据时调用
- SoundIntHandler()=>被调用以向 SSI 发送新数据
- TimerIntHandler()=>计时器节拍
- ConsoleIntHandler()=> PC 之间的 UART (在音频回放期间不使用)
- Tiva 和 CC2564之间的 Hcitr_UARTIntHandler ()=> UART

在从 CC2564接收新的音频数据之前、Tiva 似乎不执行任何操作。
(ProcessAudioData 完成后、即调用 PlaybackThread)
因此、我认为其他任务不会阻止音频。 仅来自 CC2564的音频数据接收时序似乎太慢。

音频数据参数如下(根据控制台输出)：
缓冲器上限：4608
缓冲器下限：3072
帧长度    ：119
位池        :53.
比特率        ：327993
缓冲器长度  ：128
帧/GAVD    ：16.

我认为所有 A2DP SNK 都应该支持这一点。

谢谢、此致、
田志郎一郎

您好 Tashiro、

感谢您提供信息。 我将使用 DK-TM4C129X + CC2564MODA 并查看是否可以重现相同的结果。

此致、

Michael

您好、Michael、

您是否有可连接到 Tiva 的外部 DAC？
否则、您无法按原样运行 A2DP 演示。
在这种情况下、请在 A2DP 演示中替换以下两个源、以便绕过所有 DAC 和 SSI 相关代码。
(不播放音乐、代码只会重复接收数据并对其解码。)
e2e.ti.com/.../4073.dac.c

e2e.ti.com/.../2335.sound_5F00_ssi.c
您仍然可以看到以下线程/事件之间的时序、并看到 ProcessAudioData 速度不够快。
- sbc_decode()
- ProcessAioData()
-等等

谢谢、此致、
田志郎一郎

您好、Michael、

以前的 Excel 中有一个错误信息。
由于传入的音频数据是44.1kHz 立体声、因此 I2S 格式也配置为44.1kHz (而非48kHz)。
很抱歉、这可能会导致您一侧混淆。
请在下面找到经过更正的更新的 Excel。
e2e.ti.com/.../A2DP-SSI-stop_5F00_Oct17.xlsx

基本问题是相同的。
对于44.1kHz 音频回放，ProcessAudioData()需要~23msec 间隔，但它不需要。

谢谢、此致、
田志郎一郎

您好 Tashiro、

感谢您提供 dac.c 和 sound_ssi.c 我没有 Tiva Bluetopia SDK 支持的确切编解码器、因此我需要修改它以使用用于 MSP432 Bluetopia SDK 的 CC3200AUDBOOST。

所以、我在灌电流模式下运行代码并连接了我的手机、到目前为止、很难判断我是否遇到了您所看到的相同问题。 虽然我已经实现了您在采集中看起来具有的 LED 切换、但我无法轻松判断 I2S 是否已停止。 您使用什么编解码器来接收 I2S 音频？

此外、您的客户不能使用 A3DP 的原因是否有？ 假设瓶颈在 playbackThread()中，使用 A3DP 将消除由于音频解码速度不够快而导致 I2S 音频停顿的可能性。

此致、
Michael

您好、Michael、

[引用用户="Michael Reymond "]

所以、我在灌电流模式下运行代码并连接了我的手机、到目前为止、很难判断我是否遇到了您所看到的相同问题。 虽然我已经实现了您在采集中看起来具有的 LED 切换、但我无法轻松判断 I2S 是否已停止。 您使用什么编解码器来接收 I2S 音频？

[/报价]

您能否使用示波器监控 I2S 信号？
如果问题发生、BCLK 将停止、以便轻松检测到。
或者，您可以像客户一样在 ProcessAudioData()的开头切换 GPIO。
理想情况下、对于44.1kHz 立体声、GPIO 脉冲应~21ms。

我将通过单独的电子邮件发送客户使用的编解码器

[引用用户="Michael Reymond "]

此外、您的客户不能使用 A3DP 的原因是否有？ 假设瓶颈在 playbackThread()中，使用 A3DP 将消除由于音频解码速度不够快而导致 I2S 音频停顿的可能性。

[/报价]

辅助模式和 BLE 使用 CC2564B 内的相同硬件资源。
客户希望在播放音乐时使用 BLE (SPPLE)、因此无法使用 A3DP。 A2DP 只是一个选项。




我不认为 playbackThread()是瓶颈，因为一旦收到新数据，该线程就会运行，并且数据解码在收到下一个数据之前完成。
问题是、数据不会定期以~21ms 的间隔出现。
在下面的波形中、以超过27ms 的间隔为例、它持续4次。 则会导致解码数据短缺。



我发现 AudioDecoder.c 中有采样率调整机制、但它似乎提高了播放速度。
是否可以根据缓冲区内的解码数据降低回放速度？

/*检查 SBC 缓冲器的状态以查看我们是否需要调整*/
/*播放速度。 *
if ((！PlaybackContext.SampleRateAdjustment)&&(PlaybackContext.SBCULD >= PlaybackContext.BufferHighLimit))
｛
/*我们有太多样本，因此我们将增加播放*/
/*释放存储的速度。 *
PlaybackContext.SampleRateAdjustment = SAMPLE_RATE_ADJUST_VALUE；

display((("up %d %d\r\n"，(unsigned long) PlaybackContext .CurrentSampleRate，PlaybackContext .SBCUsed)；
}

if ((PlaybackContext.SampleRateAdjustment)&&(PlaybackContext.SBCULed <= PlaybackContext.BufferLowLimit))
｛
/*我们有太多样本，因此我们将增加播放*/
/*降低存储的速度。 *
PlaybackContext.SampleRateAdjustment = 0；

显示(("down %d %d\r\n"、(unsigned long) PlaybackContext .CurrentSampleRate、PlaybackContext .SBCUsed)；
｝ 

谢谢、此致、
田志郎一郎

您好 Tashiro、

感谢您对不使用 A3DP 的原因的解释以及您看到的 I2S 行为的注意事项。

我还有几个问题：

1. 您是否使用 SDK 中的 A2DPDemo 而不进行除 SSI 主站更改以外的修改？ 或者、您是否也在 A2DP 代码的同时运行 SPPLE 代码？
2. 您能否提供所做的 SSI 代码更改？ 虽然我没有客户使用的确切编解码器、但我将能够复制您的 SSI 更改并在我的逻辑分析仪上查看 I2S 输出。

此致、

Michael

您好、Michael、

1：
客户仅使用 A2DP 演示、修改最少；
-将单个 SSI 配置为主 SSI
-使用他们的编解码器
目前没有 SPPLE 演示正在运行。

2：
我将获取代码并将其脱机发送。

BTW、当您将编解码器与 A2DP 演示配合使用时、音频数据的接收间隔恰好为21毫秒？
(即 ProcessAudioData()在21ms 内调用一次)

谢谢、此致、
田志郎一郎

您好、Michael、

我对客户项目进行了一些其他测试、并更新了 Excel 工作表。
请参阅下面的其他工作表。
-位池更改
- HCI UART
- ListLock 检查
(ProcessAudioData 产品说明书未更改)
e2e.ti.com/.../A2DP-SSI-stop_5F00_Oct31.xlsx
到目前为止、无法成功避免 BCLK 停止问题。

谢谢、此致、
田志郎一郎

您好 Tashiro、

我现在可以重复您的问题、并将通过您在之前的帖子中提供的备注继续对此进行调查。 我感谢您的耐心、希望能够快速解决这一问题、因为我可以观察到相同的 I2S 行为。

此致、

Michael

您好 Tashiro、

正如我在电子邮件中提到的、我能够重复客户看到的问题。 但是、调试这一过程花费的时间比预期的要长。 尽管如此、我希望尽快解决这一问题、尤其是考虑到您和您的客户在提供调试数据方面持续付出的努力、我感谢您在这个问题上的耐心等待。

此致、

Michael

您好 Tashiro、

正如我在最近的电子邮件中提到的、我仍在调查此问题、并有一些可能的方法、例如使用 Tiva I2S 总线以及编译器优化。 我会随时向您介绍我的最新进展、感谢您的耐心。

此致、

Michael

您好 Tashiro、

我仍然在研究这个问题。 从我上次发布以来、我现在没有更新。

此致、

Michael

Tashiro、

本周、我将查看并在收到更新后尽快返回给您。

BR、

Vince

Tashiro、

如上所述、我将通过电子邮件对此进行跟进。 我将关闭此主题、但在找到解决方案后将发布该解决方案。

BR、

Vince