Audio files distort inside Godot when using a Focusrite DAC

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

Are you using Bluetooth audio with microphone enabled?

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.

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

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 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.
https://user-images.githubusercontent.com/73611276/234338547-85ac23a6-be5e-44b9-9450-e0a9049a9ba3.mp4

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

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

I am also running into this issue; when Godot is outputting to 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.

I fiddled around a little bit this afternoon, I was able to completely eliminate 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.

@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.

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 fully eliminated the issue, as well as improving the overall performance the game.

@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.

@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 and just using my PC soundcard this does not occur ever.

Is anyone looking at solving this problem? I

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

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!

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. Anyone who can compile the engine from source can greatly help fixing the root cause!

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.

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.

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

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

I have opened https://github.com/godotengine/godot/pull/81938 now. Probably did something wrong with the Git side of thing though. My least favorite part.

@crashfort Tested your PR with my Focusrite 18i8, and it had no differences regarding the crackling audio. The crackling always occurs regardless of 1 sound playing or 100 sounds playing, but it can't really be replicated easily as it seems to be at complete random.
Happy to help with testing as much as needed on this issue as this is a huge blocker to development of my current game, an audio-focused game

I have opened #81938 now. Probably did something wrong with the Git side of thing though. My least favorite part.

checked with my Focusrite mini, seems to fix it. cross checked with other versions of the engine and changing around buffer sizes still stutters with them, but with this one i couldn't get it to stutter across a few different configurations of 128/256/512 buffer size and 44100/48000 sample rate.

For what it's worth, I can confirm that this appears to also affect my Sennheiser GSP 670. I came across this issue while trying to play Halls on Torment. Some of the other reports on the forum finally pointed me towards this issue.

After reading the whole thread, just wondering if anyone has considered ASIO drivers/hardware as part of the root cause? That may be the commonality between all the devices mentioned.

After reading the whole thread, just wondering if anyone has considered ASIO drivers/hardware as part of the root cause? That may be the commonality between all the devices mentioned.

fix has already been mentioned here. im not too familiar with audio drivers but it seemed to be a problem with WASAPI.

idk if this would be relevant but I've been noticing this error message pop up:
" modules/vorbis/audio_stream_ogg_vorbis.cpp:332 - Burning negative samples doesn't make sense. Check seek algorithm."

Can confirm that ASIO might be the issue.

Upper two channel is from godot build, lower two is original sound. I've synced start position thus difference in length proves that godot indeed has trouble.
Considering all the pop sound and overall slower playback suggest godot has trouble filling buffer or something.
Whenever Virtual ASIO is enabled (for me, Voicemeeter Banana) - despite having same sampling rate audio, even just playing track in editor's audio preview window has this issue.
If you disable standalone mode for physical playback device then finally sound plays normally.

I wonder what's the cause though, never seen any other program having issue with Voicemeeter other than Godot.

Considering all the pop sound and overall slower playback suggest godot has trouble filling buffer or something.

Can you reproduce this if you increase Output Latency in the Project Settings (then restart the editor)?

I have this exact issue on my Windows PC, and Godot 4.1.3 is the only application that does that. I have several audio devices, including an external DAC (Steinberg UR12) and wireless headphones (Steelseries Artics 7, radio, not Bluetooth). This issue even persists with Remote Audio sound device via Remote Desktop connection.
Output Latency does not make any difference whatsoever (I suspect it doesn't even work). Changing Mix Rate to the same as or different from the current audio device does not help. ASIO drivers/devices are not used.

@Calinou  Yes actually first answer I saw on reddit suggested it, so I even set it as high as 200ms and still same issue happened, and still is.

Just to add to the list of devices this is affecting: got the same issues using my Motu M2 in 4.2, heavy crackling and an increasing delay over time. And just the same as others, no crackling when using a pair of headphones plugged straight into my PC, even when I remain using my microphone connected through the interface as an input in Godot.

Just chiming in to add that I had the same problem on ASIO drivers with the Beheringer UMC22. The branch seemed to solve the issue.

Hey, same here with my UMC22 Beheringer audio interface. Everything else works, tried all the sampling and ASIO settings, no fix provided works.

Just want to add that this is still happening. I have a SoundBlasterX G6 soundcard and no matter what I do, every single audio file I play in-editor or at runtime is totally busted. All audio tracks have random crackles and/or randomly cut out then back in. (It gets much worse if applying an AudioEffect like Reverb as well.) It makes the engine completely unusable for full projects. I've never had this problem with any other application on my PC, it's exclusive to Godot.

Also for anyone looking for the setting in English, the specific box to uncheck is labelled "Give exclusive mode applications priority." You can find it under the "Advanced" tab in any audio device's properties.

That's interesting for me it seems to be the opposite. On my system, both exclusive mode settings were disabled already. After enabling "Give exclusive mode applications priority" and restarting Godot after changing settings, I've been listening to an audio file for over 10 minutes now without any crackling.

@ScarfKat glad it worked, and thanks for correct ENG terms there - Updated image!
Since that word can be translated to both way in korean I made a wrong choice I suppose haha

Considering @lander-vr needed to tick both option on unlike my case, wonder if there's something to do with Software ASIO vs Hardware.
So far my guess from this situations is:

Godot is not having fun with Software ASIO controlling output device exclusively
Godot needs exclusive mode for Hardware ASIO

We'd know for sure if we have enough devices and software ASIOs tested against this theory

Considering @lander-vr needed to tick both option on unlike my case, wonder if there's something to do with Software ASIO vs Hardware.

Coming back to my project the next day and the crackling is back. After trying each combination of those exclusive mode settings again, this time none got rid of- or affected the crackling.

Considering @lander-vr needed to tick both option on unlike my case, wonder if there's something to do with Software ASIO vs Hardware.

Coming back to my project the next day and the crackling is back. After trying each combination of those exclusive mode settings again, this time none got rid of- or affected the crackling. To make sure this wasn't something project-related, I tested in an new empty project with only an audio file imported.

After seeing this comment I went in and tried the same with my Focusrite 18i8 and this had no effect. The crackling is still there, always.

Coming back to my project the next day and the crackling is back. After trying each combination of those exclusive mode settings again, this time none got rid of- or affected the crackling. To make sure this wasn't something project-related, I tested in a new empty project with only an audio file imported.

Yeah unfortunately same here. The fix worked for a day, now I come back to the project and the audio is broken again. I'm also in the same boat of this being an engine-wide thing.

I've spent the last week trying to figure out the source of my audio issues, with audio slowing down, stuttering, and breaking up, before finally finding this issue today. What I read here sound exactly like what I experience. It is some what reproducible, in the sense that it usually occur some time during runtime every time I start my project. Sometimes it's there from the start, and sometimes it gets slower and slower, with more and more stuttering and breaking sound, before picking itself up again going back to normal. Changing audio interface always clear up the problem, and I haven't experienced the issue yet when running sound through my monitor via HDMI, but that I have only tested tonight after finding this thread. The problem also occurs in the editor, when playing my background music which last for more than a second or two.
Godot version: v4.2.1
USB audio interface: Focusrite Scarlett Solo (2nd gen)

I'm currently working on a game jam and can confirm I am also experiencing the issues on this thread. It seems to be fairly random when it will trigger. Can't seem to figure out exactly what the cause is. Thought I would throw my name in though as somebody who has also experienced the issue.
I will note that when exporting the game, the final export does not have this issue. So it definitely has to do with Godot not properly reading the audio files or some weird audio parsing through audio interfaces.
Godot Version: v4.2.1
Audio Interface: Focusrite Scarlett 2i2 (3rd gen)

This happens to me too, using a 3rd gen focusrite 8i6. It also happens on exported projects including web.
It seems to be very sporadic, and can happen at any point. I've turned off the exclusive control options for it and tried restarting my computer, but the issue is still there.
I'm trying to use the timestamp of the music for rhythm based stuff, but it gets messed up when the crackling/slowdowns happen. It's a blocker for making any kind of rhythm based game.

Chiming in to add that this is happening to me as well on a Motu M4 audio interface, Godot v4.1.2, Win 10 Pro. No messing around with driver buffer size or project audio latency has helped. Godot Editor and my Godot game are the only apps I have ever seen this problem with on this PC.

Had a friend report this was happening to him with my game (built with v4.2.stable.mono.official [46dc27791]) on his Windows 11 setup which is "RME digiface to optical digital, and from there to a DA converter".

I encountered this problem while creating a game. On short sounds this is not noticeable at all, but during music, lags occur at random times. I have a Steinberg UR22C sound card (I tried everything suggested above, it didn’t help) I’m really looking forward to the fix, because sound is very important
Godot version: v4.2.1
OS: Windows 11 Pro
USB audio interface: Steinberg UR22C

Chiming in to report the same issue, very distorted audio.
Godot version: v4.2.1
OS: Windows 11 Pro
USB audio interface: Focusrite 4i4

Same issue here. The build from @crashfort fixed the audio problem, but there are several other bugs in that godot build, so I can't use it.
I noticed that reconnecting the DAC (unplugging and plugging it back in) fixes the distortion for a while, without needing to restart the engine.
Godot: 4.2.1
OS: Windows 11 Home
Interface: Focusrite Scarlett Solo 3rd gen

Some press about this bug:
https://www.gamerevolution.com/guides/942517-halls-of-torment-audio-crackling-bug-fix-sound-godot-scarlet

I also got the same behaviors.
Music would slow down, distort, cracks and pops.
Godot 4.2
Win 10
Focusrite 2i4 Gen1
44.1 kHz/ 24 bits
stereo wav files with Loop mode forward and no compression
https://eddie-yu.itch.io/music-player
Here's the HTML5 version, the behavior would happen in the editor, test run, Window build, HTML5 build.
Sometime it happens, sometime it doesn't, sometime it persists, sometime it goes away eventually.

I played some Godot games that suffer from this like BackSlash.
While there are lots of Godot games that don't seem to have this issue like The Case of the Golden Idol and Donut Dodo.

I played some Godot games that suffer from this like BackSlash. While there are lots of Godot games that don't seem to have this issue like The Case of the Golden Idol and Donut Dodo.

Makes sense, since Case of the Golden Idol and Donut Dodo both released in 2022, using an older version of Godot from before when this bug was introduced in January 2023 if @MJacred is correct that the regression happened between Godot 4.0 beta 14 and Godot 4.0 beta 15.

This is a very critical issue that I hope gets resolved soon.
I've spent many, many hours this past week troubleshooting my PC trying to figure this out before realizing it's just an issue with Godot.
From my research, I've found that issues like this are often due to DPC latency. DPC latency (Deferred Procedure Call) occurs when a routine takes too long to process, thereby interrupting other processes from utilizing the CPU until it is done. Oftentimes it is the result of power saving features of the CPU, causing interruptions due to idling. There are hundreds of threads online of users experiencing similar audio glitches with their interfaces, with many blaming Windows, GPU drivers, or the audio interface drivers, although it is incredibly unclear where the issue is actually rooted. You can use tools like LatencyMon to help identify which drivers are contributing to latency spikes. Some of the most common culprits are dxgkrnl.sys (DirectX Graphics Kernel), ntoskrnl.exe (NT Kernel & System), storport.sys (Microsoft Storage Port Driver), and several others from what I've experienced.
I believed this to be the same issue as the audio glitches sound exactly the same, but interestingly, there are some inconsistencies. Usually, running LatencyMon shows spikes in latency corresponding to when audio glitches occur; however, it seems that the audio issues in Godot occur regardless of the DPC latency displayed in LatencyMon. After all the time I've spent modifying my settings and mitigating my system's latency, Godot's audio still exhibits the same erratic behavior.
Still, there is a part of me that believes they might still be related. The issue regarding DPC latency produces the same stuttering audio artifacts that Godot produces, and primarily affects audio interfaces due to their nature of requiring low latency. I wonder if there is a problem with interrupts within Godot itself, rather than latency caused by interrupts at the hardware level. Or, if a driver really is interfering, it could explain why this problem is not reproducible on Mac. All of my testing was done in Windows 10 with an Nvidia GPU.

I hesitate to continue learning Godot while this critical bug remains unfixed for almost a year.
I think the biggest problem here is that the intersection of: (1) people with the expensive hardware to reproduce the error, (2) people who feel they have the expertise to debug and fix the root cause, and (3) people interested enough to bother trying… is zero people.
If anyone who has encountered the error can also find a free software-based way to reproduce the error without the special hardware, I bet it would help the community do more experimenting and debugging.
For instance, if you can find any audio programs such as Voicemeeter, Virtual Audio Cables, Audacity, OBS, VirtualBox, VMWare, or any other program where you're able to send your computer audio output and make this Godot glitch happen without a specialized audio hardware interface, or if there are software emulators of the hardware interfaces that allow you to make the error happen from Godot, please comment with your findings. That way other people can work on reproducing the issue, and perhaps work on a fix that doesn't require an expensive extra device for testing.

I definitely think it is fixable. In fact, #81938 was a huge step in the right direction. No idea why it was closed, but at least this problem has been getting more attention recently. The issue is certainly in the WASAPI driver. Unfortunately, I don't think there is any way for something like this to be reproduced without the actual hardware. I am highly inclined to believe it is the product of latency issues as I described in my last comment, and if that is the case, it's not something software could emulate.
If it helps anyone, a temporary fix is to uninstall or disable your audio interface drivers. You can still use your audio interface, but use the default drivers for it instead. Useful if you don't have any other way to connect your speakers to your PC.
I just tested it and it works. It isn't a solution, but a good enough workaround for anyone to continue working on their projects until an actual fix comes around. The only downside is you'll have some audio delay/latency in your DAW, which makes recording in time difficult. If that's an issue just reinstall the drivers.
I am using a Focusrite Scarlett 2i2 Gen 2 on Windows 10.
What I did:

Unplug the audio interface
Search for Focusrite Control in the Windows search bar
Click uninstall
Find Focusrite drivers and uninstall from the menu
Open device manager
Click View -> Show hidden devices
Find any instance of "Focusrite" in Device Manager and uninstall it
Plug the audio interface back in
Windows should set up the device on its own in a few seconds
No more audio stuttering in Godot

Some of these steps may not be necessary, but I at least know that it works.
Not ideal if your workflow involves moving back and forth between your DAW and Godot frequently, but better than nothing. Hope this helps

This is a pretty critical issue and has completely stopped me from using Godot as this bug occurs in the final build of games, and the last thing I want is for players to deal with annoying unfixable audio issues.
Uninstalling my audio driver every time I want to use the program is a ridiculous workaround that is not going to work in the long run.
I am more than willing to test this as much as needed since I have access to the hardware and am familiar with building Godot, however I do not have the knowledge to fix the issue (and I assume most people do not since this has remain unfixed).
I did try #81938 when crashfort was still working on it but found that it did not resolve the issue on my device. What can we do to get more visibility on this issue? I'm quite surprised to see that this issue has not received much traction considering it is pretty critical and is affects published games, Halls of Torment being the example mentioned previously.

@jauwnio There is a hypothesis that the error started happening in between Godot v4.0-beta 14 and 15.
If you have time, would you be able to build v4.0-beta 14 and v4.0-beta 15 and then test each one with your device to verify that the problem does not occur in v4.0-beta 14 but does occur in v4.0-beta 15?
If you can prove that 14-15 hypothesis correct, it might help direct more attention to the code differences between those two builds. And if you can prove the hypothesis incorrect it could save people from spending too long looking in the wrong place. Helpful either way.

@joesondow
Doing some testing to try to help out. I made a project in 4.2 stable with a simple test scene:

both audio stream players go into a bus. the bug is somewhat random so it took a while to confirm if it was still happening and if the specific configuration affected it at all. I don't know if the audio stream players, the audio busses or audio file type (.ogg in my case) matter, but I can confirm this bug is still present.
I downloaded v4.0 beta 14 and built an identical scene, with the same audio files, and can verify that the bug is still present in that version.
I have a steinberg UR22 mk2 USB audio interface, which is similar to the scarlet focusrite or m-audio brand interfaces, but different enough to be able to say this isn't a hardware, firmware, driver, or windows issue, but something that got changed at some point in godot.

Thanks @moehnked. That's helpful for everyone to know, that v4.0 beta 14 already had the problem.
If you're able to test earlier versions of Godot to narrow down which versions have the problem and which don't, it could help the community's search to pinpoint which version introduced the problem, and therefore which code changes are relevant.

I am still in the process of testing versions on my Focusrite 18i8 3rd Gen but I have found that this issue occurs on every version down to and including 4.0 v10. Testing v9 and below today.

I've tested a few Godot versions too, and can test some more later:
✅: no crackling (not 100% though, haven't been able to reproduce yet)
❌: crackling + slowdowns confirmed

✅ v4.0.alpha1.official [31a7ddbf8]
✅ v4.0.alpha10.official [4bbe7f0b9]
❌ v4.0.alpha17.official [22a09fef5]
❌ v4.0.beta1.official [20d667284]

I think it may be this PR causing the issue. I tested the version before this and did not get any crackling. The line about changing the audio buffer size raises a flag to me as well since that is exactly what this issue sounds like - an audio buffer issue
https://github.com/godotengine/godot/pull/51296

I've tested a few Godot versions too, and can test some more later:
✅: no crackling (not 100% though, haven't been able to reproduce yet) ❌: crackling + slowdowns confirmed
* ✅ [v4.0.alpha1.official [31a7ddbf8]](https://downloads.tuxfamily.org/godotengine/4.0/alpha1/)

* ✅ [v4.0.alpha10.official [4bbe7f0b9]](https://downloads.tuxfamily.org/godotengine/4.0/alpha10/)

* ❌ [v4.0.alpha17.official [22a09fef5]](https://downloads.tuxfamily.org/godotengine/4.0/alpha17/)

* ❌ [v4.0.beta1.official [20d667284]](https://downloads.tuxfamily.org/godotengine/4.0/beta1/)

I was able to recreate the issue in alpha10, however it did take a while for it to occur, about 5 minutes of playtime.
For my tests, btw, I am using the following

5 minute long .WAV file that I created in Ableton Suite 11. 16 Bit Depth and 44100 Sample Rate
Nothing in the project except one AudioStreamPlayer2D that autoplays the sound
Focusrite 18i8 3rd gen with latest drivers, at 128 buffer size and 44100 sample rate (the default settings)

Continuing to test more, starting at alpha1 and working way up to alpha10

This is awesome work, thanks for getting some momentum going on this. Seems like we're finally starting to narrow things down.
I don't know how to make a build of the engine or anything, but I just wanted to pop in to cheer you guys on cause fixing this bug will be huge for a lot of people.

Reporting back from my testing. The crackling and slowdown does occur in versions as early as 4.0alpha1. However, the issue is far less prevalent the older you go, at least from my testing. There is a good chance it could also just be luck; since even in the most recent build you might go 15 minutes without a crackle, or maybe 1, it's pretty random. No hard evidence to indicate the issue has gotten worse over time.
I do not recall this issue ever happening on any 3.x build, and I don't think anyone else does either, so at this point I think all of the evidence collected leads to this being introduced in the very first 4.0 build.

Just figured I'd add saying that I'm having the same issues. Issue is quite spontaneous and pops up after a while and doesn't go away until I unplug and plug my DAC back in, after which is comes back a couple minutes later. I do not have this issue for any other application.
Using OGG and WAV files in my projects.
Godot 4.2 Stable
Windows 10
Scarlet 2i2 (3rd Gen)
48000Hz on both my drivers and godot
256 buffer on drives and 6ms (around 256) on godot

Just commenting to add that I started using Godot a couple of weeks ago and have been experiencing this since I started. I don't use any Focusrite hardware
Godot 4.2.1
Windows 11 Home
EPOS H3Pro BT headset

@jordachemac Which hardware does it happen with? Only on your EPOS H3Pro BT headset, or also with any other computer speakers or ear phones?

I can blindly guess that the difference between versions could be that IIRC Godot 3.0 used XAudio as a default driver on Windows, and then at some point Godot switched to WASAPI driver

I can blindly guess that the difference between versions could be that IIRC Godot 3.0 used XAudio as a default backend on Windows, and then at some point Godot switched to WASAPI backend

An XAudio2 backend is present in the source tree, but it's never been enabled by default at build-time to my knowledge.

I've had the distortion happening in web builds too, so I don't know if it's necessarily wasapi related

@joesondow  I've been testing it against a Wonderboom BT speaker and I'm pretty confident that the audio issues do not occur on that. the output formats for each are:
EPOS H3PRO - 16bit, 48000 HZ (DVD Quality) (issue occurs)
Wonderboom - 2 channels, 16 bit, 44100 Hz (CD Quality) (issue does not occur)

I am using a Focusrite iTrack Solo with Windows 10 and experience this bug constantly in 4.2.1 stable. I made a simple project in 4.0 alpha 1 and was able to replicate the exact same issue, though it does seem to happen less frequently.

I have an idea. @EIREXE released a Godot game called "Project Heartbeat" with Godot's audio system replaced with miniaudio library. You guys with affected setups could test it and check if the bug can be reproduced.
Not sure if Project Heartbeat uses WASAPI backend of miniaudio, but even if it doesn't, I think we could ask @EIREXE to force WASAPI backend and test with it again. In case of success, if the bug goes away in this game, then we can compare miniaudio and Godot code and find the cause.

Hi guys. I had a stretched sound glitch. And my audio device is Focusrite 3rd gen 2i2. So i just wrote Focusrite USB ASIO in line "Driver" which you can find in: project settings\audio\driver.

I'm on latest and I also have extremely slow choppy audio both in editor and in built exes. Judging by the article linked earlier, if I played other modern godot games such as Halls of Torment, I'd have the same audio issues. This definitely needs to be fixed engine-side, I can't adjust editor settings in other peoples' shipped games.
I have a focusrite scarlett 2i2, as with a lot of people above, and my audio is set to 48000hz. I have a feeling that having your PC output set to 48000hz and the game set to WASAPI at 44100hz is the only thing that you need to cause this issue.

I'm on latest and I also have extremely slow choppy audio both in editor and in built exes. Judging by the article linked earlier, if I played other modern godot games such as Halls of Torment, I'd have the same audio issues. This definitely needs to be fixed engine-side, I can't adjust editor settings in other peoples' shipped games.
I have a focusrite scarlett 2i2, as with a lot of people above, and my audio is set to 48000hz. I have a feeling that having your PC output set to 48000hz and the game set to WASAPI at 44100hz is the only thing that you need to cause this issue. Changing my output to 44100hz in Focusrite Control fixes the issue, but I don't want to have to do that every time I open the editor or a game.
Edit: I set the audio to 44100hz to work without pain when I made this post two hours ago, and I've been running the editor and relaunching the game a few times, and suddenly the audio's gotten really choppy again (persisting across launches). It slowly got worse and worse. Really strange, not sure what could cause this other than some audio buffer weirdness.

You can change bit rate in project settings.

ames s

As I said in the message, that's not a tenable option, as other peoples' games also have this problem when simply run, I don't have access to their projects. Plus, changing the sample rate isn't a fixall otherwise it would be 48000hz by default.

I don't think changing the buffer size has any effect outside of placebo, it really just changes the frequency at which the issue occurs. Based on the info we have as to what causes this issue, it seems to be almost a timing issue with the driver. There is some sort of desync between the audio leaving Godot and hitting the audio driver which causes it to crackle/slow down.
I've noticed that more CPU heavy projects cause this is to happen almost immediately, like if you instantiate a lot of scenes with audio playing on awake the crackle will happen instantly almost 100% of the time.
From digging through PRs it seems like there were some attempt to fix latency issues in between 3.x and 4.0 that may have created this issue. https://github.com/godotengine/godot/pull/38210 perhaps looking to this and some of the associated updates my prove fruitful?
Regarding the Project Heartbeat custom branch of Godot, I did try to build it myself but found the build running into a handful of errors I have neither the time nor knowledge to fix. If anyone else is able to build it and post it here I can try running it on my device

Just want to add the MOTU M2 audio interface to the list, same problems as described by other people. This is definitely a show stopper, and I have stopped learning Godot 4 because of this (even though I've decided that I want Godot 4 to be my next engine). Does Juan know about this at all?

I've also lost some of my enthusiasm for learning Godot after seeing this showstopper bug report languish for 11 months, even after the infusion of money the Godot Foundation received recently. Seems like the kind of problem that investment is meant for, a critical production problem marring currently released games, one which the volunteer community cannot easily fix.

@Calinou That link isn't working to show me any specific conversation. Do you have a date stamp of when the conversation happened in that #audio chat room?

@Calinou Good that Juan and others are aware. Does this mean that people are actively working on it, or no one can fix at the moment.

Nobody is currently actively working on it as we don't know the exact cause of the issue.

@Calinou That link isn't working to show me any specific conversation. Do you have a date stamp of when the conversation happened in that #audio chat room?

The relevant discussion starts on 2023-12-22.

Can anyone that is able to reproduce this bug run the engine binary like this?

Copy the Godot binary to the project folder
Run like this: C:\project_folder> godot.exe -v
Paste the output (specifically anything related to WASAPI) here

I tried to reproduce it many times but only was able to briefly hear some cracks at the start (like the first second) and then went to normal. This is what I got from it:
WASAPI: Activated output_device using IAudioClient3 interface
WASAPI: wFormatTag = 65534
WASAPI: nChannels = 2
WASAPI: nSamplesPerSec = 48000
WASAPI: nAvgBytesPerSec = 384000
WASAPI: nBlockAlign = 8
WASAPI: wBitsPerSample = 32
WASAPI: cbSize = 22
WASAPI: mix_rate = 48000
WASAPI: fundamental_period_frames = 480
WASAPI: min_period_frames = 480
WASAPI: max_period_frames = 480
WASAPI: selected a period frame size of 480
WASAPI: detected 2 channels
WASAPI: audio buffer frames: 480 calculated latency: 10ms

@jefvel do you have a project to send me so I could try to test it out? I have a Focusrite 2i2 Second gen and can't really make it happen.

I find it kinda odd that it does not use PO2 period sizes, its kind of a waste of CPU..

After trying to reproduce the issue many times, I couldn't really get it to happen. In editor, playing the game, exporting the game, nothing. I think I've only heard it once, but it might have been unrelated since it was only a second.
I also tried playing Halls of Torment since it was mentioned here, but still no issues with the sound.
I tried reproducing this in Mac and Windows (10). I'm using a Focusrite 2i2 2nd gen. I guess this only happens with the Focusrite 2i2 3rd gen.

After trying to reproduce the issue many times, I couldn't really get it to happen. In editor, playing the game, exporting the game, nothing. I think I've only heard it once, but it might have been unrelated since it was only a second.
I also tried playing Halls of Torment since it was mentioned here, but still no issues with the sound.
I tried reproducing this in Mac and Windows (10). I'm using a Focusrite 2i2 2nd gen. I guess this only happens with the Focusrite 2i2 3rd gen.

I can double check later which gen 2i2 I have to see if we can corroborate that, this 100% occurs with my focusrite 6i6 as well.

Running that I get the exact same results as @coppolaemilio.
My crackling however is very consistent, practically persistent, regardless of the project or build and doesn't disappear until I reconnect my USB interface (Motu M2). After reconnecting it takes anywhere between immediately to ~a minute or so until crackling starts happening again.

hi, wanted to add for those failing to reproduce and hopefully to help those who are trying to work around the issue while it's being solved, if you're a musician and use a digital audio station, that will potentially alter your sample rate, which causes the issue. i have my Scarlett 2i2 set to 48kHz 192 samples, and the game i am testing works fine, after i run Ableton Live 11, that sets my sample rate to 256, because that's what the DAW is built to work with, and then my godot game has this bug. so try testing after a restart before running your daw if you want it to work smoothly, and try turning on a daw or manually messing with your sample rate to reproduce if that helps

I've been aware of this issue for months and have been following this thread hoping the earlier PR would fix things. I use a Focusrite 2i2 3rd gen on Windows 10.
The issue occurs out of nowhere, but keeps occurring once it's happened. I believe this is Godot's current worst bug, and I'm willing to invest 100s of hours into helping figuring this out and fixing this if there is a way I can contribute.
Here are my logs using the official binary for Godot 4.2.1, audio crackles the whole time:
WASAPI: wFormatTag = 65534
WASAPI: nChannels = 2
WASAPI: nSamplesPerSec = 44100
WASAPI: nAvgBytesPerSec = 352800
WASAPI: nBlockAlign = 8
WASAPI: wBitsPerSample = 32
WASAPI: cbSize = 22
WASAPI: mix_rate = 44100
WASAPI: fundamental_period_frames = 441
WASAPI: min_period_frames = 441
WASAPI: max_period_frames = 441
WASAPI: selected a period frame size of 441
WASAPI: detected 2 channels
WASAPI: audio buffer frames: 441 calculated latency: 10ms

Here are my logs doing the same thing with a Godot 4.2.1 binary I manually patched with code from https://github.com/godotengine/godot/pull/81938, No crackling in this case:
WASAPI: wFormatTag = 65534
WASAPI: nChannels = 2
WASAPI: nSamplesPerSec = 44100
WASAPI: nAvgBytesPerSec = 352800
WASAPI: nBlockAlign = 8
WASAPI: wBitsPerSample = 32
WASAPI: cbSize = 22
WASAPI: detected 2 channels
WASAPI: audio buffer frames: 970 calculated latency: 21ms

I'm aware the PR wasn't solving the issue for everyone, but I am currently experiencing constant crackling with the official binary and none with my patched binary, going back and forth A/B testing them using the same project.
Let me know if you have any idea of a particular thing I should be looking out for when it comes to digging through the source code. I could also share my custom binary if it helps people who aren't comfortable compiling their own fork of Godot test this bug, if that is an acceptable thing to do.

Yesterday I was getting constant crackling on my Sound BlasterX G6 external soundcard. Today I'm back to having no crackles. This isn't the first time I've had the issue one day but not another, it's fairly hard to pin down. I resolved it yesterday by disabling "Give exclusive mode applications priority" in the sound device's settings. Today however I'm unable to reproduce even after changing exclusive mode settings again, and changing the mix rate within the project. I even tried opening FL Studio as per the advice of vinyllie, but no dice.
That being said, I'd still like to contribute a log, but I'm unsure about how exactly to do it. I have the godot exe in the project folder, then ran that, but I don't see a log anywhere. I assume it has to do with the "-v" in the initial post stating " C:\project_folder> godot.exe -v " but I'm not really sure what it means. If anyone can point me in the right direction I'd love to contribute, as I agree this is currently the engine's worst bug and the sooner we can figure it out the better.

Yesterday I was getting constant crackling on my Sound BlasterX G6 external soundcard. Today I'm back to having no crackles. This isn't the first time I've had the issue one day but not another, it's fairly hard to pin down. I resolved it yesterday by disabling "Give exclusive mode applications priority" in the sound device's settings. Today however I'm unable to reproduce even after changing exclusive mode settings again, and changing the mix rate within the project. I even tried opening FL Studio as per the advice of vinyllie, but no dice.
That being said, I'd still like to contribute a log, but I'm unsure about how exactly to do it. I have the godot exe in the project folder, then ran that, but I don't see a log anywhere. I assume it has to do with the "-v" in the initial post stating "C:\project_folder> godot.exe -v" but I'm not really sure what it means. If anyone can point me in the right direction I'd love to contribute, as I agree this is currently the engine's worst bug and the sooner we can figure it out the better.

Assuming you use Windows.
Navigate to your project folder, copy and paste your Godot executable there.
Highlight the address bar, type cmd and press Enter. A terminal window should open.
Type godot.exe -v and press Enter. godot.exe has to be the exact name of the executable you copied into your project folder.
Copy and paste all the lines starting with "WASAPI" here.

Anyone who can reproduce the bug, I suggest recording a video of the bug in action, using your phone if necessary, then post it to YouTube and link it in the comments here. Seeing and hearing examples could help collaborators theorize.

Anyone who can reproduce the bug, I suggest recording a video of the bug in action, using your phone if necessary, then post it to YouTube and link it in the comments here. Seeing and hearing examples could help collaborators theorize.
Set the YouTube video to Unlisted if you don't want your subscribers to see it.

Done: https://youtu.be/dRikq_sZfDA
As reference for those who cannot reproduce, the severity of the crackling is not constant: it isn't always as severe as in this demonstration, and sometimes (in my experience) it is even more severe.

Assuming you use Windows. Navigate to your project folder, copy and paste your Godot executable there. Highlight the address bar, type cmd and press Enter. A terminal window should open. Type godot.exe -v and press Enter. godot.exe has to be the exact name of the executable you copied into your project folder. Copy and paste all the lines starting with "WASAPI" here.

Got it, thanks for the advice. Here's the log I got. Again I had the issue yesterday but not today, full context is given in my post just above.
WASAPI: Activated output_device using IAudioClient3 interface
WASAPI: wFormatTag = 65534
WASAPI: nChannels = 8
WASAPI: nSamplesPerSec = 48000
WASAPI: nAvgBytesPerSec = 1536000
WASAPI: nBlockAlign = 32
WASAPI: wBitsPerSample = 32
WASAPI: cbSize = 22
WASAPI: mix_rate = 48000
WASAPI: fundamental_period_frames = 480
WASAPI: min_period_frames = 480
WASAPI: max_period_frames = 480
WASAPI: selected a period frame size of 480
WASAPI: detected 8 channels
WASAPI: audio buffer frames: 480 calculated latency: 10ms

Done: https://youtu.be/dRikq_sZfDA As reference for those who cannot reproduce, the severity of the crackling is not constant: it isn't always as severe as in this demonstration, and sometimes (in my experience) it is even more severe.

That is exactly the kind of thing I get when the bug occurs as well. Thanks for getting a video of it.

another video for y'all https://www.youtube.com/watch?v=wdWfZiK9HiE as lander-vr stated it's very inconsistent and i can't tell what tends to cause it. sometimes the issue happens at 192 buffer and sometimes at 256 buffer it's fine, but switching the buffer size around is the easiest way to easily recreate for me

Following the above instructions, this is all I get:
WASAPI: Activated output_device using IAudioClient3 interface WASAPI: wFormatTag = 65534 WASAPI: nChannels = 2 WASAPI: nSamplesPerSec = 48000 WASAPI: nAvgBytesPerSec = 384000 WASAPI: nBlockAlign = 8 WASAPI: wBitsPerSample = 32 WASAPI: cbSize = 22 WASAPI: mix_rate = 48000 WASAPI: fundamental_period_frames = 480 WASAPI: min_period_frames = 480 WASAPI: max_period_frames = 480 WASAPI: selected a period frame size of 480 WASAPI: detected 2 channels WASAPI: audio buffer frames: 480 calculated latency: 10ms
Closing the project after the bug has occurred does not output any errors.

There are a bunch of free and open source software DAWs listed on https://en.wikipedia.org/wiki/Digital_audio_workstation
Ardour
LMMS
MusE
Qtractor
Rosegarden
Traverso DAW
OpenMPT
If anyone who can reproduce the bug on a hardware DAW is also able to reproduce the bug just by using one of those free software DAWs (without your hardware DAW) it would allow more people to try to debug without having to buy anything.

joesondow, can you explain what a hardware DAW is? DAW software is not equivalent to an audio interface/DAC, it works in tandem with it

@joesondow You're confusing DAW and DAC. However, this line of thinking does lead me to wonder if this issue occurs when using the free ASIO4ALL driver? This driver is meant to mimic the low-latency audio found in a hardware interface and if the issue is happening with most known audio interfaces, I would think it would occur with ASIO4ALL as well

Sorry to double comment, but wanted to add this as well if it will help anyone else to test.
I quickly built the old fix from https://github.com/godotengine/godot/pull/81938 to try again, and was unable to recreate the crackling issue.
If you are able to build that (very simple, just follow the guide here https://docs.godotengine.org/en/stable/contributing/development/compiling/index.html) and try, please do and comment your OS/interface and results.
If you don't know how or don't feel like building it from source, I uploaded a build to my repository https://github.com/jauwnio/godotAudioFix in the godotaudiofix.zip. You can download and test using that as well.
My results:

Windows 11
Focusrite 18i8 Gen 3, Latest Drivers
NO CRACKLE after testing all 3 scenarios:

5 minute WAV (one audiostreamplayer)
5 minute WAV (a lot of audiostreams)
many 5 minute WAVs while also watching a YouTube video in the background (audio device exclusivity is a common cause of problems with WASAPI, so knowing that it still works with YouTube playing is a good sign)

@jauwnio Something is wrong with the godotAudio zip file, getting error "zip is invalid" when trying to extract it.

@jauwnio Thanks very much for the prebuilt binary. I loaded the simple project from my videos I posted above into this version, let it run for 10 minutes, and the audio glitch did not occur once. Just to be sure I opened the project again in 4.2.1 stable and the glitch happened after only two minutes. It seems #81938 was definitely on the right track.

@lander-vr Can you check your firmware and drivers as they might be outdated. My new firmware version is 2.07 and driver version <IP_ADDRESS>2

Updated my driver and firmware as well, they were ~2.5 years old I believe and I hadn't updated them for so long, for the same reason as @AdventurousDrake, since I experienced no audio issues aside from in Godot.
After having tried several projects for a decent amount of time each time, in editor 4.2.1, a build from 4.2.1, and the Road To Vostok demo (all of which I experienced heavy crackling in prior to updating), I have not experienced any crackling/slowdowns anymore, so far at least.

Everybody, check your firmware and drivers on your manufacturers website, maybe it can solve the problem (I didn't think about it as everything else worked fine, apart from Godot)

The last update for my Steinberg UR12 was in October 2016, so I guess I am out of luck here.

@lander-vr Fantastic news, it seems like this could have solved the problem for is MOTU M2 users at least.
@cjmaxik Sorry to hear that, maybe time for a new Audio Interface. But yeah, something definitely changed from Godot 3 to 4 on the audio side, hopefully it can be fixed for people with older hardware.

@joesondow As my problem seems to be fixed, I wouldn't be able to tell whether it actually improves anything.

@joesondow I bought a new interface anyway, but I am keeping it around for testing. It doesn't really make sense to buy a new interface because of the specific engine issue, though.

So basically, my hunch is that the fix is simple (just figure out how to get an actuall polling/callback call instead of the sleep) but Windows sound APIs are terrible and the documentation is even worse. If anyone wants to spend time on this, it would be very welcome and I can help.

Here is how Portaudio implements this, they use a sleep too it looks like, but it seems to be more complex than what we use:
https://github.com/PortAudio/portaudio/blob/master/src/hostapi/wasapi/pa_win_wasapi.c
Here is how RtAudio implements this, they do use a proper event:
https://github.com/thestk/rtaudio/blob/master/RtAudio.cpp#L6151
Relevant doc:
https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-seteventhandle
So it looks like we should basically change our code to work like in RtAudio, using WaitforSingleObject until the event unlocks. IMO from both implementations, it looks like RtAudio does a much better job implementing a proper audio callback (including full duplex) and I would use it as reference for our Wasapi code.

Thank you @reduz, this is incredibly helpful and the code has started making a lot more sense to me. I'm glad this bug is getting the attention it deserves. It makes sense that IAudioClient3 with its low latency would induce crackling earlier/a lot more frequently than the higher latency IAudioClient interface. This thus needs a proper fix where users may enjoy a properly working 10ms latency audio playback experience.
Diving into this now.

@AlexOtsuka

Could you elaborate on this? It seems that as of now, the period size when using IAudioClient3 with its 10ms latency. Is always gonna be the mix rate / 100.

The reason why you normally want to always use a PO2 period size when possible is that, not only in Godot, but also very commonly in audio software, a lot of effects are processed in chunks, as in:

Process parameters (such as envelopes, LFOs, settings, time etc). For synths this is often when midi events are processed, though unrelevant to Godot.
Process a small block of audio (often interpolating the envelopes such as amp, filter, feedback, etc)
Goto 1

And often this processing is done in PO2 blocks. Likewise for effects that use FFT, which will have most implementations working in PO2 sizes.
The problem if a non-PO2 size is that it creates peaks in the CPU processing because imagine your internal audio engine works on 256 samples, but your period size is say 300. Some audio callbacks will process twice while others will process once. If period size is PO2, generally it aligns with the block processing of internal effects or generators or general engine mixing, hence it is always desire to near it down to that if possible.
This uses a lot less CPU.

If anyone who cannot reproduce the issue wishes to simulate the crackling, they can try commenting out or removing calls to timeBeginPeriod(1) and timeEndPeriod(1) in the OS_Windows class. Sleeping in the WASAPI driver thread will then take the default system resolution time, on my Windows 11 machine about 15.6-16ms, resulting in sound like this:
https://github.com/godotengine/godot/assets/26153311/e44eab1e-ba60-4e1a-9ad9-0eebd0bf8a0b
According to the docs, this was a global setting on versions prior to Windows 10 version 2004, and any third party program could change the timer interrupt interval, which is very bad. Trying to use AUDCLNT_STREAMFLAGS_EVENTCALLBACK + WaitForSingleObject in the WASAPI driver fixes my issue above. Will take look at the RTAudio implementation in more detail.

If anyone who cannot reproduce the issue wishes to simulate the crackling, they can try commenting out or removing calls to timeBeginPeriod(1) and timeEndPeriod(1) in the OS_Windows class. Sleeping in the WASAPI driver thread will then take the default system resolution time, on my Windows 11 machine about 15.6-16ms, resulting in sound like this:
2024-02-2221-16-06.mp4
According to the docs, this was a global setting on versions prior to Windows 10 version 2004, and any third party program could change the timer interrupt interval, which is very bad. Trying to use AUDCLNT_STREAMFLAGS_EVENTCALLBACK + WaitForSingleObject in the WASAPI driver fixes my issue above. Will take look at the RTAudio implementation in more detail.

Could you share your implementation of AUDCLNT_STREAMFLAGS_EVENTCALLBACK and WaitForSingleObject() in audio_driver_wasapi.cpp? That's what I'm currently messing around with but I've yet to figure out a way to prevent audio crackling through that on my end.
As for the PO2 period sizes, it seems like the values are entirely determined by the audio driver. They are obtained via a call to IAudioClient3::GetSharedModeEnginePeriod(). The current implementation does this, and determines a period_frame value that's the closest allowed value to mix_rate * latency / 1000. In RtAudio, however, they skip this step and simply make use of the min_period_frames value returned by IAudioClient3::GetSharedModeEnginePeriod() and plug that straight into IAudioClient3::InitializeSharedAudioStream(). I don't think this has any impact on the current issue anyway, as all the values seem to be the same when using an ASIO driver.

Could you share your implementation of AUDCLNT_STREAMFLAGS_EVENTCALLBACK and WaitForSingleObject() in audio_driver_wasapi.cpp? That's what I'm currently messing around with but I've yet to figure out a way to prevent audio crackling through that on my end.

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

Could you share your implementation of AUDCLNT_STREAMFLAGS_EVENTCALLBACK and WaitForSingleObject() in audio_driver_wasapi.cpp? That's what I'm currently messing around with but I've yet to figure out a way to prevent audio crackling through that on my end.

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

Thank you. And wow, this actually seems to work perfectly so far!
I will leave the build running for a few hours to see if it breaks eventually, but this is very promising.

Juan, now that there are more clues how to proceed, what do you think about adding the "high priority" tag to this issue, to maybe get a few more people helping with the fix?

On Linux (and I believe MacOS too) the scheduler quantum is by default around 1ms, which makes it very flexible for low latency. On Windows, unfortunately, this is around 10-15ms.

Classic.
timeBeginPeriod can be used to increase precision to 1ms. Roughly same as macOS/Linux. https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod
IMHO there is no reason not to set the precision to 1ms at program startup.

Due to the same reason above, in general, this is why system calls (such as malloc, sleep, semaphores, file access, etc) should never be used in the audio thread.

Audio programmers hate me for this, but I don’t actually agree.
It’s fundamentally a trade-off with latency. You can totally call malloc on the audio thread! Just so long as you aren’t trying to do single millisecond latency for live instrument audio.
 Like well over 100 milliseconds. Highly optimized AAA games regularly have on the order of 75 - 150 ms. https://youtu.be/JTuZvRF-OgE
What’s important is that you never miss a buffer submission. You’re free to queue up multiple buffers which gives you all the slack in the world to call malloc or make syscalls. Besides, what hat do you think happens when Godot and YouTube are playing audio at the same time? :)
No malloc, syscall, locks etc is honestly good practice and probably worth doing. But I find audio programmers over-index on this when the full system latency is orders of magnitude larger than the optimizations they’re implementing!

No malloc, syscall, locks etc is honestly good practice and probably worth doing. But I find audio programmers over-index on this when the full system latency is orders of magnitude larger than the optimizations they’re implementing!

The problem is that in game engines, the CPU is juiced to the max using all cores, so the risk of your audio thread getting preempted is actually quite significant. Using proper synchronization (as in let the operating system tell you when you should mix the audio instead of checking from the outside like we are doing now) is a must to ensure your audio thread gets resumed exactly when it must mix.
I also agree that malloc/etc are generally safe (it was much worse 15 years ago when most CPUs were single core), but you have to think that Godot is meant to run in any platform it can and that, as you say yourself, not all of them have great audio support, so the safer the better.

Using proper synchronization (as in let the operating system tell you when you should mix the audio instead of checking from the outside like we are doing now) is a must to ensure your audio thread gets resumed exactly when it must mix.

The safer thing is to immediately return a queued buffer and kick off the next batch process. If the mixing thread gets interrupted that’s fine. It probably needs less than a millisecond to mix a 10+ millisecond buffer. Plenty of time!
Anyhow, just something to keep in mind by whoever ends up wrestling with the various audio APIs. As mentioned upthread they’re a poorly documented nightmare!

CPU is juiced to the max using all cores

I wish all games engines were capable of effectively leveraging all cores! If only. 😂

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

Would love to give this a shot but I'm unsure how exactly to use a patch file. I'd like to apologize for being so new to the technical side of these things lol, but I'm open to learning.

@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

@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.

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 path.
This issue has been bothering me while developing, so it's great to see more progress on this issue. Thanks everyone!

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.

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 https://github.com/godotengine/godot/pull/81938 and trying to make it compatible with IAudioClient3 are what clued me in, so thank you very much for your contribution!

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

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 can try it out and confirm it fixes their issue.

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 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'll try to update 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.

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

not tested yet
@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

not tested yet
@lander-vr
Motu M2

not tested yet
@Sunriser45
UMC22 Beheringer

not tested yet
@ScarfKat
SoundBlasterX G6

not tested yet
@rsletta
Focusrite Scarlett Solo (2nd gen)

not tested yet
@braydenplumb
Focusrite Scarlett 2i2 (3rd gen)

not tested yet
@jefvel
3rd gen focusrite 8i6

not tested yet
@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

not tested yet
@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

not tested yet
@p3tina
Focusrite iTrack Solo

not tested yet
@XanderMassonov
Focusrite 3rd gen 2i2

not tested yet
@Jewelots
focusrite scarlett 2i2

not tested yet
@AdventurousDrake
MOTU M2

not tested yet
@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

not tested yet
@ptlthg
Scarlet Solo gen 3

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.

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
https://github.com/godotengine/godot/issues/75109#issuecomment-1986579502,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA6DKJV3DANHSNWNN5YIVPTYXJF7JAVCNFSM6AAAAAAWAGUSOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWGU3TSNJQGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

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

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.

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

@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!

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

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!

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.

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.

@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.

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!

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 were 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.

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

@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 <IP_ADDRESS>8, 4.119.3, and 4.119.13. Amazing work by all involved parties. 👍🚀

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/

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.

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

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


Update README.md + Add support for Markdown/HTML + Update loop targets

Issue: N/A
What Changed

[x] Docs: update README.md with more info about the output & Getting started section.
[x] Feat: add support for analyzing Markdown/HTML files for title via the <title> tag.
[x] Feat: add support for tags (was supposed to be there as it is already being referenced in StoryIndexGenerator.ts.
[x] Maintenance: update the analyze loop to target only Meta elements instead of all elements.
[x] Maintenance: enable running unit tests on pull requests

How to test

[x] CI passes.
[x] Check updated unit tests.

Change Type

[x] maintenance
[x] documentation
[x] minor

@sheriffMoose @shilman Hi! Any plan to approve/merge this? Would love to be able to set tags on unattached docs, since i cannot seem to find any other way to do that without this! Thanks! 🙏


Better matrix of test options

Test options:

PyCurl:

New Curl handle every time or not (only with no connection reuse)
Create new connection every time (fresh connect) + forbid reuse
https://curl.haxx.se/libcurl/c/CURLOPT_FRESH_CONNECT.html and https://curl.haxx.se/libcurl/c/CURLOPT_FORBID_REUSE.html
Possibly avoid caching of DNS lookup results?

Requests:

Enable reusing connection via the session

Resolved with the command-line-run PR


splice_site: junction or region? [sf#134]

Reported by cmungall on 2008-12-04 01:55 UTC
splice_site
"The *position* where intron is excised."
five_prime_splice_site
"The *junction* between the 3 prime end of an exon and the following intron."
but the is_a path is to region, not junction.
colloquial usage is: "GU at the 5' splice site and AG at the 3' splice site"
If we interpret the "at" as "around" or "adjacent_to" then it's a junction (we change the is_a path)
If we interpret it as "coincident_with" or something like that then it's a region (we change the wording of the definition)

Commented by cmungall on 2008-12-04 19:57 UTC
Also a typo in the def
s/intron/an intron/
Also, how about expanding and adding a clause: the splice site connects an exon and an intron on the primary_transcript, and connects two exons on the spliced transcript (though it is arguable that in this case it "turns into" a splice junction)

Commented by kchris on 2008-12-04 23:34 UTC
sounds like the "splice site" and the "splice site consensus region" have sort of been conflated. I would say the "splice site" is the junction between the intron and the exon. The splice site consensus is a region of conserved sequence surrounding the actual splice site, speaking from a biological perspective.
If SO wants to represent a region, rather than a junction, perhaps the term name should be something like "splice site consensus"
-Karen

Commented by eilbeck on 2008-12-18 21:02 UTC
Hi Chris,
Right, the name suggests a point but its usage is at least 2 bp.
I re organized this part of SO
splice_site Consensus region of primary transcript bordering junction of splicing.
cis_splice_site
trans_splice_site
I am for keeping the name in line with the usage and adding splice_junction to represent the boundary.
There already is the term exon_boundary to describe the position where the intron has been excised from.
--K

Updated by eilbeck on 2009-01-22 20:33 UTC

status: open --> closed-accepted

Commented by cmungall on 2009-03-02 23:35 UTC
there are 2 text defs for splice regions that use junction as a genus:
SO:0000163 ! five_prime_cis_splice_site [DEF: "The junction between the 3 prime end of an exon and the following intron."]
SO:0000164 ! three_prime_cis_splice_site [DEF: "The junction between the 3 prime end of an intron and the following exon."]
Should be changed to (2bp?) region

Updated by cmungall on 2009-03-02 23:35 UTC

status: closed-accepted --> open-accepted

Commented by cmungall on 2009-03-02 23:45 UTC
The definition here refers to a term not declared in SO
[Term]
id: SO:0001420
name: trans_splice_site
def: "Primary transcript region bordering trans-splice junction." [SO:ke]
is_a: SO:0000162 ! splice_site

Commented by cmungall on 2009-03-02 23:57 UTC
seeing as I have reopened this, a few additional minor requests. Consider some consider tags for the following obsolete terms:
[Term]
id: SO:0000674
name: non_canonical_splice_site
def: "A splice site where the donor and acceptor sites differ from the canonical form." [SO:ke]
synonym: "non canonical splice site" EXACT []
synonym: "non-canonical splice site" EXACT []
is_obsolete: true
[Term]
id: SO:0000675
name: canonical_splice_site
def: "The major class of splice site with dinucleotides GT and AG for donor and acceptor sites, respectively." [SO:ke]
synonym: "canonical splice site" EXACT []
is_obsolete: true

Commented by cmungall on 2009-03-03 00:02 UTC
SO:0000676 - SO:0000679
??add synonyms to each: {non_}canonical_{five,three}_*cis*_splice_site

Commented by cmungall on 2009-03-03 00:06 UTC
OK, should have bundled this into one comment. This replaces my comment at 15:35
See working_draft.obo for definitions for splice_sites.
splice_site = region that overlaps exactly 2 base and adjacent_to splice_junction
cis_splice_site = splice_site that adjacent_to exon and overlaps intron
five_prime_cis_splice_site = splice_site that downstream_adjacent_to exon and starts intron
three_prime_cis_splice_site = splice_site that upstream_adjacent_to exon and finishes intron
see gia.obo for definitions of these relations
haven't done the trans ones yet

Updated by eilbeck on 2009-07-14 22:04 UTC

status: open-accepted --> closed-accepted


New command: spo tenant applicationcustomizer get

Usage
spo tenant applicationcustomizer get
Description
Get an application customizer that is installed tenant wide.
Options

Option
Description

-t, --title [title]
The title of the Application Customizer. Specify either title, id or clientSideComponentId.

-i, --id [id]
The product id of the Application Customizer. Specify either title, id or clientSideComponentId.

-c, --clientSideComponentId  [clientSideComponentId]
The Client Side Component Id (GUID) of the application customizer. Specify either title, id or clientSideComponentId.

Examples
Retrieves an application customizer by title.
m365 spo tenant applicationcustomizer get --title "Some customizer"

Retrieves an application customizer by id.
m365 spo tenant applicationcustomizer get --id 14125658-a9bc-4ddf-9c75-1b5767c9a337

Retrieves an application customizer by clientSideComponentId.
m365 spo tenant applicationcustomizer get --clientSideComponentId 7096cded-b83d-4eab-96f0-df477ed7c0bc

Additional Info
Returns the list item from the tenant wide extensions list.

Can I work on this?

Sure! All yours!


cassandra: small fixes

Coverage increased (+0.0009%) to 79.228% when pulling 7b4986c98f1fc01b7b6588fab56d29198790da0d on iksaif:master into b5341d8c06f69239bbbb9f78bc2fee6e3917e33b on criteo:master.

Coverage decreased (-0.05%) to 79.179% when pulling 482fa445a36ad46d550f195df10b683733b01f70 on iksaif:master into b5341d8c06f69239bbbb9f78bc2fee6e3917e33b on criteo:master.

Coverage decreased (-0.05%) to 79.179% when pulling cda503fbfd23c77ef7a1310c46902715a974cc82 on iksaif:master into b5341d8c06f69239bbbb9f78bc2fee6e3917e33b on criteo:master.

Coverage decreased (-0.003%) to 79.224% when pulling 23227ee023c1afe6939c9731435a0147534fbed9 on iksaif:master into b5341d8c06f69239bbbb9f78bc2fee6e3917e33b on criteo:master.

Coverage decreased (-0.1%) to 79.118% when pulling 9dbb70c45dae2c4e60176feb509231ebefb0da5e on iksaif:master into b5341d8c06f69239bbbb9f78bc2fee6e3917e33b on criteo:master.

Coverage increased (+0.4%) to 79.629% when pulling fccc57ce03b48586db532e9adf7dfe6b48bd93c3 on iksaif:master into b5341d8c06f69239bbbb9f78bc2fee6e3917e33b on criteo:master.


Updated version of PR #350

Improved version of closed PR #350

Added GitHub Workflow, now can build docker image and push to ghcr on new tag is pushed
Added Support for self-signed certs for API endpoints
Updated dockerfile and docker compose for a production build instead of running in dev mode
Updated docker compose to use ghcr image
Updated bun lock file to match package.json, for building docker image with bun install --frozen-lockfile
Removed '6379:6379' port mapping for redis, since there's no reason to map redis to host
Removed searxng_data:/data mount for searxng, since there's no such mountpoint on official searxng's docker compose
Refactored changed docker-compose.yaml to compose.yml since docker offcially suggest using the latter

It's tested and running great

Yes that looks good . The volume was added more for the dev to have a persistent storage in the container and its
discretionary. Ports etc all entirely up to devs.

Got it. If merge isn't possible feel free to just copy what you think is useful.

@yusing
Thank you for creating the PR again. There's still a build error. You should be able to check it with the bun run build
I've updated the bun.lockb in morphic/main, could you please merge it?
[17:52:38.836] Running "bun run build"
[17:52:38.842] $ next build
[17:52:39.597]   ▲ Next.js 14.2.13
[17:52:39.598]
[17:52:39.681]    Creating an optimized production build ...
[17:53:14.015]  ✓ Compiled successfully
[17:53:14.016]    Linting and checking validity of types ...
[17:53:24.150] Failed to compile.
[17:53:24.151]
[17:53:24.151] ./components/ui/codeblock.tsx:60:36
[17:53:24.151] Type error: This kind of expression is always truthy.
[17:53:24.151]
[17:53:24.151]   58 |     const fileExtension = programmingLanguages[language] || '.file'
[17:53:24.151]   59 |     const suggestedFileName = `file-${generateId()}${fileExtension}`
[17:53:24.151] > 60 |     const fileName = window.prompt('Enter file name' || '', suggestedFileName)
[17:53:24.151]      |                                    ^
[17:53:24.151]   61 |
[17:53:24.151]   62 |     if (!fileName) {
[17:53:24.151]   63 |       // User pressed cancel on prompt.
[17:53:24.202] error: script "build" exited with code 1
[17:53:24.213] Error: Command "bun run build" exited with 1
[17:53:24.571]


is there any example in non-uniform ﬁeld?

Hello, recently I read your perfect article and I saw that in the article you mentioned the work of non-uniform electric fields.
" A feasible way is to discretize the non-uniform ﬁeld to each atomic center and introduce a nonequivalent ﬁeld-dependent function to each FI-EAD feature (as implicitly implied in Fig. 1) to approximate the response of each atomic density to the local ﬁeld experienced by the central atom."
is there any example about this?

Hello, recently I read your perfect article and I saw that in the article you mentioned the work of non-uniform electric fields. " A feasible way is to discretize the non-uniform ﬁeld to each atomic center and introduce a nonequivalent ﬁeld-dependent function to each FI-EAD feature (as implicitly implied in Fig. 1) to approximate the response of each atomic density to the local ﬁeld experienced by the central atom." is there any example about this?

Sorry, it's not released yet. But it should be very simple. You can implement it yourself, using different field vectors at each atom center.

thank you very much, i will try it by myself


UnicodeEncodeError: 'ascii' codec can't encode character u'\xa0'

The following error occurs on both Linux and IRIX, both using python 2.7:
$ ./youtube-dl --verbose http://www.collegehumor.com/video/6939029
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', 'http://www.collegehumor.com/video/6939029']
[debug] youtube-dl version 2<IP_ADDRESS>
[debug] Python version 2.7.5+ - Linux-3.11.6-i686-with-Ubuntu-13.10-saucy
[debug] Proxy map: {}
[CollegeHumor] 6939029: Extracting information
[CollegeHumor] 6939029: Downloading info XML
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"main", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "./youtube-dl/main.py", line 18, in
File "./youtube-dl/youtube_dl/init.py", line 775, in main
File "./youtube-dl/youtube_dl/init.py", line 728, in _real_main
File "./youtube-dl/youtube_dl/YoutubeDL.py", line 791, in download
File "./youtube-dl/youtube_dl/YoutubeDL.py", line 416, in extract_info
File "./youtube-dl/youtube_dl/extractor/common.py", line 129, in extract
File "./youtube-dl/youtube_dl/extractor/collegehumor.py", line 53, in _real_extract
File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1300, in XML
parser.feed(text)
File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1640, in feed
self._parser.Parse(data, 0)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa0' in position 1416: ordinal not in range(128)

You will have to post the full output of youtube-dl downloading a video that causes the problem with --verbose added to the command line. Even if  it's also a collegehumor video, you'll probably have to open a new issue, but if the debug output is substantially similar, refer to this issue in the new one.


Add ability to log to roctx.  Currently just for functions

Add the ability to log function calls to roctx.  This allows attached profilers to see which MIOpen calls are being called by application and which kernels are being invoked by MIOpen.
Enabled via the MIOPEN_ENABLE_LOGGING_ROCTX env var.

@mwootton please follow https://github.com/ROCmSoftwarePlatform/MIOpen/wiki/How-to-format-code to format the code too. Thanks!

@mwootton could you please follow up on this PR? Thanks!

@mwootton should we consider moving this out of ROCm 6.0 target?

I guess it's better to continue in #2391


Remove add-delete-to-pr-files feature

This has been implemented by GitHub. Fixes #1458.

@vinkla Can you fix the merge conflict?

@sindresorhus done now.

I've pushed an update. Let me know if there is anything else I should update before we can merge this.

See my comment in https://github.com/sindresorhus/refined-github/pull/1462#discussion_r207594552

Thanks :)


Rename turkey to Türkiye

The name change is official. I also created a MR for i18n_data
https://github.com/grosser/i18n_data/pull/62

Thanks for the PR!
This name change is potentially a breaking change for some users, so I will release it on the next major release.
In the meantime, could you fix the failing tests, please?

@pmor the specs fail because of the outdated cache files. The README states: Make sure your you haven't made changes to cache/**/* so I did not run rake update_cache. Should I commit the updated cache or is there another workflow which does that?

@larskuhnt Nevermind then. Coffee still hasn't kicked in.


Bugfix/issue 1 update dependencies

Updating dependencies for operational/security reasons.
See also #1

Updating dependencies for operational/security reasons.
See also #1


Add Liceo Statale "Ischia"

The school's main website is https://liceoischia.edu.it

@peppedev Pull request merged. Thank you!


Slow route group

Laravel Version: 5.7
PHP Version: 7.4

Description:
I took a client's project using only one route group and it's causing the project to slow down.
My client has about 500 route lines. At least in version 5.7 I did not test in version 6.x
Steps To Reproduce:
Make a very large route group, I think 200 lines is enough. But in our reality it was 500 lines in a single group.

Hey there,
Unfortunately we don't support this version anymore. Please check out our support policy on which versions we are currently supporting. Can you please try to upgrade to the latest version and see if your problem persists? We'll help you out and re-open this issue if so.
Thanks!


Fix readthedocs build

Must be removed dev-requirements.txt from here

Error from build for python3.5
➜  ~ cat /Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/log/py35-1.log
action: py35, msg: getenv
cwd: /Users/bakhtiyor/PycharmProjects/sanic_session
cmd: /Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/bin/python -m pip install '.[aiomcache]' '.[redis]' '.[memcached]' '.[msgpack]' '.[dev]'
Processing /Users/bakhtiyor/PycharmProjects/sanic_session
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Download error on https://pypi.org/simple/ujson/: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:720) -- Some packages may not be found!
    Couldn't find index page for 'ujson' (maybe misspelled?)
    Download error on https://pypi.org/simple/: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:720) -- Some packages may not be found!
    No local packages or working download links found for ujson
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/var/folders/rb/f2zhv7594d73r39g3nd0lb3c0000gn/T/pip-req-build-uaojw5sq/setup.py", line 62, in <module>
        "Topic :: Internet :: WWW/HTTP :: Session",
      File "/Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/lib/python3.5/site-packages/setuptools/__init__.py", line 144, in setup
        _install_setup_requires(attrs)
      File "/Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/lib/python3.5/site-packages/setuptools/__init__.py", line 139, in _install_setup_requires
        dist.fetch_build_eggs(dist.setup_requires)
      File "/Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/lib/python3.5/site-packages/setuptools/dist.py", line 717, in fetch_build_eggs
        replace_conflicting=True,
      File "/Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/lib/python3.5/site-packages/pkg_resources/__init__.py", line 782, in resolve
        replace_conflicting=replace_conflicting
      File "/Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/lib/python3.5/site-packages/pkg_resources/__init__.py", line 1065, in best_match
        return self.obtain(req, installer)
      File "/Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/lib/python3.5/site-packages/pkg_resources/__init__.py", line 1077, in obtain
        return installer(requirement)
      File "/Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/lib/python3.5/site-packages/setuptools/dist.py", line 784, in fetch_build_egg
        return cmd.easy_install(req)
      File "/Users/bakhtiyor/PycharmProjects/sanic_session/.tox/py35/lib/python3.5/site-packages/setuptools/command/easy_install.py", line 673, in easy_install
        raise DistutilsError(msg)
    distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('ujson')
    ----------------------------------------
ERROR: Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/rb/f2zhv7594d73r39g3nd0lb3c0000gn/T/pip-req-build-uaojw5sq/

Sanic drop python3.5 support (changelog)

@xen ping

@xen ??

It seems, I broke docs page. Give me time, I fix it.

merged  #59


[#3025] - enable homepage and siteconfiguration

Pull Request Checklist:

[x] Positive Test Case Written by Dev

[x] Automated Testing

[x] Sufficient User and Developer Documentation

[ ] Passing Jenkins Build

[ ] Peer Code review and approval

Positive Test Case

Login to the admin panel, navigate to SiteConfiguration and change the site version.  Save, navigate to the homepage and verify your change persists.
Login to the admin panel, navigate to HomePage and setup a Warning message.  Save, navigate to teh homepage and verify your warning shows up.

hs_docker_base review.
https://github.com/hydroshare/hs_docker_base/pull/20

@hyi - could you take a quick look at this.  There are a couple of updated packages in hs_docker_base to make mezzanine play nice with django 1.11 and also registering the homepage.