Skip to content
New issue

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

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

Already on GitHub? # to your account

Audio quality will degrade over time until it eventually fails #27

Closed
thisandagain opened this issue Feb 16, 2017 · 6 comments
Closed
Assignees
Labels
Milestone

Comments

@thisandagain
Copy link
Contributor

Expected behavior

  • Should be able to play a long project with audio

Actual behavior

  • Audio quality begins to degrade until eventually it "cuts out" and will not resume audio playback until refreshing the page

Steps to reproduce

Operating system and browser

Mac OS 10.12.2 Chrome Version 56.0.2924.87 (64-bit)

@ed-cooper
Copy link

I didn't see anything out of the ordinary when running the project

Windows 10, Chrome 56.0.2924.87 (64-bit)

@ed-cooper
Copy link

Actually, I do see what @thisandagain describes, although I can't consistently reproduce it.

However, I only experience any issues if I switch to another tab whilst the project is playing.

So maybe this is a fundamental issue to do with how Chrome handles tabs running in the background?

@towerofnix
Copy link
Contributor

I'm also able to reproduce this, and, as @chooper100 said, only from switching between tabs.

@SillyInventor
Copy link

SillyInventor commented Feb 16, 2017

I am able to reproduce this by playing it 3 times in a row. I got degradation by running the program without sound a few times, and then adding in sound. As such I suspect an indirect source. A brief look at the memory usage shows a ~50mb leak every run with or without sound, but more concerning an increasing CPU usage.
image

Using Ubuntu 16.04, Chrome 56.0.2924.87

@thisandagain
Copy link
Contributor Author

thisandagain commented Feb 16, 2017

An event emitter leak would be my first guess, but we'll need to instrument the audio engine to track that down.

@SillyInventor
Copy link

SillyInventor commented Feb 17, 2017

Well, after checking the heap, I found there were a lot of gain nodes etc. owned by clones. By eliminating the forever clone loop in sprites 16 and 10 the problem was solved. This may be a result of poor clone disposal.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants