Audio files distort inside Godot when using a Focusrite DAC

[fkeyzuwu]

---

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version

Godot 4.0 stable

System information

Windows 10

Issue description

I have been having inconsistent bugs with audio files being played weirdly in Godot, as if Godot can't read them correctly.

I made a project that worked completely fine, and then in some way when I switched some audio files the audio started stuttering. I tried many different formats but nothing really worked. This can happen both when you preview the sound in the inspector and in game. Switching to a new project, with the same file, the audio worked fine again for a few minutes until it started stuttering again. So I think its more about the engine somehow messing up with how it reads the files. Reopening the projects seems to fix this sometimes.

I tried recreating what could make this happen but couldn't really find a reason, but its still happening, with old/new projects, although again inconsistently changing between stuttering and working normally, with all types of files.

I tried with 32bit float, 24bit int, and 16bit int .wav files, mp3 320kbps, all at 44.1khz.

Obviously the files themselves are not corrupted as if you play them externally they sound just fine. My audio is fine anywhere else outside of Godot, so I don't think its a problem with my setup.

Steps to reproduce

Just try dragging in audio files into Godot and preview them in the inspector, see if anything happens I guess. As I said, this is pretty inconsistent so I don't know how to reproduce it. It happened to me in a brand new project, as well in a project that I have been working for a few hours on.

Currently I can't reproduce it for some reason, if it comes back again ill try recording it.

Minimal reproduction project

N/A

[Calinou]

• Related to Opening the program makes my desktop audio start popping due to adb running in the background #74779 and Distorted sound on Windows with Corsair or SteelSeries Wireless Headset #25875.

Are you using Bluetooth audio with microphone enabled? This limits audio output to mono and will greatly decrease its quality.

[fkeyzuwu]

No, I'm using good quality wired headphones and speakers with a Focusrite mini audio interface. I'm not talking about mono signal. When it happens, it sounds like the file is "half corrupted", meaning the information you hear is still some what related to the original signal, but is weirdly distorted. And again, hearing anything else outside of Godot works completely fine, I A/B tested it in real time. Hopefully I'll have something to show for when this happens again and I record it.

This doesn't seem to be related to these other issues you mentioned imo.

[Psiice]

I'm having the same issue. I'm using Godot 4.0.1 Stable. Headphones are wired and no audio issues outside of Godot. I tried mp3 wav and ogg. Every format is working fine on windows10 media player or VLC media player. As soon as i import them to Godot the Audio is laggy/crackling on the prewiev and on AudioStreamPlayer and also in-game

Edit:
i tried using my cheap wireless headband hedphones and for my surprise the audio lagging/cracking is gone.
my main headphones are going through a scarlett 2i2 (3rd gen) audio interface which sample rate is set to 44100 and the Buffer size was 512. Reducing the Buffer size to 256 solved my problme inside Godot

[fkeyzuwu]

I'm having the same issue.

Edit: i tried using my cheap wireless headband hedphones and for my surprise the audio lagging/cracking is gone. my main headphones are going through a scarlett 2i2 (3rd gen) audio interface which sample rate is set to 44100 and the Buffer size was 512. Reducing the Buffer size to 256 solved my problme inside Godot

This is the exact problem I'm pretty sure. I also had the problem reoccur to me, and when switching from 512 to 256 buffer size the audio stopped stuttering. I have a Scarlett mini. this might have to do specifically with Focusrite products, needs checking.
This also happens with exported godot games made on godot 4.0.x, I figured this out because I entered the Godot Wild Jam where I'm sure most of the people used godot 4.0.x. all their games had that problem on my pc, and ours which was made on godot 3.5.2 stable didn't have that audio stuttering problem regardless of the buffer size.

Video attached here. Notice that there are some stutters even when being on 256 buffer size.

Untitled.design.mp4

@Calinou

[yaboigraves]

I can attest to this possibly being related to focusrite products, I have a scarlet 2i2 and get the exact same audio corruption usually until a pc restart

[MJacred]

@Psiice, @fkeyzuwu, @yaboigraves did you also test without scarlett (the usb audio interface) and directly connecting the (good) headphones to your computer? (And I don't mean wireless/bluetooth)

[MrBlockers]

I am also running into this issue; when Godot output is through my Focusrite 2i2, the sounds played from Godot are inconsistently distorted (in a bitrate way).

Plugging into and using any other standard audio outputs on my PC makes the issue go away. My audio files are all Mono 16 bit 44100 Hz .WAV files.

[MrBlockers]

I fiddled around a little bit this afternoon, I was able to fix the distortion by going into Focusrite Control and setting the sample rate (under Device in the toolbar) to 44.1 kHz. the default setting is 48 kHz. Edit: I also found that playing the same files in Audacity with the 48kHz samplerate produced the same distortion, so I am inclined that this is not really godot's fault.

[vinyllie]

@MJacred

I am encountering this issue as well, with the Focusrite Scarlett 2i2, and can confirm that when plugging directly into my computer the audio is fine. Setting the Scarlett's sample rate to 44100 did not help, although strangely setting it to 192000 did make the audio in Godot no longer bug for the moment. However, this bugs out all of my other audio software, meaning I'll have to switch back and forth a bunch.

[moehnked]

hey. been running into this issue a lot.
Audio sounds like its cutting out and stuttering, happens frequently but at unpredictable times. Happens in game when the game is running, but it also happens in editor when playing an audio file

audio_issue_short.webm

Here is an example of the waveforms of a recording, showing gaps in the audio:

I have a Steinberg brand UR22mkII USB audio interface that my headphones are connected to.
Reducing the buffer size the driver settings from 512 to 256 seems to have improved the issue, as well as seeming to improve the overall smoothness of the game. However, the stuttering still occurs, just much less frequently

[fkeyzuwu]

@Psiice, @fkeyzuwu, @yaboigraves did you also test without scarlett (the usb audio interface) and directly connecting the (good) headphones to your computer? (And I don't mean wireless/bluetooth)

Sorry, didnt see your message. but no, It doesn't happen while directly connecting my headphones to the pc.

Is anyone looking at solving this problem? I would assume it should be relatively high importance. Depending on severity it can happen very commonly, and be almost unfixable(for me changing the buffer size doesn't guarantee it being fixed 95% of the time). Also might be happening on other audio interfaces as implied by @moehnked. And as I said, this is not a problem with JUST the editor, it also happens on exported projects, meaning pretty much any project that is out from this Godot version onwards will very likely have this problem. It can pretty much make the game unplayable with audio for some people. It's also worth mentioning that these Focusrite audio interfaces are very common.

[yaboigraves]

@Psiice, @fkeyzuwu, @yaboigraves did you also test without scarlett (the usb audio interface) and directly connecting the (good) headphones to your computer? (And I don't mean wireless/bluetooth)

Without using my scarlet 2i2 and just using my PC soundcard this does not occur ever.

[Calinou]

Is anyone looking at solving this problem?

We have relatively few audio contributors (I am not one of them). Also, not all of them have access to a Focusrite DAC (which isn't cheap for something you'd buy just to fix a bug).

What's the cheapest Focusrite DAC on which the issue has been confirmed?

[yaboigraves]

scarlet 2i2 i believe is the cheapest model, I'd honestly be willing to be put in contact with an audio engine dev who's interested in tackling this and shipping them mine to borrow, as I have a 6i6 I use for daily work anyways. Worth a shot I suppose!

[MJacred]

Including this issue, I'm aware of 3 other issues that sound very similar. All of them have in common that there is another audio-related process running. And that the issue popped up between v4.0-beta 14 and 15 (source). @Calinou referenced the Engine commits here. They are an excellent starting point for the investigation.
Therefore, if I'm not mistaken about the issue relations, it should be possible to find and solve the issue without requiring an audio interface. Unless proven otherwise.

In turn, this means that also non-audio engine devs can bisect the regression and look out where audio code was touched. Anyone who can compile the engine from source can greatly help fixing the root cause!

[crashfort]

This issue happens no matter what sample rate you are using in the project settings and no matter what sample rate you are using in the Focusrite settings. This is an isolated bug in Godot since this stuttering issue only happens inside Godot and programs made by using Godot (ie, using Godot code). I have been using a Focusrite device for over 5 years and Godot is the only place where this issue happens, which makes it safe to say that this is not any external issue or user error. I have worked on and developed low latency audio playback software and never came across this issue either (while using a Focusrite device with latest Focusrite drivers).

Changing the sample rate inside the Focusrite settings is not a fix, it only resets the Windows output device, and Godot probably catches that event. It will still slowly drift away and it will start stuttering again which makes this seem like an accumulation error (such as missing a loop somewhere when feeding the output device).

This issue does not appear when not using a studio audio interface (for example BT headphones), which makes me think that the Godot code makes big assumptions about the output device in the audio code that is not correct.

[crashfort]

Ok an update. I did some work on this today and I believe that I have resolved this issue in my local build. Back to back testing with the official Godot 4.1 build and my local build, also testing with different Focusrite sample rates and the issue does not appear in my local build, while it occurs in the official build.

I have also tested with BT headphones and it also works there.

I modified the WASAPI driver quite a bit to resolve this issue. I also looked at the XAudio2 implementation but it doesn't build (probably why it is excluded from the build also), so I will not touch that. But I am very certain this issue would not have happened in the XAudio2 implementation if it was used for speaker playback.

[Calinou]

Great work 🙂 Could you open a pull request on master with your changes, please?

I also looked at the XAudio2 implementation but it doesn't build (probably why it is excluded from the build also),

The XAudio2 driver has been disabled by default for a long time, so it probably bitrot over time.

[ScarfKat]

@ScarfKat: You'd need to download the Godot engine source code and use your system's console/terminal to apply this patch. Maybe a code editor can do this using GUI. As this repo uses git for version control, here is an explanation https://stackoverflow.com/questions/2249852/how-to-apply-a-patch-generated-with-git-format-patch (and here the official docs: https://git-scm.com/docs/git-apply). And then you'd need to build Godot from source with that patch: https://docs.godotengine.org/en/stable/contributing/development/compiling/index.html

EDIT: for further technical questions, it's best to ask the community in one of these places: https://godotengine.org/community/

Got it. And I'll ask any further technical questions there, thanks.

[ptlthg]

Changes-On-f15ced.patch Note that it's a simple test and I've removed audio input from the callback just to check output.

I can confirm this fixes the audio crackling for me with a Scarlet Solo gen 3. Not very scientific, but I just imported a WAV into a blank project and played it from the inspector. Got some crackles/pops within 10 seconds without the patch, then no crackling for the entire 90-second clip with the patch.

This issue has been bothering me while developing, so it's great to see more progress on this issue. Thanks everyone!

[AlexOtsuka]

I might have figured out the actual issue at hand. In fact, if I'm correct, it is so incredibly trivial that it's almost sickening.
While updating the code to make use of the superior event callback features is the proper long term plan, I believe the issue was actually somewhere else entirely.

UINT32 write_frames = MIN(ad->buffer_frames - cur_frames, avail_frames);

ad->buffer_frames is not the maximum available buffer size when using IAudioClient3. This is easily proven by calling GetBufferSize(). For example in my case, I had a buffer_frames value of 441 while GetBufferSize() would return 970. The main problem with this is that it seems like the current padding value can sometimes exceed ad->buffer_frames, causing GetBuffer() to glitch out.

This also explains why the patch seems to work perfectly. By fully omitting checking for the padding frames, issues would only occur if and only if the avail_frames value is larger than max buffer size - padding, which rarely happens (but still does sometimes, in my testing).

Please test this out as much as possible by building my fork https://github.com/AlexOtsuka/godot/tree/audio-fix. This is current master, but you can also apply the exact same changes to 4.2.1. I'm submitting this as a PR as it is an exceedingly simple fix that makes for a perfect cherry-pick, but I'd still like to have as many confirmations as possible that this works for everyone.

[alessandrofama]

Yes, GetCurrentPadding still needs to be called for shared-mode streams with AUDCLNT_STREAMFLAGS_EVENTCALLBACK, was a mistake in the patch.

[AlexOtsuka]

Yes, GetCurrentPadding still needs to be called for shared-mode streams with AUDCLNT_STREAMFLAGS_EVENTCALLBACK, was a mistake in the patch.

I figured as much, but couldn't get your patch to work by subtracting padding. This, and going through #81938 and trying to make it compatible with IAudioClient3 are what clued me in, so thank you very much for your contribution!

[jauwnio]

@AlexOtsuka Just tested with a previously problematic project on my Focusrite Scarlett 18i8. Absolutely zero crackling. Fantastic fix!!

[akien-mga]

Please test this out as much as possible by building my fork https://github.com/AlexOtsuka/godot/tree/audio-fix. This is current master, but you can also apply the exact same changes to 4.2.1. I'm submitting this as a PR as it is an exceedingly simple fix that makes for a perfect cherry-pick, but I'd still like to have as many confirmations as possible that this works for everyone.

Now that there's a PR, this is more straightforward to test, by downloading the Windows editor artifact from the PR here: https://github.com/godotengine/godot/actions/runs/8204422959/artifacts/1309510801

It would be great if several affected users could try it out and confirm it fixes their issue.

[joesondow]

I've compiled all the people here who have reported the audio bug with their devices. Anyone who is still able to reproduce the bug with the latest public Godot version 4.2.1, please try out AlexOtsuka's fix and post a comment to let us know if it clearly fixes the audio bug on your device.

To get the build with the PR 89283 fix in it, go to
https://github.com/godotengine/godot/actions/runs/8204422959/
Scroll down to artifacts. Select "windows editor".

I'm updating this comment with results as they come in.

Reminder: if you've updated drivers or something so you can no longer reproduce the audio bug, then there's nothing for you to test now, but thank you for your help earlier.

Edit May 2024: The fix is now in Godot 4.2.2 and later as well.

PR 89283 Result	User	Device
✅Approved	@jauwnio	Focusrite 18i8 3rd Gen
not tested yet	@fkeyzuwu	Focusrite Scarlett mini
not tested yet	@Psiice	Focusrite Scarlett 2i2 (3rd gen)
not tested yet	@yaboigraves	Focusrite Scarlett 2i2
not tested yet	@MrBlockers	Focusrite Scarlett 2i2
not tested yet	@vinyllie	Focusrite Scarlett 2i2
✅Approved	@moehnked	Steinberg brand UR22mkII
not tested yet	@crashfort	Focusrite
not tested yet	@justhereforaquestion	Asus Xonar DSX sound card
not tested yet	@stilestr	Focusrite 18i8
not tested yet	@Ansraer	Sennheiser GSP 670
not tested yet	@cjmaxik	Steinberg UR12
not tested yet	@cjmaxik	Steelseries Artics 7
can no longer test	@lander-vr	Motu M2
not tested yet	@Sunriser45	UMC22 Beheringer
✅Approved	@ScarfKat	SoundBlasterX G6
✅Approved	@rsletta	Focusrite Scarlett Solo (2nd gen)
not tested yet	@braydenplumb	Focusrite Scarlett 2i2 (3rd gen)
not tested yet	@jefvel	3rd gen focusrite 8i6
✅Approved	@j-s-c-o	Motu M4
not tested yet	@newobj	RME digiface
not tested yet	@MayniYT	Steinberg UR22C
not tested yet	@OddlifeDev	Focusrite 4i4
not tested yet	@DennisVoelk	Focusrite Scarlett Solo 3rd gen
✅Approved	@loki3323	Focusrite 2i4 Gen1
not tested yet	@colinmbo	Focusrite Scarlett 2i2 Gen 2
not tested yet	@StaticNS	Scarlet 2i2 (3rd Gen)
not tested yet	@jordachemac	EPOS H3Pro BT headset
✅Approved	@p3tina	Focusrite iTrack Solo
can no longer test	@XanderMassonov	Focusrite 3rd gen 2i2
✅Approved	@Jewelots	focusrite scarlett 2i2
not tested yet	@AdventurousDrake	MOTU M2
✅Approved	@yongan-game	M-Audio M-Track Solo
not tested yet	@coppolaemilio	Focusrite 2i2 Second gen
not tested yet	@nico-elsewhere	focusrite 6i6
Implemented	@AlexOtsuka	Focusrite 2i2 3rd gen
✅Approved	@ptlthg	Scarlet Solo gen 3
✅Approved	@LuisEscorza	Focusrite 4i4 3rd Gen

[akien-mga]

Thanks to everyone involved debugging this!

I merged the PR already has the first results seem good and the code change is trivial, but please keep updating this issue to confirm whether your issue did get fixed. You can test the PR artifact as described above, or test with the upcoming 4.3 dev 5 which should have this commit (no ETA for that snapshot, GDC will keep me busy the next couple of weeks).

My understanding is that there are still architecture issues in the WASAPI driver that are worth addressing eventually. Would be good to open a dedicated issue to keep track of those, if anyone has a good grasp on what the problems are.

[j-s-c-o]

Yes, this build fixes my crackling audio issues (Win10/Motu M4), at least as far as I can tell. Thanks to all who contributed!

…

On Fri, Mar 8, 2024 at 6:57 PM Rémi Verschelde ***@***.***> wrote: Thanks to everyone involved debugging this! I merged the PR already has the first results seem good and the code change is trivial, but please keep updating this issue to confirm whether your issue did get fixed. You can test the PR artifact as described above, or test with the upcoming 4.3 dev 5 which should have this commit (no ETA for that snapshot, GDC will keep me busy the next couple of weeks). My understanding is that there are still architecture issues in the WASAPI driver that are worth addressing eventually. Would be good to open a dedicated issue to keep track of those, if anyone has a good grasp on what the problems are. — Reply to this email directly, view it on GitHub <#75109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6DKJV3DANHSNWNN5YIVPTYXJF7JAVCNFSM6AAAAAAWAGUSOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWGU3TSNJQGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Jewelots]

Confirmed fixed for me too, yep. Thanks all, really good stuff!

[AlexOtsuka]

I'm glad to see this work so well for everyone so far. I have kept the changes to an absolute minimum in order for the PR to go through and be cherry-picked as fast as possible as this was such a major issue for so many people.

Here are a few things to know about IAudioClient3 for anyone who wishes to delve deeper into this and improve the code, as this is a fairly new and very poorly documented API:

• Buffer sizes: As reduz has previously mentioned, it is more efficient for period sizes to be powers of 2. However, this is mostly out of our control because those values are pulled straight from the audio driver by calling
  IAudioClient3::GetSharedModeEnginePeriod().
  The extra calculations done to the period sizes don't seem to do much, and we might as well just pass in min_period_frames to IAudioClient3::InitializeSharedAudioStream(), as this is a value deemed safe to use by the driver.
• Using a delay vs an event callback driven approach: The first approach seems more common for shared mode, while an event driven approach is definitely preferable for exclusive mode. I do believe, however, that an event driven approach has the advantage of removing a bunch of inconsistent variables due to quirks of the OS. Both alessandrofama's patch and the older dropped PR are examples of how that could be implemented, and they actually work fine with IAudioClient3 after they're modified to make use of the proper max buffer size.
• About calling IAudioClient::GetBufferSize(): I coded this to be called every iteration. I believe this is preferable, as it eliminates a bunch of potential bugs when switching audio devices, for example. It's an extremely fast and cheap call anyway.
• About using IAudioClient3 for input: As of now, we're only using IAudioClient3 for audio output. Surely, this is something worth looking into in the future?

Anyway, this was my first time dealing with audio driver API code and I found it very instructive. However, there's still a big chunk of the code I'm very unfamiliar with. For now, I'm content with people being able to play audio through Godot the way it's meant to be. Thanks everyone for your feedback and contributions, and please keep testing this.

[p3tina]

After testing I believe I can confirm that this build has fixed this issue for me, as well. Great work everyone!

[moehnked]

@joesondow
tested the build multiple times, using the same audio and scene setup. switched back and forth between the test build and 4.2.1, and I could not get the audio glitch to happen in the test build, while it was definitely still happening in 4.2.1
so I think we can confirm that this is fixed!
once again, my hardware is a Steinberg brand UR22mkII usb audio interface, 24 bit / 192 khz

absolutely incredible work by everyone who reported on this, provided information, researched, worked on the solute, implemented fixes and tested! and of course thanks @AlexOtsuka for being a literal actual hero!

[ptlthg]

This new fix seems to have solved the crackling for me also, thanks @AlexOtsuka!

[ScarfKat]

Just tried the fix and it totally works! I had the audio bug again today, so I loaded up the fixed build and I've had absolutely no issues. Thanks so much to everyone who helped with this!

[XanderMassonov]

I'm new to Godot and GitHub, so this solution is difficult for me to understand. I just update focusrite 2i2 driver and that glitch dissapered. I hope forever.

[AlexOtsuka]

I'm new to Godot and GitHub, so this solution is difficult for me to understand. I just update focusrite 2i2 driver and that glitch dissapered. I hope forever.

Hey don't worry about it, it'll disappear with the next update anyway.

[yongan-game]

@AlexOtsuka I didn't get a chance to report on this fix earlier because the bug didn't pop up for me until just now, but I can confirm that this fix also works on my M-Audio M-Track Solo, at least from my testing.

I haven't run this build for too long, but whenever I get the crackling issue it persists across Godot restarts; when launching my project in this build, the issue is immediately gone.

[lander-vr]

Just got around to testing it as well and it seems to work fine on my end!

For some reason, the issue was fixed for me (in 4.2 and 4.3dev, didn't test other versions) by updating the drivers of my Motu. Suggested by @AdventurousDrake, who has the same audio interface as me, for whom that also worked. I'm not sure if that even makes sense though given the cause of the problem.

Either way, I've got no crackling or audible issues with that PR. Thanks for the fix @AlexOtsuka, great work!

[AlexOtsuka]

Just got around to testing it as well and it seems to work fine on my end!

For some reason, the issue was fixed for me (in 4.2 and 4.3dev, didn't test other versions) by updating the drivers of my Motu. Suggested by @AdventurousDrake, who has the same audio interface as me, for whom that also worked. I'm not sure if that even makes sense though given the cause of the problem.

Either way, I've got no crackling or audible issues with that PR. Thanks for the fix @AlexOtsuka, great work!

It's absolutely possible for a driver update to minimize this issue. The likelihood of this bug happening was significantly increased by slower hardware and older, less optimized drivers, because in many cases, the padding value could stay at 0 or at one iteration worth of buffer_frames for a very long time before it finally started filling up and causing the bug. This is why it was so inconsistent to reproduce in the first place.

The idea was that none of the workarounds would absolutely 100% guarantee the bug not to happen, and that you can't expect your players to mess around with their drivers and audio settings to fix an issue that should basically never occur. The fix should ensure that this can never happen anymore, no matter what.

[lander-vr]

Perfect! Thanks for the clarification/explanation. It's great to see this issue finally got resolved.

[rsletta]

@joesondow, sorry for the late reply. Finally got around to test this tonight. Can confirm that the build fixes the issues at my end, with audio playing seemingly flawless. It used to break by anything from a couple of seconds, to max 30 sec. Tested one a Focusrite Scarlet Solo 2nd gen with Focusrite driver 4.65.5.658, 4.119.3, and 4.119.13. Amazing work by all involved parties. 👍🚀

[joesondow]

I see the fix is live in the pre-release version Godot 4.3 dev 5. Great work @AlexOtsuka and everyone who helped!

https://godotengine.org/article/dev-snapshot-godot-4-3-dev-5/

[joesondow]

The developers have also backported this important fix to Godot 4.1.4 and Godot 4.2.2 so now the default current version on the Godot homepage contains the fix for this problem.

https://godotengine.org/article/maintenance-release-godot-4-2-2-and-4-1-4/

[loki3323]

Thank you everyone for contributing on this.
It seems to work for me!
(Focusrite 2i4 Gen1)

[LuisEscorza]

Started using 4.2.2 and the issue seems to be gone! (Focusrite 4i4 3rd Gen)
Thanks everyone!