beagleboneblack - Beagle Bone Black Audio Cape rev B 同步问题

Question

基本上音频披风正在工作。除了一种奇怪的现象让我感到困惑。我会尽力解释。

当我播放 .wav 文件时，例如 speaker-test -t vaw -> 如果幸运的话，我会听到预期的左前 - 右前。但是十分之九，我听到白噪声，音频在背景中左前右前非常微弱，或者在其他时间声音只是失真。当我用 aplay 或 mplayer 播放文件时也会发生同样的情况。

因此，当我很幸运，或者相对于系统时钟的时间同步时，我可以清楚地听到音频，如果不同步，我可能会出现白噪声或播放失真。

我有广泛的谷歌，并没有找到任何解决方案。所以我希望你们中的一个人知道这里发生了什么。它必须是低水平的东西。

我在这件事上是个新手，但据此:Troubleshooting Linux Sound所有接缝都可以正常工作。

这些是我的系统参数和设置:root@beaglebone:~# lsb_release -a 发行商 ID:Angstrom 描述:Angstrom GNU/Linux v2012.12(核心版)发布:v2012.12 代号:核心版

root@beaglebone:~# cat /sys/devices/bone_capemgr*/slots 0: 54:PF---

1: 55:PF--- 
2: 56:P---L CBB-Relay,00A0,Logic_Supply,CBB-Relay
3: 57:PF--- 
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-L Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-AUDI-02
root@beaglebone:~# speaker-test -t wav

扬声器测试 1.0.25

默认播放设备 流参数为 48000Hz、S16_LE、1 channel WAV 文件 速率设置为 48000Hz(请求的 48000Hz) 缓冲区大小范围从 128 到 32768 周期大小范围从 8 到 2048 使用最大缓冲区大小 32768 周期 = 4 已设置period_size = 2048 设置为 buffer_size = 32768

0 - 左前
每个周期的时间 ​​= 0.641097

0 - 左前
root@beaglebone:~# mplayer AxelF.wav MPlayer2 2.0-379-ge3f5043 (C) 2000-2011 MPlayer Team 162 音频和 361 视频编解码器

播放 AxelF.wav。检测到的文件格式:WAV格式(libavformat)[wav@0xb6082780]max_analyze_duration达到[lavf]流0:音频(pcm_s16le)，-aid 0加载字幕。

==================================================== ============[编辑]
强制音频编解码器:mad 打开音频解码器:[pcm] 未压缩的 PCM 音频解码器 AUDIO:44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400) 选择的音频编解码器: [pcm] afm: pcm (未压缩的 PCM)

==================================================== ============[编辑]
AO:[alsa] 44100Hz 2ch s16le(每个样本 2 字节) 视频:无视频 开始播放... A:1.6 (01.6) of 15.9 (15.8) 0.3%

MPlayer 被模块中的信号 2 中断:未知

退出...(退出)

Answer 1

我可以阐明是什么导致了您遇到的伪影。很抱歉，我还没有对策——我正在努力解决同样的问题。您非常准确地描述了可感知的后果。

声音数据使用 I2S 从 ARM 片上系统传输到音频 cape 上的音频编解码器。公共(public)汽车。 I2S 是一种串行协议(protocol)，它一次发送一个位，从最高有效位开始每个样本，然后将所有位发送到最低有效位。在发送一个样本的最低有效位后，将发送下一个音频 channel 上的样本的最高有效位。为了能够解释比特流，接收音频编解码器需要知道新的声音样本何时从其最高有效位开始，以及每个声音样本属于哪个 channel 。为此，“Word Select” (WS) 信号是 I2S 的一部分，它会更改其值以指示声音样本的开始并识别 channel ，请参阅 this I2S timing diagram为了更好地理解这个概念。

您和我对我们不太正常的音频披风的看法可以通过音频编解码器不同步解释的比特流来完全解释:

当您在背景中听到响亮的噪音和柔和的目标信号时，前一个样本的一个或多个最低有效位将被解释为当前样本的最高有效位。移位的位数越多，目标信号就越柔和，直到您可能仅在(这是一个猜测!)移位大约 4 位时才感觉到噪声。

当移位在另一个方向时，即当前样本的最高有效位被解释为前一个样本的最低有效位，那么您听到的信号的软部分听起来是正确的，即当最高有效位是没有实际使用(这是一个简化，见下文)。对于信号的较大部分，例如鼓节拍时，您会将丢失的最重要位视为失真。当然，随着更多位在这个方向上移动，失真会变得更糟，并从更柔和的水平开始。

在上面的段落中，最高有效位会随着数据的符号而变化，因此只有在最高有效位与软声音的下一个最高有效位具有相同值的情况下，没有实际使用它的声明才有效。见 Two's Complement介绍如何在计算机中表示负整数。

我不确定腐败发生在哪里。可能是 Cape 上的音频编解码器没有正确解释 WS 信号，或者 ARM 片上系统没有正确发送 WS 信号，或者位移可能已经在 ARM CPU 内部发生，例如在 Alsa 驱动程序中。