Проблемы с синхронизацией Beagle Bone Black Audio Cape rev B

В основном звуковой плащ работает. За исключением одного странного явления, которое сбивает меня с толку. Я попытаюсь объяснить.

Когда я проигрываю файл .wav, например, Speaker-Test -t vaw -> если повезет, я слышу Передний левый - Передний правый, как и ожидалось. Но на 9 из 10 я слышу белый шум со звуком спереди слева спереди справа очень слабо на фоне или в другое время звук просто искажается. То же самое происходит, когда я играю файл с помощью aplay или mplayer.

Поэтому, когда мне везет, или время синхронизировано с системными часами, я слышу звук четко, если не синхронизировано, это может быть белый шум или искаженное воспроизведение.

Я много гуглил и не нашел решения. Так что я надеюсь, что кто-то из вас, ребята, знает, что здесь происходит. Это должно быть что-то низкого уровня.

Я новичок в этом вопросе, но согласно этому: Устранение неполадок со звуком в Linux все швы работают нормально.

Вот мои системные параметры и настройки: root@beaglebone:~# lsb_release -a Идентификатор дистрибьютора: Angstrom Описание: Angstrom GNU/Linux v2012.12 (Core edition) Выпуск: v2012.12 Кодовое имя: Core edition

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

Устройство воспроизведения установлено по умолчанию. Параметры потока: 48 000 Гц, S16_LE, 1 канал. WAV-файл(ы). Скорость установлена ​​на 48 000 Гц (запрошенная 48 000 Гц). 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 АУДИО: 44100 Гц, 2 канала, s16le, 1411,2 кбит/100,00% (соотношение: 176400 ->176400) Выбранный аудиокодек: [pcm] afm: pcm (несжатый PCM)

================================================== ============[edit] AO: [alsa] 44100Hz 2ch s16le (2 байта на образец) Видео: нет видео Начало воспроизведения... A: 1,6 (01,6) из 15,9 (15,8) 0,3 %

MPlayer прерван сигналом 2 в модуле: неизвестно

Выход... (Выйти)


beagleboneblack
person Rowdy Tuinhout    schedule 13.09.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я могу пролить свет на то, что вызывает артефакты, которые вы испытываете. Мне жаль, что у меня пока нет контрмеры - я борюсь с той же проблемой. Вы довольно точно описываете ощутимые последствия.

Звуковые данные передаются от системы ARM на чипе к аудиокодеку на звуковом плаще с использованием I2S. I2S — это последовательный протокол, он отправляет по одному биту за раз, начиная каждую выборку со старшего бита, а затем отправляя все биты до самого младшего бита. После отправки младшего значащего бита одной выборки отправляется старший значащий бит выборки на следующем аудиоканале. Чтобы иметь возможность интерпретировать битовый поток, принимающий аудиокодек должен знать, когда новый звуковой образец начинается со своего старшего бита, а также, к какому каналу принадлежит каждый звуковой образец. Для этой цели сигнал «Выбор слова» (WS) является частью I2S и изменяет свое значение, чтобы указать начало звукового образца, а также идентифицирует канал, см. эта временная диаграмма I2S для лучшего понимания концепции.

То, что мы с вами воспринимаем на наших не совсем рабочих звуковых накидках, можно полностью объяснить тем, что битовый поток интерпретируется аудиокодеком не в ногу:

Когда вы слышите громкий шум и слабый целевой сигнал на фоне, тогда один или несколько младших битов предыдущего сэмпла интерпретируются как старшие значащие биты текущего семпла. Чем больше битов сдвинуто, тем мягче целевой сигнал, пока вы не заметите шум только тогда, когда (это предположение!) сдвинуты примерно 4 бита.

Когда сдвиг происходит в другом направлении, т. е. старший бит текущего сэмпла интерпретируется как младший бит предыдущего семпла, тогда то, что вы слышите, будет звучать правильно для мягких частей сигнала, т. е. когда старший бит фактически не используется (это упрощение, см. ниже). Для более громких частей сигнала, например. ударов барабана, вы воспримете отсутствующий самый значащий бит как искажение. Конечно, искажение усугубляется и начинается с более мягких уровней по мере сдвига большего количества битов в этом направлении.

В приведенном выше абзаце старший значащий бит будет меняться в зависимости от знака данных, поэтому утверждение о том, что он фактически не используется, допустимо только в той мере, в какой старший значащий бит будет иметь то же значение, что и следующий старший значащий бит для тихих звуков. См. Дополнение до двух для ознакомления с представлением отрицательных целых чисел в компьютерах. .

Я не уверен, где происходит коррупция. Возможно, сигнал WS неправильно интерпретируется аудиокодеком на мысе, или сигнал WS неправильно отправляется системой ARM System-on-Chip, или сдвиг битов может произойти уже внутри процессора ARM, например. в драйвере Alsa.

person Ludwig Schulze    schedule 25.11.2014