[10:45:40] <vasy> Привет всем!
[12:13:58] <stuw> vasy, привет. Что-нибудь еще раскопал по звуку?
[12:14:58] <stuw> https://github.com/CyanogenMod/android_hardware_qcom_audio-caf/blob/cm-11.0/policy_hal/AudioPolicyManager.cpp#L56
[12:15:02] <stuw> https://github.com/CyanogenMod/android_hardware_qcom_audio-caf/blob/cm-11.0/policy_hal/AudioPolicyManager.cpp#L315
[12:15:13] <stuw> в новом хале я только два места с роутингом нашел
[12:16:21] <stuw> можно попробовать найти, что происходит, когда передается этот параметр и попробовать это сделать через утилиты с новым халом.
[12:22:00] <vasy> больше пока не копал, но мне кажется что дело, вот в этом:
[12:22:00] <vasy> E/AudioSystem( 799): AudioSystem::setParameters keyValuePairs=in_call=true
[12:22:00] <vasy> а 799 это PID system_server
[12:25:54] <vasy> а 226 pid mediarerver'а
[12:25:54] <vasy> так что, libril-qc-qmi-1.so тут вроде не причем...
[12:31:31] <zombah> добрый день всем
[12:34:42] <vasy> zombah: Привет!
[12:35:15] <vasy> про звук тока перед твоим приходом писал:
[12:35:15] <vasy> больше пока не копал, но мне кажется что дело, вот в этом:
[12:35:15] <vasy> E/AudioSystem( 799): AudioSystem::setParameters keyValuePairs=in_call=true
[12:35:15] <vasy> а 799 это PID system_server
[12:35:15] <vasy> а 226 pid mediarerver'а
[12:35:16] <vasy> так что, libril-qc-qmi-1.so тут вроде не причем...
[12:35:53] <zombah> хм ты думаешь его нет когда надо или что?
[12:36:33] <vasy> а ты читал мои логи позавчера?
[12:37:12] <zombah> когда ты дебаг этого setparameters собирал? вроде читал
[12:37:44] <zombah> хотя мельком у меня на работе дел много было
[12:38:03] <vasy> ага, так вот это строка есть на legacy hal, и нету на "новом"
[12:38:33] <zombah> ааа а ты уже нашел кто ее вызивает?
[12:39:23] <vasy> 799 это PID system_server, больше еще не нарыл...
[12:43:41] <stuw> я не помню, мы собирали состояние dapm до звонка и при звонке?
[12:44:04] <vasy> stuw: dapm это что?
[12:45:34] <stuw> хз как проще объяснить ) в алсе это обозначает элементы, которые контролируют состояние разных кусков кодека (вкл/выкл). Они связаны (связи могут динамически меняться).
[12:45:59] <stuw> Включается цепочка от входа до выхода.
[12:46:20] <stuw> маршрут (routing) и определяет, какие элементы будут включаться
[12:47:27] <stuw> 20 мая что-то разгребали
[12:48:15] <vasy> stuw: это выяснили, в случае "нового" hal нечего не изменяется
[12:48:45] <stuw> а что меняется до вызова и во время со старым ?
[12:49:20] <vasy> stuw: а там много всего, я так не помню
[12:49:35] <vasy> но стуть в том что с новым вообще нечего не меняется
[12:51:34] <stuw> RX1 MIX2 INP1 с ZERO на IIR1 и RX1 MIX1 INP1 с ZERO на RX1 меняется
[12:52:00] <stuw> что-то как-то по кругу ходим ))
[12:52:19] <vasy> ага :)
[12:53:45] <stuw> в tynimix/alsamixer можно поменять значение "RX1 MIX2 INP1" и "RX1 MIX1 INP1" ?
[12:54:17] <vasy> stuw: я тогда куртил что-то руками, добился шипения из динамика, но не звука
[12:54:58] <stuw> шипение это уже что-то ))
[12:55:22] <vasy> но мне кажется куртить als'у это всетаки не правильный путь :)
[12:55:26] <stuw> arecord/aplay есть утилиты?
[12:56:03] <vasy> вроде нету
[12:56:18] <stuw> через алсу можно проверить, что на правильном пути. Нормальный фикс должен починить звук не в алсе, а где-то в недрах андроида
[12:56:34] <stuw> они задрали звуковую подсистему переписывать ) вот что я скажу ))
[12:56:38] <zombah> их можно добавить они там же где tinymix живут
[12:57:01] <vasy> так суть , что как раз с новым hal alsa вообще не дергается при звонке
[12:57:40] <stuw> и уровень звука не меняется?
[12:57:57] <vasy> stuw: вообще нечего не меняется
[12:58:05] <stuw> дуру-дуру-дурдом ))
[12:58:39] <vasy> и таки мне кажется что с
[12:58:39] <vasy> AudioSystem::setParameters keyValuePairs=in_call=true
[12:58:39] <vasy> это связано...
[12:58:53] <vasy> но ведь еще есть и косяк со второй sim....
[13:00:34] <zombah> т.е. легаси в сорца думаю имеет смысл сначала с ним поиграться
[13:00:55] <vasy> а что именно играть?
[13:01:28] <zombah> vasy: да как и раньше лог симки где звонок срабатывает и лог где нет, чтобы понять чего не хватает
[13:02:04] <zombah> надо найти место на котором обрывается цепочка
[13:02:06] <vasy> zombah: я уже вроде выкладывал с неделю назад
[13:02:38] <zombah> vasy: да но там такого не видно, надо еще дебагов вставлять
[13:09:38] <vasy> да он и так вроде каждый чих пишет:
[13:09:38] <vasy> D/alsa_ucm( 225): Setting mixer control: Voice_Tx Mixer PRI_MI2S_TX_Voice, value: 0
[13:09:38] <vasy> D/alsa_ucm( 225): Setting mixer control: RX1 MIX1 INP1, value: ZERO
[13:09:38] <vasy> и тд и тп
[13:10:43] <vasy> с учетом того, что стоковый так-же работает, со второй sim дело не в hal
[13:11:55] <zombah> ну где этот чих должен не совпадать иначе бы все работало 8)
[13:12:41] <vasy> тут может в сток попробовать засунуть эту либу и посмотреть лог
[13:20:07] <zombah> попробуй, я правда боюсь вдруг там все работать будет 8)
[15:00:33] <vasy> zombah: strnlen ???
[15:46:35] <zombah> vasy: в drivers/soc/tegra/pmc.c strnlen нет
[15:48:06] <zombah> а вообще это распространенная функция много где в ядре используется
[15:50:19] <vasy> zombah: если я правильно понял strnlen oops вызывает
[15:51:48] <zombah> так 4.2 смотрю уже фигово старыми компиляторами собирается
[15:52:08] <zombah> во многих модулях ругань странная
[15:55:20] <vasy> zombah: а ядро всегда было к компилятору чувствительно
[15:55:32] <zombah> всяко да
[17:53:34] <zombah> stuw: попингай вольфрама а то чет он не отвечает
[17:53:53] <stuw> да че пинать, надо слать новую версию и все )
[17:54:13] <zombah> stuw: ну так тыж хотел потестить на джетсоне?
[17:54:30] <stuw> пущай боевую версию тестят )
[17:54:49] <zombah> stuw: ишь не тоже вариант
[17:55:01] <zombah> ну тоже вариант тобишь
[17:55:09] <stuw> я понял )
[18:12:46] <zombah> блин с 4.2 у меня теперь наоборот с обычным cmdline грузится, вставляю initcall_debug хрен экран все время дохнет
[18:13:47] <zombah> думаю это atomic modesetting виноват