LINUX.ORG.RU

QAudioOutput и паузы при воспроизведении

 ,


0

3

Доброго дня! Есть задача получения блоков аудиоданных из стороннего приложения (например, RTP-пакеты по UDP, фрагменты raw-файлов) и выдача после необходимых преобразований на аудио-выход в реальном времени. Всё это часть приложения, написанного на Qt, поэтому данный функционал тоже решил написать с помощью Qt (ver 5.7.0). Столкнулся с тем, что воспроизведение идет с паузами переходе одного блока QBuffer к другому. Пробовал предварительное накопление N блоков в очереди, циклический буфер, даже просто считывание файла блоками в while. Создалось впечатление, что QAudioOutput заточен под проигрывание только «завершенного» монолитного блока данных, без подбрасывания дровишек в реалтайме. В интернетах кто-то тоже не смог решить эту проблему, у кого-то якобы получалось. Если есть примеры успешного использования QAudioOutput в подобных задачах, прошу направить на путь истинный).


По теме не посоветую, но когда мне пришлось писать работу с видеопотоком нестандартного формата, я посмотрел в сторону QtMultimedia в части «как подлезть к нему под капот со своим форматом», оценил, насколько там всё глубоко инкапсулировано, плюнул и обошёлся без него, благо формат был простой. При том, что всё остальное было написано на Qt, да.

На истину в последней инстанции не претендую, возможно, был неправ. Могу ещё добавить, что мне в той же работе пришлось отказаться от QImage в качестве смотрелки JPEG-ов, поскольку он может упасть, если ему на вход подать битые данные. Если и QtMultimedia написан так же, то меня это точно не устраивает, мне нужно не падение, а пропуск некорректных данных.

P.S. Нет, багрепорт не написал — надо ещё проверять, повторяется ли ошибка в последней версии Qt. Возможно, как-нибудь напишу (и ещё неизвестно, сочтут ли это кутешники багом, данные-то действительно битые).

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Ну да, QtMM до сих пор не айс, что уже говорить про v5.7.x. Хотя, под виндой использовали его как то для записи и воспроизведения потокового WAVE аудио, принимаемого с УАРТ. Вроде было все норм. Может ты до делаешь не так, см. там примеры есть именно с непрерывным воспроизведением синусойды.

Ну а по хорошему, если под Линукс, то сам сделай враппер к гстримеру и юзай его без QtMM. Или тупо свой плагин к QtMM сваргань, если не хочешь менять АПИ.

kuzulis ★★
()
Ответ на: комментарий от kuzulis

Может ты до делаешь не так, см. там примеры есть именно с непрерывным воспроизведением синусойды.

Это, наверное, ТСу, а не мне. :)

hobbit ★★★★★
()
Ответ на: комментарий от kuzulis

Да, меня как раз WAVE и интересует. Гляну, спасибо всем за отклик

Putnik
() автор топика

В интернетах кто-то тоже не смог решить эту проблему, у кого-то якобы получалось

туда и обратитесь к тем у кого получалось

anonymous
()
Ответ на: комментарий от anonymous

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

Putnik
() автор топика
Ответ на: комментарий от Putnik

как же не переживать
пришел троль с темой - «я все изучил, ничего не подходит, дайте еще»
с такой формулировкой, вас нужно послать изучать дальше

anonymous
()

считывание файла блоками в while

Как часто и насколько быстро/много?

Есть ли у аутпута метод для проверки насколько забит его буфер? Узнать позицию в буфере?

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

Копнул в сторону варианта для винды через winmm. Действительно, выяснилось, что пишу быстрее, чем audio вычитывает. Но это уже совсем другая история) Спасибо за наводку.

Putnik
() автор топика
Ответ на: комментарий от Putnik

Действительно, выяснилось, что пишу быстрее, чем audio вычитывает

Ну дык — явно кольцевой буфер, явно писатель должен следить за позицией читателя чтобы не затереть то, что ещё не прочитано. И наоборот — читатель должен следить за позицией писателя, чтобы не начать читать то, что было записано гораздо раньше. Оно как бы предполагает вот это всё.

deep-purple ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.