Browser performance issues, desktop spectrogram not working (Windows)

[BajekekButLost]

I've been using the desktop version for the last couple of months, and it was fine with good performance. When I updated yesterday, the spectrogram wasn't working. When I import the flac file, it's just blank (note: I tried with mp3 as well, same thing). So I tried using in in Zen (Firefox), and the spectrogram image did show up, only the playhead was lagging (although that's probably a Firefox thing). I tried two Chromium based browsers (Helium, Brave), and in both cases it worked fine, with the slight issue that when I was scrolling on the page or the spectrogram, my whole PC started exploding. The page starts lagging, my cursor starts lagging, and I can't do anything. Please fix.

[apoint123]

It looks like there might have been an issue when packaging the app; in the meantime, you can use the web version until we fix it: https://tool.amll.dev/

Regarding the audio stuttering issue, could you try uploading the audio file for us to check?

[Super12138]

I also met this problem on my laptop.
I use the latest CI version of AMLL TTML Tool, which runs on Windows 11, Microsoft Edge WebView 2(150.0.4078.83). It doesn't produce any error log of spectrogram components.

But in the browser which can render the spectrogram sucessfully, it produce error.

I guess, maybe it is caused by web worker in tauri or the version of MS Webview

Here's a sample audio.
Gentleman.zip

[apoint123]

Thanks for the detailed report and samples! We have identified and reproduced the root cause of this issue on desktop.

The spectrogram module utilizes wasm-bindgen-rayon for multi-threaded parallel processing.

1. When rendering the spectrogram, spectrogram.worker.ts initializes the thread pool by spawning nested module workers (workerHelpers.js).
2. On the desktop, static assets are served over Tauri's custom protocol (http://tauri.localhost).
3. Due to a unknown bug, network requests for scripts initiated inside an nested workers fail to be routed.
4. As a result, the request for workerHelpers-xxx.js hangs indefinitely in a Pending state, preventing the WebAssembly multi-threading pool from initializing.

This explains why the spectrogram works fine on standard Web browsers (which run over standard HTTP/HTTPS servers), but hangs silently on the desktop app without throwing explicit JS error logs. (Those console errors you showed are actually false positives that I just haven't had time to fix)

I suspect this is currently an upstream bug and I'm not sure how to fix it within this project. I could disable thread pool initialization, but that would significantly hurt performance, so I would recommend using the web version for now.

[Super12138]

Thanks for the detailed investigation of this issue! I really appreciate about your clear explanation for this issue!
I will use the web version instead.
Besides, if you need further confirmation or more information of this issue, I'm glad to assist!

[apoint123]

Confirmed a upstream bug: MicrosoftEdge/WebView2Feedback#4926