-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix audio resampling functionality #7858
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
Conversation
AudioResampler6bb4aed to
0ede71a
Compare
The quality settings can conflict with an instrument's choice of interpolation. For example, one instrument may only work with a fixed set of interpolation modes that do not necessarily align with the interpolation modes specified by AudioResampler. AudioRessampler works with some modes like SincBest, but some instruments may not have that mode, so theres a conflict. It is simpler and safer to allow instruments to determine what interpolation mode they will use.
Lots of double backing, but probably should wait for a refactor for the current code architecture and stuff to see how the playback loops fit into everything.
szeli1
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have reviewed this PR and I didn't find anything wrong with the code.
I tested this PR by importing sample clips and I found the following:
I got this message every time I imported something:
qt.accessibility.atspi: WARNING Qt AtSpiAdaptor: Accessible invalid: QAccessibleInterface(0x5562060aeb00 invalid) "/org/a11y/atspi/accessible/2147484886
szeli1
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving this PR. (tested with 8000, 11025, 16000, 22050, 32000 and more sample rates)
Doesn't seem related, though I don't think I've seen this error before. Might be something specific on your machine, not sure.
Thanks for testing! |
messmerd
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me code-wise
Co-authored-by: Dalton Messmer <[email protected]>
|
Thanks for the review @messmerd! |
|
Ready to merge? |
Basically, but @bratpeki is interested in doing some final testing. |
|
Tested PATs, GIGs, SF2, AFP and SlicerT on 192, sounds great. Please (finally) merge! 🎉 |
Co-authored-by: Dalton Messmer <[email protected]>
This PR improves the usage of libsamplerate when resampling.
Changes:
Redirect all libsamplerate usage to
AudioResampler. This ensures we are always using libsamplerate with the same resampling logic, preventing bugs.Call
src_processas many times as necessary to resample all of the source audio we need to fill up the destination buffer. Before, LMMS was only callingsrc_processonce, and assumed that libsamplerate always read all of the input data it gave it, which isn't necessarily true and can cause input frames to be dropped. Any input frames not read in the current iteration are stored within a small array and will be used on the next call tosrc_process.Remove the use of buffer margins. This was needed to accommodate for libsamplerate's transport delay, but this involved expensive copies and allocations, and the margin added may not be adequate depending on how long the transport delay needs to be, which wasn't accounted for. To fix this, we allow the transport delay to occur on the onset of when
AudioResampleris first used, which then the delay will be removed on subsequent resampling.Remove the choice to choose an interpolation mode when exporting. This can conflict with the interpolation mode specified by the instruments and their APIs, so it was removed.