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

Output volume #27

Open
mdabbs opened this issue Feb 13, 2024 · 6 comments
Open

Output volume #27

mdabbs opened this issue Feb 13, 2024 · 6 comments

Comments

@mdabbs
Copy link

mdabbs commented Feb 13, 2024

It appears that the output volume is significantly less that the original volume? Is this by design? I don't understand the math enough to know if this is by design or if the volume is being lost somewhere in the computations.

@marcelblum
Copy link

Yeah it seems to be a consequence of the processing, what I have unscientifically found to work best is to boost the volume using pre- and post-GainNodes both set to a value of 1.6.

@mdabbs
Copy link
Author

mdabbs commented Feb 14, 2024

I can understand why it's there in the handleOutputBuffersToRetrieve function where it divides by the number of overlaps. Logically, the same signal added to itself nbOverlap times should be divided back down. But from my experience with digital audio, mixing signals usually doesn't require a shift down.

I'm not scientifically or mathematically inclined, but from a logical standpoint, would it makes sense to maybe keep something like an RMS value for each WEBAUDIO_BLOCK_SIZE window, and then normalize each block as it goes out to about what it was when it came in? I may give that a try, but I wonder if the perceived volume would jump too much and be too perceptible to the human ear?

@marcelblum
Copy link

Honestly crunching all these numbers in pure JS is so cpu intensive as it is, I wouldn't want to pile on any further computation, which is why I settled on using a simple pregain/postgain to compensate.

@mdabbs
Copy link
Author

mdabbs commented Feb 16, 2024

Sorry, one more question if you don't mind. The fft and ifft, are those standard? I'm porting this to c++. Could I substitute something like fftw instead? From some basic profiling, it looks like transform4 and realTransform4 are really taking the bulk of the time.

@marcelblum
Copy link

Full disclosure, I'm not a maintainer of this project just a tinkerer who forked it. I'm not sure why you would want to port this to c++ as there are surely better existing implementations (Rubber Band comes to mind), this is just a rough implementation using web standards within the limits of current browsers. But yeah, in theory you should be able to use a better/faster existing FFT library, not sure how much of a drop in replacement it would be.

@mdabbs
Copy link
Author

mdabbs commented Feb 17, 2024

Yea, I've looked at Rubber Band but it has commercial licensing restrictions. I just need something for a media player/karaoke app, but since I might make mine commercial also, I need something less restrictive with licensing. Also, I really just want to understand more of how it all works, so I'm a fellow tinkerer as well. I appreciate the discourse though.

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

No branches or pull requests

2 participants