LINUX.ORG.RU

xanmod... рвет linux-rt в low-latency аудио задачах???

 , , , ,


3

5

Я в шоке…

Годами, буквально годами пытаюсь получить минимальную задержку при обработке аудио на ноутбуке с jack, а теперь и с pipewire.

Платформа - Sandy Bridge, встроенное аудио Realtek ALC272.

Всегда считал нормой для этого ноутбука буфер 48000 Гц / 256 семплов (5,3 мс задержка) (кто в теме то поймет что это). Тут на ЛОРе мне много раз писали что это совсем не круто. Да я и на слух слышу задержку при игре на гитаре. Это все на обычном ядре, дефолтном в дистрибутивах. При меньшем буфере стабильно не работает.

Периодически я решал озаботиться улучшением, первое что советуют везде - использовать linux_rt вместо обычного ядра. Это немного улучшало ситуацию, можно было получить вдвое меньшую задержку 48000/128 (2,7 мс). Но не очень стабильно. Это - тоже совсем не айс!

И вот, чисто случайно, без объявления войны, я ставлю NixOS и в нем ядро xanmod 5.14. Происходит какая-то мистика!

Я выставляю 48000 / 64 (это уже 1.3 миллисекунды задержки). Все гранитно стабильно!

Выставляю 48000 / 32 (тридцать два, Карл!) - работает! Иногда похрюкивает.

КАК???? Это вообще законно??

Вопрос у меня вот в чем - как именно в xanmod так выходит, какие опции, или модификации, могут повлиять на то что стало вот так?

ИТАК

Пожалуй подведу окончательные итоги.

  1. Практически все широко распространенные в сети рекомендации надо читать навыворот. Почему - отдельный вопрос.

  2. Лучше всего для обеспечения low-latency при работе с аудио подходит обычное, общего назначения ядро. Даже ванильное ядро с kernel.org может обеспечить экстремально низкую задержку на моем музейном железе.

  3. Ядро linux_rt подходит заметно хуже. Я не знаю почему. Видимо оно для совсем других задач, а то что оно работало со звуком лучше - дела давно минувших дней. Современные версии обычного ядра работают лучше.

  4. Рекомендации по настройке ядра, по CONFIG_HZ, PREEMPT - можно выполнять, можно нет. Низкая задержка достижима с любыми вариантами этих настроек.

  5. Желательно собирать ядро с минимальной конфигурацией. по-видимому я столкнулся с тем, что на конфигурации от Arch Linux на моем железе что-то лишнее мешало.

★★★★

Последнее исправление: James_Holden (всего исправлений: 3)

Периодически я решал озаботиться улучшением, первое что советуют везде - использовать linux_rt вместо обычного ядра

BTW, ubuntu studio использует linux-lowlatency - это 1000HZ и PREEMPT=y. Есть мнение, что этого достаточно! Доводилось ли тебе испытывать столь простой конфиг?

anonymous
()

КАК???? Это вообще законно??

Вопрос у меня вот в чем - как именно в xanmod так выходит, какие опции, или модификации, могут повлиять на то что стало вот так?

Стоит подвести итоги и переформулировать вопросы.

В чем проблема и каков теперь главный вопрос?

Улучшение происходит при смене ядра с 510 на 515? Что еще интересного? Какое ядро больше всего сломано, какое лучшее?

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

Допустим нужно каждые 60мкс отправлять сообщение, ни больше ни меньше.

Извините что влезаю, меня звуковые аспекты здесь волнуют только на уровне хобби, и мне 8-10ms для моих задач вполне хватает. Но устойчивые 60мкс это более менее серьёзная заява. На скольки девятках?

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

Никак, потому что тик отключается при отсуствии нагрузки, а при её присутствии уже ничего не меняет. Правда 1000hz говно потому что имеет больший оверхед, лично замерял. Себе ставлю 100hz, визуально задержек не вижу, попугаи выросли.

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

Шаманство какое-то. Не представляю. Знаю одно - когда вот так прыгаешь с бубном, «улучшаешь» систему, кажется, что всё очень хорошо. Но через какое-то время становится всё плохо. Даже обновлений не надо, линукс просто решает разжиреть и обнаглеть. Вспомни мою первую тему про пайпваир, у меня даже блютус наушники работали с 64-ым буффером. А теперь даде на встройке не возможно что-то посерьёзнее делать даже на 128.

Кстати, вчера вечером докомпилял-таки ядро, сегодня-завтра вечером попробую, что там за серебряная пуля :)

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

Когда-то в Дебьяне сравнивал стандартное ядро и преемпт, вообще никакой разницы в нагреваниях, или жоре батареи не заметил.

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

Там же вроде PREEMPT_VOLUNTARY включен

Да, в NixOS включен.

Итак, проверил. Параметр preempt не влияет. Пробовал все три значения - none, full, voluntary. Работает одинаково. PREEMPT_DYNAMIC включено.

Возможно еще, что в 5.15 что-то наулучшали

5.14 от NixOS работает так же хорошо.

Вот конфиг ядра NixOS

https://pastebin.com/QJ4tKhnn

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

Стоит подвести итоги и переформулировать вопросы.

Добавил в основной пост.

Улучшение происходит при смене ядра с 510 на 515?

Скорее не в этом дело. При смене с арча 5.14 на NixOS 5.14 такой же эффект.

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

просто арч дает плохой конфиг, так выходит?

Фиг знает, это все крайне странно. Я очень мало верю что в арче прямо кривое ядро. Возможно (очень гипотетически), там включен какой-то драйвер, типа датчиков, который не дает стабильно переключаться на pipewire.

Еще крайне странно, что эффект есть только с pipewire. На чистой alsa задержка намного хуже. Всегда раньше было наоборот.

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

Попробуй тогда в Арчевском конфиге таймер на 1000 Hz переключить, как в NixOS. Либо можно 500 Hz попробовать, как в XanMod, но придется тогда патч наложить.

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

В RT ядрах еще и realtime патчи на PREEMPT_RT, а как ты сам выяснил, режим preemption не то чтобы заметно влият на задержки в твоем случае. А может вообще realtime каким-то образом ухудшает ситацию, так что логично предположить, что дело в таймере. Конечно, может и не в нем дело, но попробовать стоит.

Просто отличий в конфигах много, но из очевидно влияющего на задержки только частота таймера в глаза бросается.

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

А clocksource используется одинаковый или нет? Что cat /sys/devices/system/clocksource/clocksource0/current_clocksource показывает под разными ядрами? И cat /sys/devices/system/clocksource/clocksource0/available_clocksource тоже глянуть бы на разных ядрах.

А ещё ЕМНИП в xanmod патченный планировщик задач умеющий в SCHED_ISO и softrealtime. Но кажется это уже писали.

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

Одинаково в обоих случаях, хорошем и плохом

tsc
tsc hpet acpi_pm
James_Holden ★★★★
() автор топика
Ответ на: комментарий от Jameson

А ещё ЕМНИП в xanmod патченный планировщик задач

Все идет к тому что xanmod патчи не причем, на обычном ядре от NixOS то же самое. Правда, они туда тоже какие-то патчи могли накатить вполне.

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

А можешь ещё глянуть, в «плохом» ядре CONFIG_SND_HRTIMER включено как либо, модулем там, или в ядро, или выключено совсем?

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

Вот мне как раз кажется что xanmod патчи как раз причём и Nixовское ядро тоже совсем не ванилла. Я кстати посмотрел, у меня в xanmod 500mhz таймер, может это он так влияет всё же? Ещё ЕМНИП в xanmod используются отличные от ванильных дефолтные настройки переменных шедулера, аналогичные тем что в zen ядре по дефолту, они их оттуда упёрли.

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

Дык ты усуши его под своё железо, чо ты как не инженер. И будет оно пересобираться быстро и красиво...

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

Поверю на слово, так как Nix и как у него ядро собирается не знаю совсем. Но удивлён, думал ванилла нынче только в слаке да LFS осталась. Слегка даже удивлён. Ну если Nixовская ванилла тоже магию делает - нужно смотреть .config тогда. Значит колдовство там спрятано, потому что ванильный конфиг с дефолтными параметрами «ни рыба ни мясо» и слегка деревянный. Значит они там что то подкручивают возможно.

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

Во-первых усушивать я буду неделю, что еще дольше. Во-вторых у меня практическая задача не усушить, а наоборот сделать универсальным.

James_Holden ★★★★
() автор топика

а вот ещё такой вопрос:
Физическая-то задержка в NixOS при буфере 32 действительно маленькая? Меньше чем в RT но с 64, например?

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

Физическая-то задержка в NixOS при буфере 32 действительно маленькая? Меньше чем в RT но с 64, например?

Ну наверное. А почему она не меньше будет? По идее тут не должно влиять какое ядро, NixOS или винда или еще что-то. Влияет на то, что буфер 32 вообще посыпется, или не посыпется.

Но под виндой, насколько я видел по обзорам, дается при настройке ASIO реальная задержка. А под линуксом - только буфер, а он при величине 32 становится маленькой, почти незначительной частью реальной задержки. Так что циферки 0,7 мс гордо горящие в ардуре ни о чем не говорят.

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

Я понимаю, что ты имеешь в виду - а может в NixOS показывает одно, а физически задержка в разы больше, потому оно и работает. Но так не может быть - буфер то реально 32 (это видно по потоку, прилетающему в плагины, я проверял там действительно 32 семпла за шаг прилетает), а значит pipewire должно как бешеное переключаться чтобы успеть его отработать. И оно мистическим образом успевает.

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

У меня система засрана и от тяжести плагина зависит

https://ibb.co/dkMbN6c
если так - работает, но иногда попердывает

Если выставить 64 семпла, то небула работает отлично
ASIO тогда пишет полную задержку - 380 семплов/4,0мс (по 190 на вход и выход)

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

В реальности, там ещё 3-4 семпла набегает
Когда daw настраиваешь - кладешь наушник на звукосниматель и записываешь клик. Он чуть чуть позже сетки. Но там действительно 3-4 семпла.
А так-то да. У специально заточенных под какую-никакую звукозапись, карт, стараются делать аппаратную задержку поменьше. Это и не новость.

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

наушник к датчику в упор
в daw включаешь запись и метроном
датчик поймает клик с катушки, безо всякого воздуха

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

Понятно.

Ну 3 семпла на 96 кГц это вообще ни о чем.

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

@hakavlad @Kron4ek @pon4ik @R_He_Po6oT

Парад фантастических чудес продолжается!

Я собрал кое-как кастомное ядро, включив всего по минимуму. Исходники ядра - от обычного 5.15 от NixOS, конфиг настраивал с нуля через make menuconfig. Включил реально минимум, еле грузится система. Сделал специально CONFIG_HZ=100 - думал это все сломает. И включил full preempt.

На этот раз пробую на стационарнике! core 2 duo, встройка VIA. Вообще чудеса показывает!

Выставил буфер 96000/16 и работает стабильно, если вынуть WiFi карту. Этот же системник работает с таким буфером и на обычном NixOS ядре, но довольно сильно сыпет xrun’ами. А на самосборном - стабильно.

То есть предварительно получается, дело не в таймере. Видимо какие-то модули все-таки мешали.

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

Блин, а я так и не испробовал вчера новоиспечённое ядро. Пришёл домой и заснул. Сегодня точно надо попробовать.

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

Может интерфейс настройки pipewire не пашет?

Всмысле не пашет? Тут наоборот что-то черезчур пашет.

А, ты про то, реальные ли цифры? Да, реальные 146%. Я проверяю не только через интерфейс. Действительно такая низкая задержка.

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

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

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

Надо было поиграться с эксклюзивным выделением процессорных ядер под звуковой софт

Даже не знаю, он интенсивно использует память, сможет ли он работать на отдельном ядре полностью независимо?

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

+Тик шедулера даже можно убрать.

anonymous
()

(тред не читал)

Кстати, такой вопрос: вот ты всё это тестировал на NixOS, с "пуповером", а что скажешь по поводу других дистрибутивов и JACK? Я чего спрашиваю – ещё не все плагины с pw-jack работают, да и съезжать с "арча" не хочется.

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

а что скажешь по поводу других дистрибутивов и JACK?

Когда я начал использовать аудио и JACK в принципе, я уже закончил период скакания по дистрибутивам.

Поэтому могу сказать только вот что.

В Arch Linux - работало плоховато последние лет 5 как я активно это использую. Сделал самосбор типа LFS - там так же как в Арче.

Вот теперь создал эту тему чтобы понять, что на арче не так. Явно дело именно в ядре, как оно собрано.

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

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

А Xanmod под "арчем" пробовал? Если оно имеет такие же настройки, как под NixOS, и даст такой же результат, то можно будет оную выкинуть из уравнения.

Кстати, могу вечером проверить, как оно будет (Arch, Xanmod, внешняя звуковуха), как домой доберусь.

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

А Xanmod под «арчем» пробовал?

У меня сейчас арча нет, ставить ради этого лень. Я пока поковыряю самосборные ядра, там и прояснится.

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