#alsa #gold

Победил проблему со звуком. Как? Что было?

Было 3 одновременных неприятных бага, которые устроены так, что, пока не заборешь все 3, звука не будет, и даже не будет понятно, есть у тебя прогресс, или нет.

* Как я уже рассказывал, система у меня определяла 2(на самом деле 3, но это неважно) аудиокарточки - hdmi выход в видеокарте, и встройку. alsa выбрала в качестве карты по умолчанию hdmi выход, поэтому звук, даже если и шел куда-то, то, явно, не туда.

* libalsa silently fail, если в системе нет группы audio. Конечно, нам в протокол общения с ядром обязательно надо указать эту информацию, даже если пользователю не нужен доступ к этой группе(у меня пользователи напрямую не ходят в alsa, а ходят в мультиплексор sndiod). Повторю - наличие пользователя в этой группе не нужно, важно наличие этой группы на машине. PZDS.

* В alsa все выходы по умолчанию mute. Это не было бы проблемой, если бы я знал/помнил, как это выглядит в "графическом" alsamixer. Выглядит оно... незаметно, скажем так. То, что каналы замучены, я нашел в полном большом выхлопе какой-то отладочной тулзы.

Наверное, стоит упомянуть, что, прежде чем чинить alsa, я попробовал вывести звук через alsa oss emulation, но у меня, с ходу, не получилось, потому что oss сейчас, конечно, уже так себе поддерживается в клиентах. Например, я нигде не смогу указать, что нужна именно вторая карта(к этому моменту я уже понимал, что звуковые карты перепутаны).

Все заработало? Нет!

Но сначала история из прошлого.

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

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

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

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

* there is no such thing as "protaskivanie"! #protaskivanie

и

* what the hell code are your writing?

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

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

К чему это я?

Авторы #sndiod решили позаниматься "protaskivanie" - они погрузили формат описания звукового устройства в какой-то свой формат, и мне понадобилось еще полчаса чтения кода, чтобы понять, что нужно запускать не "sndiod -f 1", а "sndiod -f rsnd/1". Что такое этот rsnd, и зачем он там нужен, я не понял.

С другой стороны, я пытаюсь делать так, чтобы "protaskivanie" не было нужно, поэтому я сделал так, что номер карты можно указать параметром ко всему #realm, и он попадет прямо в самый скрипт настройки sndiod:

pg-> ./ix list system
{'flags': {'alsa_device': '1', 'failsafe': '1'}, 
 'name': 'set/system/0'}

Этот флажочек сам пробулькивается до конечного скрипта:

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sndio/runit/scripts/ix.sh#L8

После этого все заработало, звук появился сразу и везде, кроме epiphany, потому что там аццкий gstreamer, с которым я еще вообще не разбирался.

https://roman.pt/posts/dont-let-dicts-spoil-your-code/
https://lobste.rs/s/gzemqn/don_t_let_dicts_spoil_your_code

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

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

Сначала я несколько переформулирую задачу, надеюсь, что без https://en.wikipedia.org/wiki/Straw_man

Учем, что в Python (очень упрощенно, но достаточно для моих нужд)

a.b := a.__dict__['b']

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

Плюсы этого подхода понятны - иногда(pun intended) не нужно менять внутреннее представление при изменении формата данных и протоколов.

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

Минусов же - вагон и маленькая тележка:

* Если вам не повезло, то нужно менять и промежуточное представление, и внутренние данные. Это все усложняет, и вы можете стать заложником такого разделения при попытке сменить формат данных.

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

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

* Performance. На этом не останавливаюсь, и так все понятно. Тут мне могут возразить про туплы и датаклассы - на разборе много потеряете.

* Достаточно subtle вещь, но IMHO важная. В Python dict везде, вы можете очень прозрачно манипулировать этими словарями как объектами, так и как kwargs, и часто это очень удобно. С классами как?

**a.__dict__['b']

? Ну такое.

* На каждое сочетание частей исходных данных классов не наберешься. Я к тому, что разных вариантов нетипизированных словарей у вас может быть очень много(в том числе, data driven), и вам совсем не захочется их все как-то именовать.

* #protaskivanie

Я свои словари разбираю только, если мне нужна полиморфная иерархия классов. И то, я постараюсь словари в поля классов не разбирать, а положить одним словарем все.

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

(Если подумать, то у меня в коде на Python сильно больше словарей и функций, чем классов с методами)

Ну и такое, философское, замечание - вот так вот отказываться от словарей в Python, это как в Lisp от списков.

Выходной, почему-то хорошее настроение, поэтому вот вам чутка менеджерской мудрости от дядюшки PG!

(мне эту глубокую мысль донес один коллега лет 17 назад, я не претендую на лавры изобретателя)

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

Пообещайте, что сейчас зашлете ему PR, и спокойно возвращайтесь на рабочее место.

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

В критической ситуации люди соображают быстро, да.

#llvmweekly (Остапа понесло, ага)

https://github.com/llvm/llvm-project/commit/d1fd97737e90

А вот если кому-то интересно, как запилить поддержку санитайзера под пока неподдерживаемую OS.

В целом, копируешь куски реализации из Linux, + немного #protaskivanie по обертке релеватных системных вызовов, + код для определения раскладки замапленых участков памяти процессом.

Муторно, но не очень сложно.

И взгляд с другой стороны - https://keithp.com/blogs/sanitizer-fun/, как поддержать неизвестную libc в санитайзерах, и с чем пришлось столкнуться.