Spectrum Analysis

35 views
Skip to first unread message

Slm Dn

unread,
Sep 1, 2026, 4:49:45 PM (3 days ago) Sep 1
to DroidScript
Hi everyone,

I’m having an issue with the ViviaAudio plugin and spectrum analysis.

I have a DroidScript app that uses ViviaAudio to get FFT, RMS and Peak data from the audio currently playing with a DroidScript MediaPlayer.

The code works perfectly when I run it directly inside DroidScript, but when I build the app as an APK and install it on the same Android device, the spectrum analyzer no longer works.

I have already added these permissions:

_AddPermissions("Media");
_AddPermissions("Network");
_AddPermissions("RecordAudio");
_AddPermissions("ModifyAudioSettings");

And I initialize ViviaAudio like this:

app.LoadPlugin("ViviaAudio");

plg = app.CreateViviaAudio();
plg.Start();

Then I read the analyzer data:

var fft = plg.GetFFT();
var rms = plg.GetRms();
var peak = plg.GetPeak();

The MediaPlayer itself can play the song, but after building the APK, ViviaAudio does not seem to receive/analyze the audio.

I’m testing this on Android 14.

Does anyone know if ViviaAudio requires any additional permission, manifest setting, APK configuration, or special setup when building the DroidScript project as an APK?

Why would ViviaAudio work inside DroidScript but not in the compiled APK?

Any help would be greatly appreciated. Thanks!

Dave

unread,
Sep 3, 2026, 12:42:21 PM (24 hours ago) Sep 3
to DroidScript
Where did you get the ViviaAudio plugin from, I'm not aware of that?

Slm Dn

unread,
Sep 3, 2026, 1:05:15 PM (24 hours ago) Sep 3
to DroidScript
Hi Dave,

I managed to solve the spectrum analyzer issue. It was related to the APK/build environment, and the spectrum analyzer is now working correctly in the compiled APK as well.

I’m actually developing a music player application with DroidScript. DroidScript handles the music playback and music management, while I’m using an HTML/JavaScript interface as the UI and remote control for the player.

As I’ve been adding more features, I’ve started running into performance problems, especially in the HTML interface.

DroidScript is continuously sending data to the HTML/JavaScript side, and as the application has become more complex, this constant communication seems to be causing significant performance loss in the HTML UI. This is particularly noticeable with real-time features such as the spectrum analyzer, where the interface needs to be updated frequently.

Do you have any recommendations for optimizing the performance of the HTML/JavaScript side in DroidScript?

In particular, I’d be interested in best practices for:

- Reducing the overhead of communication between DroidScript and the HTML interface
- Avoiding unnecessary data transfers or UI updates
- Optimizing DOM manipulation and rendering
- Handling frequently updated real-time data such as FFT/RMS/Peak values
- Structuring a larger HTML/JavaScript UI so that it remains responsive as more features are added

I’d also be interested to know if there are any DroidScript-specific techniques or common performance pitfalls I should be aware of when using HTML as the UI for a DroidScript application.

Thanks!

3 Eylül 2026 Perşembe tarihinde saat 19:42:21 UTC+3 itibarıyla Dave şunları yazdı:

Dave

unread,
4:57 AM (8 hours ago) 4:57 AM
to DroidScript
Hi, sounds interesting, but you never said where the ViviaAudio plugin came from.. is that yours?

Re. speed optimisation - if you are making many rapid calls across the JS->Java bridge, ie. any app.* calls, then the biggest improvement will be to disable the automatic debugging during that phase.

app.SetDebug( false ) --> block all debugging.
app.SetDebug("console") --> just allows your console.log() calls to show up

If the transferring of FFT/RMS data out of the plugin is causing a major slowdown, you could think about doing the FFT/RMS on HTML side using WebAudio or pure JS instead.   You could also experiment with using WebSockets on the 127.0.0.1 loopback address to communicate between the two sides instead of using the bridge.

If your app is mostly living in the DOM/HTML world, then the best way to improve performance and portability is to keep everything in the HTML/DOM side and use a combination of WebAudio and HTML Canvas, only rarely making app.* calls when absolutely necessary.  Porting things across might sound daunting, but you'll be amazed at how helpful Codex or Claud can be for that sort of thing.


Slm Dn

unread,
10:14 AM (2 hours ago) 10:14 AM
to DroidScript

Hi Dave,

I actually wrote the ViviaAudio plugin myself. I created it specifically for this project to get the FFT, RMS and Peak data from the audio being played by DroidScript’s MediaPlayer.

I also noticed a significant performance improvement after setting:

app.SetDebug(false)

It made a surprisingly noticeable difference, especially when the application is doing continuous audio processing and UI updates.

There is another issue I’ve been investigating. When using Web Audio for some of the audio-related processing, I sometimes get small audio glitches in the background, such as slight stuttering, clicks, or hiss. It seems to become more noticeable when the application is doing other work at the same time.

Do you think running the relevant audio processing through a foreground service would help with this kind of problem on Android? Or would you recommend handling it differently in DroidScript?

I’m trying to keep the audio processing stable while the HTML/JavaScript interface continues to handle the UI and real-time visualizations.

Thanks!


4 Eylül 2026 Cuma tarihinde saat 11:57:34 UTC+3 itibarıyla Dave şunları yazdı:
Reply all
Reply to author
Forward
0 new messages