Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.117.153.38] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Простая проверка показывает, что если в обработчик wim_open/сlose воткнуть sleep(10000), основной поток зависает на заданные 10 с. В то время как обработчик wim_data основной поток не блокирует. Отладчик показывает выполнение callback, в случае wim_data, в побочном потоке.
Механизм мне неизвестен. Добавлено Цитата А перечислять все 10 000 функций которые можно вызывать и которые нельзя тоже не целесообразно. Отсюда автор просто упомянул то что считает наиболее важным. Логично. Но всё-таки в callback-е возвращается заголовок буфера, и майкрософт мог бы сообщить, что с ним, на их взгляд, можно делать. Перечислить waveinaddbuffer и пр. было бы несложно. midiOutLongMsg они же в описание впихнули, хотя необходимость его использования в callback менее очевидна, чем waveinaddbuffer. Мне так кажется. Цитата Просто это дюже не удобно. Как раз очень удобно. Основной поток не блокируется, и есть куча времени на обработку буферов, при вменяемой их длительности. |
Сообщ.
#17
,
|
|
|
Цитата Prince @ Уберите из callback вывод в консоль. Закоментируйте waveinreset и waveinstop в main. numBufCyr-- в callback при завершении записи перенесите в конец блока. Все сделал, не помогло. Видимо, причина в чем-то другом |
Сообщ.
#18
,
|
|
|
У меня тоже не получилось. Проект прикрепил.
Прикреплённый файлMySound.zip (5,16 Кбайт, скачиваний: 171) |
Сообщ.
#19
,
|
|
|
Если сделать volatile для numBufCyr, то работает и с циклом do. Программа зависает при включении waveInReset, почему - не понятно.
|
Сообщ.
#20
,
|
|
|
Все заработало, видимо, был сбой
|
Сообщ.
#21
,
|
|
|
Цитата Программа зависает при включении waveInReset, почему - не понятно. Ещё раз проверил. После waveinreset виснет waveinunprepareheader в сallback. Варианты: 1. не использовать waveinreset, подождать, пока все буферы будут заполнены и уничтожены в callback. 2. при использовании waveinreset, вынести waveinunprepareheader из callback в основной поток. Во втором случае могут быть тоже несколько вариантов. Самый простой, наверное - это хранить массив headers. И после того, как цикл по numBufCyr завершится, выполнить в цикле unpreapre/free/free для всех элементов headers. После waveinreset, дополнительный поток, в котором обрабатывается очередь сообщений wim_data - уничтожается. Получается, дедлок наступает...когда waveinreset("кто-то" другой после выполнения waveinreset) собирается уничтожить поток, ожидая, когда очистится очередь сообщений потока (?), в то время как в нём происходит вызов waveinunprepare...в общем, нельзя вызывать waveinunprepareheader внутри callback после waveinreset. |
Сообщ.
#22
,
|
|
|
А вы проверяли c volatile numBufCyr?
|
Сообщ.
#23
,
|
|
|
Я проверял код из первого поста, компилил в wxDev-C++. Также повторил в delphi.
Работает без нареканий. Уже говорил, waveinreset и waveinstop в таком контексте лишние. Поскольку все буферы ко времени вызова фунций уже уничтожены, функции фактически ничего не делают(полезного). Работает и с waveinreset/stop и без. В общем, программа не виснет. Как исходный вариант, так и допиленый. Если поставить waveinreset перед циклом while(numBufCyr != 0)(там вызов waveinreset имеет смысл: не нужно ожидать, пока будут записаны все буферы в очереди) - см. выше, сообщение #21. Цитата А вы проверяли c volatile numBufCyr? Работает и так и эдак. А, да, winXP. |
Сообщ.
#24
,
|
|
|
Спасибо за объяснения, очень полезно.
|
Сообщ.
#25
,
|
|
|
Так у вас программа виснет или нет?
Win7/8/.. ? |
Сообщ.
#26
,
|
|
|
В Windows 7 и 8 я по сравнению с исходным текстом (в 1 сообщении) сделал volatile для nunBufCyr, больше ничего не менял. Программа не виснет. Посоветовали это решение в теме Почему в релиз-версии программа зависает?
|