Linux: синхронизация во время записи / воспроизведения звука

Question

У меня есть более общий вопрос, касающийся синхронизации в стандартной ОС Linux, связанной с воспроизведением звука и получением данных через последовательный порт.

В данный момент я читаю сигнал PCM, поступающий через мост USB-Serial (pl2303), который записывается, кодируется и отправляется с FPGA.

Теперь мне нужно создать «пики» в известной позиции в записанном звуковом потоке и планировать воспроизведение звукового файла с того же устройства, которое записывает в известный момент. Пик должен начинаться и останавливаться в окнах максимум 50 мс, его длина может быть ~ 200 мс ...

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

• Мост USB-to-Serial собирает ~ 20 байтов со стороны последовательного порта перед отправкой их на сторону USB (при скорости 230400 Бод это дает ~ 1 мс)
• Если я вызываю «sleep 1; mpg123 $ MP3FILE` &» непосредственно перед моим программным обеспечением для записи, ядро ​​Linux будет планировать их по-разному (может быть, это вызывает несколько 10 мс, в зависимости от загрузки системы?)
• Возможно, звуковая карта / драйвер добавит еще немного неизвестных задержек ...
• Будут ли уловки типа "nice" или "sched_setscheduler" в моем случае?
• Я мог бы создать дополнительный поток внутри моей программы записи, который воспроизводит звук. При этом время может быть более точным, но у меня много работы ...

Большое спасибо.

В любом случае, я попробую, но я ищу некоторые дополнительные знания, чтобы лучше понять и решить мои будущие проблемы.

Answer 1

это снова я ... После одной беспокойной ночи я решил свои странные проблемы с синхронизацией ... Мое первое редактирование не совсем корректно, так как то, что я опубликовал, не воспроизводилось на 100% После выполнения еще нескольких тестов, я могу получить следующий график, показывающий точность синхронизации:

Результаты анализа http://mega2000.de/~mzenzes/pics4web/2010-05-28_13-37-08_timingexperiment.png

Я пробовал два разных ядра Ubuntu : 2.6.32-21-generic и 2.6.32-10-rt

Я пытался добиться RT-планирования: sudo chrt --fifo 99 ./experimenter.sh

И я попытался изменить параметры энергосбережения: echo {performance,conservative} | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Это привело к 8 различным тестам с 50 прогонами каждый. Вот цифры:

                                   mean(peakPos)  std(peakPos) 
rt-kernel-fifo99-ondemand          0.97           0.0212 
rt-kernel-fifo99-performance       0.99           0.0040 
rt-kernel-ondemand                 0.91           0.1423 
rt-kernel-performance              0.96           0.0078 
standard-kernel-fifo99-ondemand    0.68           0.0177 
standard-kernel-fifo99-performance 0.72           0.0142 
standard-kernel-ondemand           0.69           0.0749 
standard-kernel-performance        0.69           0.0147

Answer 2

Я не уверен на 100%, но я полагаю, что ваше ядро ​​необходимо перестроить, чтобы планировщик уменьшил время задержки при переключении задач в многозадачном режиме, в ядрах серии 2.6.x есть возможность сделать Ядро более гладкое, сделав его упреждаемым.

• Перейти к типу и характеристикам процессора
• Модель вытеснения
• Выберите ядро ​​Preemptible (рабочий стол с низкой задержкой)

Это должно упростить синхронизацию и сделать звуки более плавными в результате уменьшения дрожания.

Попробуйте и перекомпилируйте ядро ​​снова. Конечно, существует множество патчей для ядра, которые сокращают временные интервалы для каждого переключателя задач, чтобы сделать его еще более плавным, пробег может варьироваться в зависимости от:

1. Скорость процессора - какой процессор используется?
2. Память - сколько оперативки?
3. Дисковый ввод / вывод - чем быстрее, тем лучше

Использование этих трех факторов вместе повлияет на планировщик и функции многозадачности. Чем меньше латентность, тем она более мелкозернистая.

Кстати, есть специальный дистрибутив linux, предназначенный для захвата звука в реальном времени, я не могу вспомнить его название, ядро ​​в этом дистрибутиве было сильно исправлено, чтобы сделать звук очень плавным.