performance decrease since last tar.gz upload

[kindohm]

Has much changed in the basics of how audiolib.js runs or is used since about two months ago? I've been building demos and have been learning with the downloadable library in the tar.gz that was posted about two months ago. I just built audiolib.js from source today and updated the audiolib.js files in my demos - and have noticed a considerable amount of new latency or dropouts that I didn't experience before. After rolling back to my previous copies of audiolib.js the latency and dropouts go away.

I admit I haven't been a contributor to this project and honestly a lot of the code is beyond my skill level. Thus, I don't really have a good understanding of what has changed in the last two months or what may be causing the performance issues.

I guess I'm just curious if I'm doing something fundamentally wrong in my apps or if performance issues have actually been creeping in to the source over the last couple of months. I'd be glad to take a look and try to make some fixes if there are any known issues that need help.

-Mike

[jussi-kalliokoski]

Hey there,

On which browser(s) is this perceivable? Not much has changed within audiolib.js, aside from new modules and bug fixes.

sink.js on the other hand has changed quite a lot, so the issue might be there. However, I haven't profiled it for a while, so I'm not sure what has happened. Most of the changes to sink.js have been bug fixes, reliability boosts (underrun recovery) and memory optimizations (reusing arrays), and they should actually all contribute to less dropouts.

Now that I profiled it, however, it seems to take an awful lot of processing power on Firefox compared to what it used to. Chrome on the other hand is using vastly less than it used to. I've added an issue to sink.js for this, and will try to fix it ASAP.

[jussi-kalliokoski]

Oh, and thanks for reporting! :)

[kindohm]

I noticed this in Chrome - which is strange since you've observed better performance in Chrome. I didn't try the same test in Firefox though (old drop of audiolib.js versus latest build from source). I'll give that a shot and let you know what I observe.

[jussi-kalliokoski]

Strange... Looks like sink.js uses about 1-2% when outputting silence on both Chrome and Firefox, so maybe the reason is elsewhere. Could you run a profiler on your page and put a screenshot up for it? Would probably help in finding the source of the problem quite quickly.

[kindohm]

Here's a screen shot of the profile along with the source: http://ge.tt/8wwc0sD

In addition to the profile output, there are three main qualitative observations I am making with this code:

1) Latency with the UI. When I click the "play" button in my code, there is more latency before I hear the sound than before. I've noticed this with both the buffer-based and sample-based oscillators.

2) A noticeable, quiet click or noise that plays at a regular pulse (e.g. like a metronome) when the oscillator is not filling the buffer.

3) A noticeable, short dropout or click at a regular pulse when the oscillator is filling the buffer and a since wave is playing.

I tried the same code in Firefox and I did not observe the click or pulse issues. Latency felt better, but still noticeable compared to in the past with Chrome.

[jussi-kalliokoski]

Thank you very much. As I suspected, the profiling actually showed unexpected results, as most of the processing power is used in functions that shouldn't be firing in the first place. Namely, WAV conversion. What it means is that Chrome seems to be accidentally using the suboptimal WAV Data URI backend instead of the Web Audio API backend.

Moved this issue here.

[jussi-kalliokoski]

Thanks a lot for reporting, this was indeed a bigger issue than I initially thought, would've been a shame if it got through to a release. Should be fixed now, though. :)

[kindohm]

Great - I'll check it out later today/tonight.