[Android Software Development] guitardedhero:
The Sony libraries part of the Core module installation are currently reserved for Qualcomm devices as I long suspected that compatibility was limited to Qualcomm. I'd love to be proven wrong, though.

The individual Sony effects libraries like xloud, clearaudio, vpt, and others are actually all bundled into libsonysweffect.so which has weighed in at a hefty 1.0MB or more for.some time now. These individual effects are not configured with audio effects entries, libsonysweffect.so uses build.prop or setprop entries for configuration, using a combination of values for the available effects using the following table that is included in the setprop installed with the Sony module:

I know it's not the user-friendliest manner for sound profiles, but Sony never intended this to be an activity performed by the user, SoundEnhancement is what sets these values when the user makes selections.

Below are two default sound profiles to show how these values indicate very specific effects selections:

This first default profile is for the device speaker with the value of 0x122.

Referring to the Sony Effect table while reading the speaker profile right-to-left, the value of 2 is S-Force, the value of 20 is ClearPhase Speaker, and the value of 100 is Speaker Bundle resulting in a value of 122 when all are combined.

The second default profile just above is the headset profile. This profile is a good example to show the additional arithmetic that results with values that cannot be attributed to an effect without a single instance of addition. Taking the default Headset Profile value of 0x298, you might notice that there is no value of 90 for an effect in the Sony Effect table.

Reading right-to-left, we know ClearAudio is there. Even the remaining single digit effects combined fall short of a value of 8 (the remaining would add up to 7), so we know ClearAudio is part of the default Headset profile.

The same logic applies to the value of 90 in the default Headset profile value of 298: 90 can only result by adding the values 80 and 10, ClearAudio+ and VPT, respectively. As you can see, no other combination can produce a value of 90.

The final value of 200 in 298 is obviously ACL (Auto Level Control or Auto Loudness Control)

Breaking down default profiles using this arithmetic allows you to create your own values using the desired effects with the confidence that you are hearing what you applied and not some some random combination of effects.

The appearance of Sony in most Core module installations and the optional Sony module certainly seem questionable at best, especially if the Sony Effect table is limited to the Sony module. It's been one of my least satisfied implementations. The fact is, dating back to the ViPER|Atmos days, the Pulse visualization feature of Dirty Unicorns and now other roms, has been a very demanding feature to support with no support never being an option lol. I finally found a way back then to enhance Pulse beyond Google Play Music or whatever individual media player it was with Dirty Unicorns. Once Pulse functioned with all other media players, there was no turning back. I've found myself in a kind of permanent​ marriage ever since.

All it took to provide this enhanced support was the combination of the Sony SW Effect and visualizer audio effects configuration entries, as well as those libraries, of course.

The Core module's usage of Sony content is to provide Pulse support, nothing more. The reason the Sony module has the setprop with the Sony Effect table is because the Sony module includes /system/etc/sony_effect, the directory of binary code for the individual effects which are required for these Sony effects if wanting anything more than support for Pulse visualization.

The usage of scripts in /system/etc/init.d is done so with the hope that the device, in fact, has NO init.d support. While brainstorming manipulating multiple scripts with full control of order and timing, I came up with the current solution we have. While the current solution hopes the device does NOT have init.d support, it is absolutely DEPENDENT on su.d support with system or systemless SuperSU installations.

Essentially, a device rooted with SuperSU and without init.d support that has a single script in /system/su.d or /su/su.d after the ARISE installation only has one script that will execute automatically during boot. This particular script, more than anything else, is purposed for executing the init.d scripts in a specific order as well as schedule.

Any directory outside of /system/su.d in the system partition would provide the same ability. Even though it appears misinformed, I still opted to use init.d for those other scripts in the event a device, in fact, DOES have init.d support, which would allow a functioning ARISE installation without root whatsoever.

A slight chance for embarrassment in order to provide as much as possible to all users in all possible scenarios is worth it every time.

Something was off when you were testing your getprop results with /system/etc/init.d/arisesound_setprop, either name or permissions. Any file of any name with the shebang header (#!/system/bin/sh or #!/su/bin/sush) with 0700 permissions or above will execute automatically during boot. Anything in /system/etc/init.d without init.d support will only execute if targeted specifically by the /system/su.d script if its permissions (0775) and shebang header (#!/system/bin/sh) are appropriate.

:good:

---------- Post added at 12:44 AM ---------- Previous post was at 12:38 AM ----------

I'm sorry, I was asking about your rom's audio_effects.conf and not the one after the ARISE installation. Both uploads show your configuration being AOSP and NOT Android O Qualcomm, although Android O is still the default audio effects configuration Qualcomm devices receive if nothing else is specified. :good: