LINUX.ORG.RU

Вывод дочернего процесса, можно ли притормозить?

 , ,


0

1

Вывод дочернего процесса, можно ли притормозить?

Суть в следующем: 1. если в командной строке я запускаю: madplay -R 16000 -1 -o raw:/dev/stdout fileName.mp3 | aplay -r 16000 -f S16_LE -t raw -c 1 то в htop я вижу обе задачи на протяжении всего проигрывания файла, используемая ими память на протяжении всего проигрывания не растет. Т.е. madplay выдает данные порциями?

2. если я запускаю из своей программы дочерний процесс «madplay -R 16000 -1 -o raw:/dev/stdout fileName.mp3» и ловлю его вывод, то madplay быстренько отрабатывает декодирование файла полностью, и завершается. Как можно запустить дочерний процесс, чтоб его вывод был тоже порциями как в первом случае с aplay? Т.е. как его «притормаживать» его вывод? Пишу на Qt, но важен сам принцип понять.


Ответ на: комментарий от t184256

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

deep-purple ★★★★★
()

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

deep-purple ★★★★★
()

Эти процессы общаются через пайп в обоих случаях. Если из пайпа не читать, то он заполнится в ядре ос и оно усыпит пишущего.

Ты скорее всего юзаешь какой-нибудь класс для запуска madplay, и он вычитывает сразу всё.

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

Да, не слать сигналы. Подпишись на readyReadStandardOutput (или waitForReadyRead) и читай понемногу readData(buf, len), если решил, что пора. Если они там не намудрили, то будет как в 1.

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

Хотя нет, readData там протектед, в общем найди способ читать не readAllData, а кусками по len байт. Подсказал бы как, но лень ковыряться в этой куче оопнутой шелухи.

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

даже если я вообще ничего не буду читать, то madplay быстро отрабатывает, а в htop вижу как память моего процесса растет, и весь его вывод после завершения доступен для чтения, видимо QProcess сам все в буфер вычитывает.

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

пробовал, абсолютно также всё

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

qprocess вычитывает все сразу, его не остановить
придется решать задачу иначе

x905 ★★★★★
()

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

Хотя, имея дела с кутэ в прошлом, мне и самому слабо верится.

anonymous
()

Все тривиально: с pipe связан буффер фиксированного размера (64 кб, если верить man 7 pipe). Вызовы read/write у читающей/пишущей стороны блокируются при опустошении/переполнении этого буфера. Поэтому aplay, который читает данные со скоростью воспроизведения непроизвольно «притормаживает» декодер, а когда ты читаешь на максимальной скорости, декодер разгоняется на полную катушку.

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