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

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

1 голос
/ 21 мая 2010

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

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

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

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

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

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

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

Ответы [ 2 ]

0 голосов
/ 28 мая 2010

это снова я ... После одной беспокойной ночи я решил свои странные проблемы с синхронизацией ... Мое первое редактирование не совсем корректно, так как то, что я опубликовал, не воспроизводилось на 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
0 голосов
/ 21 мая 2010

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

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

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

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

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

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

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

...