Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

seems to start lagging after being used for a while #32

Closed
mmckegg opened this issue Dec 4, 2014 · 9 comments
Closed

seems to start lagging after being used for a while #32

mmckegg opened this issue Dec 4, 2014 · 9 comments

Comments

@mmckegg
Copy link
Owner

mmckegg commented Dec 4, 2014

also on stable chrome, sometimes will just crash when it all gets too much, although in canary it doesn't crash, but the lag seems to be worse.

mmckegg added a commit that referenced this issue Jan 8, 2015
@mmckegg
Copy link
Owner Author

mmckegg commented Feb 20, 2015

hopefully this is a lot better in v2

reduced CPU usage of oscillators and envelopes.

dropouts are caused by audio thread CPU usage exceeding 100%.

missed schedules are due to garbage collection time + scheduling time exceeding frame length

@feross
Copy link

feross commented Apr 17, 2015

Yep, I just ran into this. Over time, the chance of getting a drop out seems to go up. After a while, it's basically impossible to continue without a restart, and the music sometimes even completely stops. CPU at 100%.

Btw Matt: I got a Launchpad Mini and this is so much fun!! Amazing project.

@feross
Copy link

feross commented Apr 17, 2015

Even if you reset all active loops and start over just adding a few beats, it seems to overwhelm the CPU like there's a bunch of extra work being done that wasn't happening when I first started.

@mmckegg
Copy link
Owner Author

mmckegg commented Apr 17, 2015

Yeah, it almost seems like something isn't being cleaned up properly. I think it's in the audio thread though.

@feross
Copy link

feross commented Apr 21, 2015

Anecdotally, the lag starts to happen after I've been using button 5 (Beat Hold).

@feross
Copy link

feross commented Apr 21, 2015

The only solution seems to be to restart Loop Drop when this happens.

@mmckegg
Copy link
Owner Author

mmckegg commented May 30, 2015

I found that Chrome 43 (and 44) seemed to be particularly bad. Could only hold down about half as many triggers before hitting the limit.

But Chrome 45 (current canary) seems to be working even better than 42, and doesn't seem to have the same problem with garbage collection dropouts. So this is great 😄

I'm really hoping that a lot of the performance problems will just fix themselves over time 🙏

@ahdinosaur
Copy link
Collaborator

@mmckegg you might be interested in this thread on how to control the v8 garbage collector with cli params: nodejs/node#3370, although you might already be aware of these things.

For a kitchen sink example with arbitrary values:

node --gc_global --optimize_for_size --max_old_space_size=960 --use_idle_notification --always_compact --max_executable_size=64 --gc_interval=100 --expose_gc server.js

@mmckegg
Copy link
Owner Author

mmckegg commented Jan 2, 2016

okay so Chrome 47 has done some magic, and this doesn't seem to be a problem anymore! Hurray!

🎉 🎈 🌈 🌟

There are still a few glitches, but they are no longer seem to be getting worse over time, instead they're just garbage collection related most likely.

@mmckegg mmckegg closed this as completed Jan 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants