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

Мне тут на ЛОР писали что вертикальная синхронизация экрана может портить параметры реалтайма.

Думал об этом, но я проверял - у меня не влияет. В разных DE, WM, при разных настройках одно и то же.

Ещё у меня было наблюдение что реалтайм зависит от правильной видеокарты(на видеокартах с широкой шиной 128 бит и более, но как оказалось не на любых и по моему с обновлениями ядра испортились и на той где было хорошо).

Во вторых можно было видеть как он постепенно за лето довольно сильно попортился, в какой год на память не скажу, но было это на debian wheezy, а значит можешь прикинуть в какие версии ядра это произошло.

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

А не пробовал на рипер перейти? Там ни jack, ни pipewire не нужны - напрямую через alsa работает

Ну и еще, у хороших звуковых карт есть аппаратный мониторинг, правда тогда звук себе придется «делать» с помощью педальки

Пробовал в том числе, и ardour через alsa напрямую работает тоже - все то же самое.

есть аппаратный мониторинг

Я его за пять минут для любой карты спаяю.

Я его за пять минут для любой карты спаяю.

И микс с плэйбеком сделаешь? Тебе же не только себя слушать надо

И монопольно захватывает аудиоустройство так что другие приложения становятся немыми. Линукс как он есть лол

И монопольно захватывает аудиоустройство так что другие приложения становятся немыми.

И это хорошо

И микс с плэйбеком сделаешь?

Ну да. Плюс два резистора.

Линукс как он есть лол

А в других ОС типа как-то иначе? Везде DAW монопольно захватывает, ЕМНИП. В линуксе как раз с этим лучше.

Плюс два резистора.

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

ядро xanmod 5.14. Происходит какая-то мистика!

Не xanmod rt-вариант?

А какой планировщик?

Подписался на тему. Аж самому интересно, что тамошние разработчики накорчевали.

hakavlad, ты же туда патч слал, как думаешь, могло повлиять?

Вряд ли дело в le9.

В xanmod много всего, см список https://xanmod.org/

xanmod… рвет

Какая именно версия xanmod? Там же много всяких - rt, cacule, Task Type CPU Sched (TT) etc. Исследовал ли разные версии xanmod?

Исследовал ли также liquorix или zen? Там твики шедулера, например. https://liquorix.net/

А в других ОС типа как-то иначе?

Другой конфиг ядра и прочие другие настройки.

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

Подозреваю что ТСа просто тупо спасает опция CONFIG_HZ=500, емнип в абсолютно всех дистрибутивах она из коробки 250.

В liquorix эта опция равно 1000 что сильно греет процессор в играх. На liquorix я видел зависания системы в первый же день, на xanmod ни разу за пол года.

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

    Caching, Virtual Memory Manager and CPUFreq Governor improvements.

    Full multi-core block layer runqueue requests for high I/O throughput.

    BBRv2 TCP congestion control + FQ-PIE packet scheduling and AQM algorithm.

    ORC Unwinder for kernel stack traces (debuginfo) implementation.

    High responsiveness multitasking Task Type scheduler (SCHED_NORMAL) build available [5.15-tt].

    Real-time Linux kernel (PREEMPT_RT) build available [5.15-rt] [5.10-rt].

        TCP performance optimizations backport from linux/net-next [5.15].

        AMD's P-state driver for Zen2 and Zen3 processors [5.15].

        Google's BBRv2 TCP congestion control.

        PCIe ACS Override for bypassing IOMMU groups support.

        Graysky's additional CPU optimizations for GCC and Clang.

        Clear Linux patchset [partial].

        Android Ashmem and Binder IPC driver as module for Anbox.

Что-то из этого. https://xanmod.org/

Не исследовал, пробовал только cacule!

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

Странно, у меня именно это. Кстати система в целом тоже отлично работает.

у тебя 5.14, а сейчас он какуле заменил на какой-то «task type»

хотя здесь https://forum.xanmod.org/thread-4169.html?highlight=cacule в конце сообщают что проблемы пофикшены, в любом случае когда обновишься до 5.15 никакого cacule уже не будет.

Ага, надо попробовать 5.15, может что прояснится.

так может дело и не в нем, может улучшение дают другие патчи

Поставил сейчас 5.15 «task type».

Все то же самое - работает очешуенно. Значит дело не в этом шедулере.

Ставить просто rt-ядро без настроек и перевешивания нужных процессов по нужным ядрам, это всё равно что распаковать презерватив и положить его рядом, может эффект и будет, но скорее плацебо.

Естественно то что нужно настроено, импользуется rtkit.

И второй момент - с точно такими же настройками на xanmod все зашибись.

Ну я на всякий, мало-ли ты его поставил и ожидаешь чуда. Второй момент, rt ядро всё-таки для мягкого рилтайма на серверочках где это нужно. Т.е. по-сути призвано обслуживать одно приложение, ценой чего? ценой всего правильно, скорее всего ядрышко рассчитанное на десктоп имеет другой конфиг само по себе, хоть и содержит «такой же» планировщик. Третий момент, если дистрибутив из коробки поставляется с rt ядром, там скорее всего лучше настроены различные релевантные вещи(как пример - дефолтные опции сокетов).

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

А это на той же системе, где у тебя недавно Шмель взлетел со старой картой?

Ну и как с какулями? Летает Шмель?

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

Допустим, если у меня настройки неправильные, то как оно тогда на xanmod работает?

А это на той же системе, где у тебя недавно Шмель взлетел со старой картой?

Да, там же.

Ну и как с какулями? Летает Шмель?

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

Но какули по сути все, я уже поставил 5.15 c tt и на какули возвращаться смысла нет.

Ядро Linux 5.15 Task Type CPU Sched (TT) ?

У меня на 5.14 драйвер вообще отваливался. На чем-то новее 5.4 OpenCL отпадало.

Драйвер nvidia-390, Ubuntu 20.04, ядра 5.10, 5.13, OpenCL

Спасибо за инфу. На досуге надо будет 5.15 попробовать.

Всё просто, те настройки которые ты не задаёшь наследуются от некоторого дефолта, носителем которого является init. Я сильно сомневаюсь, что ты задаёшь прям все возможные настройки вручную :)

Как вариант, можно ещё конфиги ядра сравнить.

Ядро Linux 5.15 Task Type CPU Sched (TT) ?

Да.

Можно, но там же патчей еще вагон. Не пойму как можно изолировать проблему без пересборки ядра 100500 раз.

Я почему про это всё вещаю, тонко настроенное даже 3.х rt ядрышко легко даёт стабильные результаты для микросекундных точностей например заданные 60мкс в 99.9999% случаев (понятное дело, если по дороге не было чего-то что просто не умещается в эту величину). А ты говоришь про величины на 2 порядка выше, притом на существенную разницу. Поэтому 100% поменялось что-то не шедулере, скорее всего более разумная настройка или их набор, хотя, версию pipewire ябы тоже сравнил учитывая стадию разработки изделия.

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

Чуть лучше изолировать проблему можно попробовать сделав профилирование под нагрузкой воспроизводящей проблему под профайлером.

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

стабильные результаты для микросекундных точностей например заданные 60мкс в 99.9999% случаев

Погоди, то есть допустим делаем один процесс риалтаймовым, и он будет стабильно включаться каждые 60 микросекунд? Или как?

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

версию pipewire ябы тоже сравнил учитывая стадию разработки изделия

Версия во всех попытках одинаковая, я только ядро меняю.

А как вот эта частота тиков 500 герц влияет?

профилирование под нагрузкой воспроизводящей проблему под профайлером

А как? Можно как-то определить из-за чего конкретно не успевает? Воспроизвести нагрузку проще простого - запустить звук )))

вообще, rt ядра должны работать как rt, только если нет нагрузки, если процессов куча, никакой выгоды от этого не получишь

Так приоритеты процессов же разные.

Погоди, то есть допустим делаем один процесс риалтаймовым, и он будет стабильно включаться каждые 60 микросекунд? Или как?

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

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

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

Разница между риалтайм планированием и вытесняющей многозадачностью вот в чём: при вытесняющей многозадачности у твоего процесса есть квант времени через который он гарантированно уснёт, чтобы дать поработать другим процессам (например процесс поработал 1мс, потом уснул а остальные процессы работали 0.4мс, он проснулся, но сэмпл уже просран и не акутален, либо класть его в очередь и наращивать задержку либо выкидывать из потока). При «риалтайм» планировании, процесс(на самом деле тут лучше говорить про потоки) работает, пока у него есть работа, и просыпается как только работа появилась вновь, но есть вариации в зависимости от политики планирования и нюансы в зависимости от установок affinity.

А как вот эта частота тиков 500 герц влияет?

Это я х3 про что ты я в обработке звука практически ничего не понимаю.

Слово preemptive тут всё портит…

man perf

Точно для твоей задачи нужно будет использовать повышенную частоту сэмплирования (вот ирония, сэмплировать сэмплирование :)).

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

А linux_rt тут вообще как-то помогает по сравнению с обычным ядром? Почему-то всегда для звука советуют linux-rt ставить…

Это я х3 про что ты я в обработке звука практически ничего не понимаю.

Это не про звук, я про опцию конфига ядра CONFIG_HZ = 500 (у xanmod).

Точно для твоей задачи нужно будет использовать повышенную частоту сэмплирования (вот ирония, сэмплировать сэмплирование :)).

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

А linux_rt тут вообще как-то помогает по сравнению с обычным ядром? Почему-то всегда для звука советуют linux-rt ставить…

Помогает тем, что там есть софт риалтайм планировщики. Если воспроизводить серверный подход, можно с одного или двух ядер согнать все процессы, и посадить на них «mission critical» процесс, и сказать - он никогда не спит. В обычном ядре так нельзя.

Это не про звук, я про опцию конфига ядра CONFIG_HZ = 500 (у xanmod).

При прочих равных это читается как «точность таймера», раз в 500мкс будет приелтать на ядро прерывания таймера, именно с такой частотой(раз в 500мкс) оно будет проверять не пора ли усыпить какой-то процесс. Т.е. если процес начал работать в 0мкс от предыдущего прерывания, поработал 1мс, ему осталось поработать ещё 50мкс, то в зависимости от политики планирования и настроек планировщика он либо уснёт, либо поработает ещё 500мкс.