LuK1337 changed the topic of #titandev to: Loliés! | *yiff* | https://libera.irclog.whitequark.org/titandev
clfbbn has joined #titandev
<clfbbn> Does vendor/etc/acdbdata has anything to do with settings in audio_platform_info_intcodec.xml? I saw a list of acdb ids in audio hal msm8974/platform.c. Should I compare this and the decompiled stock's audio.primary.kona.so to get a working audio_platform_info_intcodec.xml?
<LuK1337> you don't have acdbdata in odm by chance, do you?
<LuK1337> (on stock)
<clfbbn> No. On stock, the acdbdata folder is located in vendor partition.
<LuK1337> if you think ids are wrong
<LuK1337> you can dump them /w https://github.com/cryptomilk/acdb_get
<LuK1337> also instructions are outdated
<LuK1337> you definitely don't want to push it to system
<LuK1337> XD
<clfbbn> OK, I will try that
<clfbbn> So first I used "generate_acdb_data.sh stock_audio_hal.so" to generate the header and make acdb_get, pushed the binary and stock audio.primary.kona.so to /vendor/bin and /vendor/lib64/hw accordingly (I have modified the src to dlopen the 64-bit lib). Then I got a list of acdb_ids that is very, very different from the original one.
<LuK1337> because it's printing everything
<LuK1337> not just overrides
<clfbbn> So I should compare it with what has been defined in msm8974/platform.c and see whether all acid_id matches, right?
<LuK1337> or dump lineage ids
<LuK1337> and diff
<LuK1337> xd
<clfbbn> So if I got everything right, this will not be the problem of acdb_ids because the diff shows that they are identical
<LuK1337> did you override vc vol steps?
<clfbbn> it is 7 originally and it does not work. Then I took ro.config.vc_call_vol_steps from stock which is 8
<LuK1337> uh
<LuK1337> your device has 32-bit audio
<LuK1337> doesn't it?
<LuK1337> and you said you pushed 64-bit one...
<LuK1337> it really seems sketchy that you say that there are no diffs
<LuK1337> between stock and lineag
<LuK1337> lineage
<LuK1337> that's very uncommon...
<clfbbn> Let me start all over, pushing 32-bit audio libraries, etc.
<clfbbn> voice_send_vol_step_cmd: DSP returned error[ADSP_EALREADY]
<clfbbn> Does this have some relations with the problem?
<clfbbn> But it says "ALREADY", never mind...
<LuK1337> no
<LuK1337> it just says your adsp is unhappy
<clfbbn> I am still getting the same results. Here are my steps: 1. generate header for lineage's hal && build 2. push to vendor/bin and execute 3. generate header for stock's hal && build 4. push to vendor/bin 5. push stock hal to vendor/lib/hw 6. (reboot) 7. execute
<LuK1337> strace it
<LuK1337> and see what audio.primary it actually loads
<clfbbn> openat(AT_FDCWD, "/vendor/lib/hw/audio.primary.kona.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
<LuK1337> uh
<LuK1337> you don't need to reboot btw
<clfbbn> Oh, I thought it will not actually dlopen a library if it is already loaded in memory.
<clfbbn> I do see here: https://gist.github.com/ThEMarD/0d6041fd38d6147e99130307e094f807 : "Sometimes though? You might be unfortunate enough to have an OEM who uses all kinds of haxxs in their audio HAL which will result in a lot of these ACDB ID's being wrong... so it's recommended to also check the audio_platform_info.xml to see what they have there and pray that it's the right ACDB ID's... worst case
<clfbbn> if they're not? You'll need to logcat your stock ROM to find the actual ACDB ID'"
clfbbn has quit [Quit: WeeChat 3.5]