Очередь / обмен событиями между потоками аудио / графического приложения Linux в реальном времени в C - PullRequest
1 голос
/ 13 декабря 2011

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

Яработает над аудио / графическим приложением реального времени в C для Linux (Ubuntu), которое использует графику OpenGL и SDL, аудио ALSA (MIDI), pthread-файлы POSIX и пользовательские библиотеки для периферийного оборудования.В настоящее время существует основной поток и поток для связи с периферийными устройствами.Основной поток объединяет основной цикл рисования графики с кодом, который управляет записью / воспроизведением аудио (или, точнее, MIDI-событиями, настроенными для циклической записи / воспроизведения).

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

Аудиопоток должен быть строго синхронизирован, чтобы запись / воспроизведение былинепротиворечивый, и он должен получать события триггера от потока периферийного обработчика (и обратите внимание, что может быть более одного периферийного потока, генерирующего события), но не ждать их достаточно долго, чтобы на синхронизацию воспроизведения вообще влияли.События триггера, отправленные периферийным потоком (ами), должны быть синхронизированы с аудиопотоком, чтобы когда пользователь запускает воспроизведение / запись ноты, он воспроизводился в нужное время (т. Е. Немедленно, при воспроизведении ноты или записи).в правильное положение в цикле записи).

Аудиопоток отправляет события 'draw' в графический поток (который, я думаю, останется основным потоком программы), и графический поток должен рисовать их как можно скорее, чтобы графические события выглядели синхронизированными ссобытия воспроизведения аудио - хотя графический поток не должен быть так строго синхронизирован, как аудио поток.

Надеюсь, это достаточно ясно, чтобы люди могли предложить, что я должен попробовать.Я не слишком знаком с алгоритмами очередей, блокировками, блокировками и мьютексами и т. Д., Но я понимаю основные понятия, поэтому, если кто-нибудь может подсказать, какие алгоритмы очереди или обмена сообщениями мне следует рассмотреть, и дать ссылку на любые примеры / реализации в C, это было бы прекрасно.Большое спасибо!

1 Ответ

0 голосов
/ 16 декабря 2011

Я бы посмотрел на zeromq .Это действительно делает большую работу по упрощению многих из этих концепций для вас.По сути, это магический транспортный уровень, который стоит в очереди и может быть организован в различных топологиях по различным протоколам (IPC, TCP и т. Д.).Он также имеет отличную документацию и работает в Windows и Linux.Существует клиентская библиотека на любом языке, который имеет значение.

Мне нравится думать о ней как о сокете в форме дюймового червя.

...