这里https://github.com/espressif/esp-idf/issues/12277提到LE audio的硬件条件是2M PHY, BL618是支持的
如果一定要同时实现LE 音频和 WiFi, 可以试试恒玄bes2600w这个有le audio的实现并且支持wifi, SDK地址:https://github.com/Hi-LinkDuino/RM56
实现无损无线音频不一定要依赖蓝牙, 可以试试海思的hi2821, 使用SLE协议可以达到12Mbps, SDK地址:https://gitee.com/bearpi/bearpi-h2821_pico
O2C14 发表于 2024-7-16 21:00
这里https://github.com/espressif/esp-idf/issues/12277提到LE audio的硬件条件是2M PHY, BL618是支持的
...
他在这里实际上是错误的，LE Audio依赖于等时通道硬件功能（ISO）。
没有设备支持SLE协议，它不能集成到移动设备和计算机中。
O11111 发表于 2024-7-16 16:06
这很酷。 我建议你等到我将来公开发布我的库。
BL618是否支持LE Audio？ 如果是这样，您甚至可以尝试实 ...
讨论已经打开:https://github.com/O2C14/btstack_test/discussions
我将在上面说明实现这个播放器的细节,sink端已经接近完善,接下来要开发source端和音频均衡器
测试l2hcv3编解码,在传输比特率为~1330kbps下的测试
48kS24_1344.wav是指lc3plus在传输比特率为1344kbps下的输出
48kS24,48kS32,和l2hcv3的输出叠在一起了.
我想说的是l2hcv3的编解码能力可能超过了lc3plus,之后我会用白噪音继续测试
l2hcv3没有lhdc那么复杂,编解码库只有210KB,所以我打算逆向这个
厉害厉害
O2C14 发表于 2024-7-26 12:29
测试l2hcv3编解码,在传输比特率为~1330kbps下的测试
48kS24_1344.wav是指lc3plus在传输比特率为1344kbps下 ...
那么，L2HC库被剥离，所以它实际上比LHDC更难进行逆向工程。 而LC3plus HR实际上是在谷歌的liblc3免费许可下提供的。
你可能也想看看aptX Adaptive。新的R4修订版看起来很有希望。
顺便说一句，您可能应该在您的 btstack_test 存储库中为此开启一个讨论。
本帖最后由 O2C14 于 2024-7-26 21:48 编辑
O11111 发表于 2024-7-26 18:51
那么，L2HC库被剥离，所以它实际上比LHDC更难进行逆向工程。 而LC3plus HR实际上是在谷歌的liblc3免费许 ...
L2HC有公开的标准:
只是没有开源的编解码器,虽然L2HCv3与公开标准有一些不同,但是大部分都能对应上
白噪音测试显示L2HCv3在编码48khz/32bit时 传输比特率最高为~2328kbps
aptX Adaptive好像都是用QDSP实现的,难以逆向
O2C14 发表于 2024-7-26 21:15
L2HC有公开的标准:
只是没有开源的编解码器,虽然L2HCv3与公开标准有一些不同,但是大部分都能对应上
白噪音 ...
标准很棒，但似乎并不完整。它总共只有 19 页，包括 A2DP 特定信息。无论如何，它只是一个基于 MDCT 的普通编解码器，绝对没有理由使用它。实际上支持的硬件太少了。
此外，32 位对于音频来说并不是那么有用。
还有针对 Xtensa 和 Kalimba 架构的 aptX Adaptive 实现。
O11111 发表于 2024-7-26 21:52
标准很棒，但似乎并不完整。它总共只有 19 页，包括 A2DP 特定信息。无论如何，它只是一个基于 MDCT 的普 ...
在ADK中我发现了这个
这里面会包含APTX adaptive解码器吗,哪怕只是一部分只要有核心就好.
l2hcv3的解码器快要完成了,只是kiss fft的定点版本的精度不是很好,输出总是与共享库版本有差异
O2C14 发表于 2024-8-14 15:24
在ADK中我发现了这个
这里面会包含APTX adaptive解码器吗,哪怕只是一部分只要有核心就好.
l2hcv3的解码器 ...
似乎只有解码器，所以你可能会尝试对其进行反向工程。 但使用kalsim可能更容易。
而这只是aptX自适应R2.1/R3。 R4不同，我认为现在在R2.1/R3上工作没有多大意义。