-
Notifications
You must be signed in to change notification settings - Fork 45
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
Playing a StreamingSoundData
intermittently plays a scratchy, sped-up version of the sound
#36
Comments
I'm not able to reproduce the issue. What operating system is this on? Does the problem still occur if you set That "scratchiness" sounds to me like Kira can't fill the OS's audio buffer fast enough, which would make sense for an unoptimized build, but that doesn't explain why the music is playing back faster than normal. If anything, I'd expect it to play back slower. I think there might be some part of Kira that isn't getting optimized even though you have optimization turned on for dependencies because of some generic functions that get compiled as part of the main crate, but that's pure speculation on my part. |
This is on Debian Sid (
That's about what I expected, but I figured I might as well ask here just in case.
This might be part of it. I don't believe there are any generic functions between the main crate and Kira (at least in the state shown in the video), but I am using a trait object to store game states. |
Hi again, I could not reproduce the issue on Debian Bullseye. When playing a hundred or so copies of the streaming sound, I got underruns, but I didn't observe the sped-up playback you did. I just got normal playback, but with regular pauses. I'm guessing the Linux kernel version isn't relevant here, but I could be wrong. Not sure what else to try to reproduce the issue. |
I tried playing this audio file as a
StreamingSoundData
with a loop point of 7.0. Occasionally, this would work, but sometimes, it would come out as a scratchy mess:2022-12-11.12-37-30.mp4
Upon closer inspection, this seems to be a sped up version of the track. Sometimes this issue would correct itself at the loop point, but occasionally, it continues forever.
Thus far, I've only been able to reproduce this issue in debug builds (with optimized dependencies). Release builds seem to be unaffected.
The text was updated successfully, but these errors were encountered: