[Android Software Development] guitardedhero:
Fantastic question. Through our greatest attempts to provide the ultimate modular installation, one unavoidable peculiarity manifested from my insistence on dictating precise placement of all audio_effects entries for every module that has them.

This is the important fact of our Core module to understand:

Whenever the Core module is installed, a base template of the appropriate audio effects configuration for the device is placed containing only Core module and device firmware libraries and effects.

In addition to those entries, there are many slots for the available modules in specific locations that have no effect other than satisfying a module's installation requirement to write its necessary library and effect entries to the file in order to function.

All modules with library and effect entries besides Core only edit the audio effects configuration (add to it when installed, removed from it when uninstalled).

Once the Core module has successfully installed, followed by a few modules, the result is a prepared audio effects configuration. Installing/uninstalling modules other than Core can be done countless times without starting over.

Now, let's take this carefully prepared audio effects configuration that is the result of numerous module testing and assume it is exactly how it is wanted to be:

If Core module is installed over that installation, the audio effects configuration is now overwritten by the base file. Restoring that optimum sound system installation from before will require installing the same modules as before.

If experimentation is the objective, install Core module only once. If using non-AROMA, remove the value of "true" from "install.core=" in /sdcard/arise_customize.prop. This step should be very familiar as a value of "true" does not exist for any property line and will trigger an Error 1 in the recovery session if /sdcard/arise_customize.prop remains unchanged.

This is done in a manner that forces the user to edit the file we like to call WISHLIST. Hundreds of combinations are possible with this simple file by adding a value of true to desired module installations/uninstallations.

If updating to a new sound system version with additional modules already decided, the WISHLIST can be prepared to install Core and optional modules in one recovery session. If experimentation is later desired, remember to remove the value of "true" from "install.core=" first.

This evasiveness of inadvertently reinstalling the Core module is mimicked by the Skip to Modules selection in the beginning of the AROMA session. :good:

---------- Post added at 08:28 PM ---------- Previous post was at 07:57 PM ----------

Correct. A minimum of 0700 permissions is required to execute an executable script in /system/su.d with a functioning SuperSU installation, either system or systemless. Anything less than 0700 permissions will remove any execute permissions rendering the script having no effect or impact.

A bootloop causing script can be incapacitated by booting into recovery, mounting System, navigating to /system/su.d, and applying 0600 permissions or less to the script responsible.

My suggestion for changing permissions fulfills two great habits of file management:

It promotes an awareness of permissions a file or directory has as well as the impact permissions can have. We've all seen permissions all over the place when dealing with inept preparations of mods of various kinds. A user may be oblivious to what seems to be screaming at a user that is always aware of current permissions when observing through a file manager not requiring additional steps to even see the permissions (another important thing to ensure).

It promotes managing the problem head-on. There is almost always more than one way to achieve a result. Efficiency is always an important value to maintain, but the lesson of cause and effect is hardly ever a challenge to learn or understand.

Please know that I'm not dismissing your alternate suggestion, both have the same result on the device. I just wanted to clarify why I made mine. :good:

---------- Post added at 08:45 PM ---------- Previous post was at 08:28 PM ----------

It's conditional whether reinstalling the Core module is logical: A significant update to Core content or a desire to install the Core to start fresh for testing available modules.

The scenario where reinstalling the Core module should be avoided is when active experimentation is taking place while installing/uninstalling various modules.

Next time you flash your ROM zip, I recommend reinstalling the sound system while keeping audio_policy intact by selecting No for the deep_buffer module. You are familiar with the modified audio_policy, see how your device performs with its audio_policy intact. :good:

---------- Post added at 09:05 PM ---------- Previous post was at 08:45 PM ----------

I am not aware of a way to utilize an impulse response sample outside of an application. That would be quite the discovery though!

SRS has existed in many different forms in Android mobile, many being simple software libraries and effects, especially earlier on in Android development. Advancement and efficiency in technology has allowed the more complex utilizations of more powerful effects to take advantage of existing hardware for minimal power consumption and optimum levels of processing.

Arkamys on the mobile platform certainly begs for some clarity and information. As you may know, Arkamys is most known for its automobile audio systems, even if it isn't a unanimously adored audio technology for many auto enthusiasts.

In Android, Arkamys seems to influence the lower bass frequencies more than any other affect on a sound profile. Still, after using for quite some time, it is almost more obvious and apparent when it is not there rather then when it is, if that even makes sense lol. :good: