Ответ 1
Я предполагаю, что вы прочитали и поняли этот раздел linux-journal. Вы также можете обнаружить, что этот блог разъясняет вещи в отношении выбора размера периода (или фрагмента в блоге) в контексте ALSA. Цитировать:
Вы не должны злоупотреблять логикой фрагментов звуковых устройств. Это похоже на это:
Задержка определяется размером буфера.
Интервал пробуждения определяется размером фрагмента.Уровень заполнения буфера будет колебаться между "полным буфером" и "полным буфер минус 1x размер фрагмента минус время ожидания планирования ОС". настройка меньшие размеры фрагментов увеличат нагрузку на процессор и уменьшат батарею время, когда вы вынуждаете процессор просыпаться чаще. OTOH увеличивается выйдите из безопасности, так как вы ранее заполняете буфер воспроизведения. Выбор размер фрагмента - это то, что вам нужно сделать, балансируя ваши потребности между потреблением энергии и безопасностью отсева. С современными процессоры и хороший планировщик ОС, такой как Linux, устанавливающий размер фрагмента на все, кроме половины размера буфера, не имеют смысл.
... (О, ALSA использует термин "период" для того, что я называю "фрагментом", выше. Это синоним)
Итак, как правило, вы должны установить period
в 2 (как это было сделано в howto, на который вы ссылались). Тогда periodsize * period
- ваш общий размер буфера в байтах. Наконец, latency - это задержка, вызванная буферизацией этого множества выборок, и ее можно вычислить, разделив размер буфера на скорость, с которой воспроизводятся образцы (т.е. согласно формуле latency = periodsize * periods / (rate * bytes_per_frame)
в комментариях кода).
Например, параметры из howto:
- period = 2
- periodize = 8192 bytes
- rate = 44100 Гц
- 16 бит стереозвука (4 байта на кадр)
соответствуют суммарному размеру буфера period * periodsize = 2 * 8192 = 16384
байтов и задержке 16384/(44100 * 4) ~ 0,093` секунд.
Обратите внимание, что ваше оборудование может иметь некоторые ограничения по размеру для поддерживаемого размера периода (см. этот справочник по устранению неполадок)