Hey, thanks a lot! Just what I was looking for. That was great of you to point me in the right direction!! I'm off to learn all about how to use it.
Hey, thanks a lot! Just what I was looking for. That was great of you to point me in the right direction!! I'm off to learn all about how to use it.
Lord Sithek
Senior Member
You're welcome
You just need to have old profiles in the Viper's directory on the internal storage and then flash converter in Magisk Sent from my mido using XDA Labs
Uhhhh the installer said Incompatiblity detected. Is that a very bad sign
:silly: .Update: OK yep the app refused to open and now so far DolbyAtmos 0.94 is working for me.
Update: OK reinstalled DolbyAtmos 0.965 and got the log file for it. It seem like there's a problem with mounting partition
NewUPDATE: OK so one last attempt I install Viper with JamesDSP with Ainur Sauron with compariblity patch and Atmos and AML. Dolby refused to open. However, I then flash 0.965 and suprisingly it worked
. I AM SO CONFUSED. But after rethink I think I know what happened! But anyway it work now so OK thx.
Last edited:
Didn't try the .965 but reporting 0.964 on my Xperia XZ running aosp pie with magisk 20.3
Installed thu magisk, checking compatibility took like 10 mins and it said its not compatible aswell, but it worked just fine after installing, didn't break any other installed sound mods that i've wrote down below. All working just fine.
I already have like 4 other audio mods (Sauron, V4A, Dolby digital plus, DTS) that makes atmos 5.
Installed thu magisk, checking compatibility took like 10 mins and it said its not compatible aswell, but it worked just fine after installing, didn't break any other installed sound mods that i've wrote down below. All working just fine.
I already have like 4 other audio mods (Sauron, V4A, Dolby digital plus, DTS) that makes atmos 5.
Works fine on my Lenovo Yoga Tab 3 Plus (YTX703L) on official LineageOS 16, although installation freezed for a while on "Checking rom compatibility" and it said "X Incompatibility detected".
Wait a minute did you use emulator or is that just a screen mirroring app? I'm pretty dumb.
I use an application on windows which allows to display the screen because the K5 vibe that I tested in the middle of the touch screen which no longer responds ...
SCRCPY exe :good:
Lots of script changes. Be patient with the compatibility check (give up after five minutes, though).
If I remember correctly, it's ACDB last.
In a nutshell it's a similar idea to AML. Just a different implementation.
Sent from my Pixel 3a XL using XDA Labs
Order of installation does not matter as ACDB, at this time, prepares audio effects configurations during each device boot using what is available in Magisk modules at any given time.
It's finally operating how I had intended before the major ACDB update recently where I was running into issues accommodating multiple Magisk modules with the acdb.conf file.
Honestly, I do not know how it could be any easier for a dev or even a user wanting to add effect configuration to an existing module in less time than it took you to reach the end of this third paragraph.
The only matter of concern for dev/user interested in ACDB support is the acdb.conf file, which I suggest placing in the Magisk module's root folder next to module.prop and the /system folder.
This acdb.conf file contains four or more properties to which values need to be applied in order to have any configuration take place each device boot.
Many are already likely familiar with the relevant components in configuring an audio effect. For the rest of you, here's a quick synopsis:
Effect libraries in /lib/soundfx/ must be configured appropriately to have a chance at doing anything other than being absolutely dormant. Still, effect libraries fully configured have no effect whatsoever on the audio signal unless an effect-chain for the library is created by an apk, service, or other component. But, this can only happen if the library is properly configured in the first place.
Configuration takes place in various forms of two file types:
audio_effects.conf with its own Android-specific format and audio_effects.xml with its more standard xml.format.
The components used to configure an effect remain the same for both formats:
Library ID
Library Name
Effect ID
Effect UUID
The Library ID is entirely flexible and can be almost any single string, but it is encouraged to maintain the common Library ID unless a unique scenario calls for a change to be able to have more than one instance of a library.
The Library Name is, in fact, the filename of the library, so it is restricted to how the library appears in the filesystem. A change in filename will require the same change to Library Name when configuring, for example.
Before we move onto the two Effect components, let us use ViPER4Android's popular and familiar effect library to illustrate the two Library components.
ViPER4Android is an incredible DSP application with a phenomenal effect library:
libv4a_fx_ics.so
If you guessed this to be the Library Name value for the effect configuration, you are correct. The Library ID presented by the authors for libv4a_fx_ics.so is:
v4a_fx
As you can see, it does not appear to be anything other than an identifier as it does not match anything explicitly.
At this point, we have half of acdb.conf ready to complete already:
The Effect ID is exactly like the Library ID in that it is not intended to match anything other than itself. More often than not, the Effect ID is actually the same value as the Library ID, although, this doesn't mean anything other than one less thing to try to remember.
The authors of ViPER4Android presented their Effect ID slightly different than the Library ID:
v4a_standard_fx
Let us go ahead and plug that value in our acdb.conf:
Remaining now is the most exciting part of the effect library: its Universal Unique Identifier.
This is a 32 digit hexadecimal strict pattern inside the library and is responsible for Android's capacity to create an effect-chain in which the effect library can fulfill its purpose when compiled.
When configuring, this 32 digit hexadecimal (0-9,a-f) value is divided into hyphen separated groups of 8-4-4-4-12 like: 01234567-89ab-cdef-0123-456789abcdef
This value can be changed if a unique scenario calls for multiple instances to coexist and must be done to the library directly. Otherwise, the Effect UUID is fixed and no other value will allow the library to execute.
The ViPER4Android author presented the Effect UUID as:
41d3c987-e6cf-11e3-a88a-11aba5d5c51b
This fourth value can now complete our acdb.conf file to instantly configure the ViPER4Android effect during the reboot following the saving of acdb.conf and placing it inside an existing ViPER4Android Magisk module:
That's it. Nothing more to it. :good:
Last edited:
Hi. Thanks a lot for your hard work. Please answer me you can't do compatibility DA with AML or not want do this? Regards.
I've never actually used AML and ACDB came about during this testing phase as a way to evade external conflicts which disrupt everything we have going.
I have nothing against AML and Zack and I are friends.
I simply choose to never put something in my stuff that I cannot read backwards. I have trouble following Zack's shell maneuvering left to right lol.
I can guarantee you that Zack would never implement something he cannot follow, either.
When brainstorming solutions to those disruptions - AML being one of the primary ones, I really had no interest in maintaining something additional to the task at hand in this thread.
When the ACDB solution was prepared in my mind, I immediately went to Zack and laid everything out for him with my blessing that he could do whatever he wanted with it since it fit his niche, obviously. I gave him a week to make a decision before I would actually prepare it and utilize it in this testing phase as ruling out any disruptive variable in periods of testing such as this is critical.
It took a couple dozen revisions to get to where it is now, but I simply could not be happier than I am now with the results. Maintenance is nearly non-existent and development will likely be limited only to enhanced support such as multiple effects in a single acdb.conf as well as support for proxy effects. Other than that, it's a wrap.
The fact that something like AML and ACDB can ever be necessary is something that has always irked me and I was convinced that things like these would never catch on - due to laziness, unawareness, who-gives-a-****ness...
But, I feel ACDB right now has the best chance of catching on than anything else similar. And that is because using this small little file guarantees sufficient and consistent audio effect configuration for the dev requiring, quite possibly, the smallest effort of all tasks completed to provide a product.
And it's so simple and straightforward that users can easily place a completed acdb.conf into a module if the dev doesn't do so.
It cannot be any easier than this. I've tried really hard to find anything easier than this and this is it.
Lastly, having two separate components such as the ACDB module and the acdb.conf files fosters effortless testing of different configs on the fly with no reason to ever do anything outside of the acdb.conf file.
Try it out and test it like I just described. I think you will be very amused with how much effort normally spent targeting, copying, and patching configurations simply disappears lol.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
231Release Candidates for 9.0+ begin on page 458 and on Telegram.
The troubleshooting guide for Release Candidates is in this post.
updated 20200206
YouTube™ Link!
"Listen to the Dolby Atmos™ Difference!"
Dolby Atmos™
for
Android Oreo
Description:
- Dolby Atmos™ Digital Signal Processer with effects and Graphic User Interface ported from the latest ZTE™ Axon 7 Android Oreo firmware intended for all Android devices on Android Oreo.
- Dolby Atmos™ sound effects applied to media audio output supporting various media players.
- Flexible custom recovery installation archive supporting Magisk and SuperSU installations as well as existing audio mod installations - fully supporting Enforcing SELinux Mode:
- Multiple installation scenarios available using the included arise_parameters.prop that is automatically copied to /sdcard if not already there. When edited by the user in this /sdcard location, arise_parameters.prop can:
- Instruct an installation directly to /system if a Magisk user prefers a /system installation over the Magisk module installation.
- Instruct a system-less module installation using /su if a SuperSU user with the system-less SuperSU installation prefers a module installation for a variety of reasons such as insufficient /system space to accommodate a /system installation or the convenience of a persistent installation unaffected by rom updates.
- Instruct an installation directly to /system if a Magisk user prefers a /system installation over the Magisk module installation.
- Multiple installation scenarios available using the included arise_parameters.prop that is automatically copied to /sdcard if not already there. When edited by the user in this /sdcard location, arise_parameters.prop can:
- An independent build maintained by @[B]Zackptg5[/B] fully integrated with Unity:
- Active accommodation of existing and future Magisk modules relevant to audio modification.
- Flashing the installation archive over a current installation results with an uninstallation of the Dolby Atmos™ Magisk module.
- @[B]Zackptg5[/B] explains the nuances a bit further here.
- Active accommodation of existing and future Magisk modules relevant to audio modification.
Details:
- A minimum of SDK 26 (Android 8.0) is required for installation to begin, else Exit 1 will abort the recovery installation activity.
- A root solution or a capable kernel is required in order to automate the execution of scripts during boot to allow the appropriate sepolicy rules necessary for Dolby Atmos™ functionality while in Enforcing SELinux mode.
- Third party audio effects and DSP's such as ViPER4Android (<--
link to @[B]docnok63[/B]'s solution :highfive may require some extra effort to allow processing due to Dolby Atmos' dependency on its output_session_processing music effect.
Instructions:
- Performing a backup of the /system partition in recovery is encouraged for users receiving a /system installation:
TWRP > Backup > Check System > Edit name, if desired > Swipe to perform backup operation
- Confirm device requirements are met and installation results are acceptable.
- Confirm an escape route is available in the event of unsuccessful device boot or unsatisfactory experience.
- Confirm successful download and location of downloaded archive(s).
- Boot to recovery > Install > *.zip > Swipe to perform installation operation > Advanced > Copy Log > Reboot
- Updating procedure is no different unless specified otherwise.
Additional Information:
Downloads:
- Android File Host (gh)
- Standard:
- Latest: 20180219[*]MD5: eb56b15a2f35bd87e7627652620a98ac
- Standard:
- Android File Host (Zackptg5)
- Unity:
- Latest: 20180220[*]MD5: 16d3397c43bc8ac20fb12f1b637a16cb
- Latest: 20180220[*]MD5: 16d3397c43bc8ac20fb12f1b637a16cb
- Unity:
Changelog:
Code:[B]Standard 20180219 -[/B] - Expiration met for the Dolby Atmos Demo Video component after confirmation of its lack for volume support indicated a native "bug" and not a porting shortcoming. - A reduction of 67MB, uncompressed, now totaling 15.49MB uncompressed, without the Dolby Atmos Demo Video component. - Abandonment of the recently introduced libsurround_proc.so library (suspect of recent audio unpleasantness) from the Nokia 6 Official Oreo build that was paired with that same firmware's Dolby Surround Sound Settings' menu as an additional apk that is currently still included and still in its trial period. - SUBSTANTIAL adjustments, additions, and improvements to every script - installation and boot scripts, the most comprehensive update for this shell component thus far. [B]Unity 20180220 -[/B] - Added the debloated apk.
Credits:
45Release Candidate 1:
• 32-bit and 64-bit installations from a single zip.
• Axon 9 Pro apk and effect library used in both 32-bit and 64-bit installations to provide the most consistent experience for all users.
• This allows 32-bit users to avoid the 3dB GEQ boost limit as well as any license check by Lenovo.
• Removed much of the verbose messaging during the installation.
• Refinements and minor corrections to every single script.
Procedure:
• Install ACDB 0.45 if not already installed.
• Uninstall any existing Dolby Atmos™ installation and reboot.
• Install RC1 in Magisk Manager or in custom recovery.
• Save installation log before rebooting.
• Apply your best effort to find a failure or force a failure of functionality by any reasonable means - deleting/overwriting something will not count, obviously.434141Android Oreo Database
/system/bin/audioserver <-- Drive link
- Purpose and Contribution:
- Introduced with Android Nougat, audioserver appears as its own binary after years of being a component of /system/bin/mediaserver in all Android firmware.
- Introduced with Android Nougat, vendor provided Dolby Atmos™ software audio solutions appear with a new media.dolby_memoryservice that is compiled into /system/bin/audioserver as well as a unique system library typically appearing as /system/vendor/lib/libdlbmemoryservice.so.
- These new components are crucial to a functional Dolby Atmos software solution and there is currently no known way of achieving any amount of success without them.
- While porting the very first Nougat Dolby Atmos system available, courtesy of ZTE™ Axon 7’s initial Nougat firmware image, I discovered this implementation and a functional port was finally available.
- However, using a Nexus 6 at the time, I was able to evade nearly all bootloop scenarios with much of what would cause a bootloop scenario for others.
- It took no time to determine that this new media.dolby_memoryservice component was going to be a challenge in achieving a viable Dolby Atmos Nougat port.
- To begin, results were determined: Successful device boot or Unsuccessful device boot.
- Stock firmware seemed to fare much better than custom firmware, even for just a single device.
- A pattern began to emerge for me when focusing only on the audioserver binary: Stock firmware had an audioserver file size range (21.50KB-21.53KB) and Custom firmware had an audioserver file size range of its own (21.58KB-21.60KB).
- Not a significant difference, unless you were looking for a difference.
- This assessment presented an effective predictibility of an installation scenario's success and failure with nearly 100% accuracy (nearly only because every possible scenario is not documented).
- This audioserver database is intended for those that have determined a single scenario as successful or as unsuccessful due to the native audioserver binary in their device’s rom being overwritten or symlinked over with the audioserver native to the ZTE™ Axon 7 Oreo firmware AND NOT A RESULT OF ANY OTHER FILE OR SCRIPT OPERATION!!
- Simply, those with success have the easier path requiring nearly no effort other than uploading the native audioserver from their firmware along with the firmware build.prop to the WIN audioserver folder.
- Those contributing to the FAIL audioserver folder with the native audioserver along with the firmware build.prop will only be able to do so after some personal testing to ensure the audioserver switching is the exclusive cause of an unsuccessful device boot after flashing the Dolby Atmos installation archive in recovery.
- Introduced with Android Nougat, audioserver appears as its own binary after years of being a component of /system/bin/mediaserver in all Android firmware.
:good: - Dolby Atmos™ Digital Signal Processer with effects and Graphic User Interface ported from the latest ZTE™ Axon 7 Android Oreo firmware intended for all Android devices on Android Oreo.
