Hello,
I'm using AudioContext.createMediaStreamDestination() in order to keep AudioContext playback alive on Webkit-based browsers and mobile devices, and while it works perfectly on Webkit and Gecko, I've been running into a strange issue with it on specifically Chromium/Blink-based browsers. I'm posting this here just because I don't know if this is a Chromium bug or an issue with some other part of my system, so I want to check if anybody is able to reproduce it, or if there might be some other explanation for it.
The way I have this set up is pretty simple--it creates the MediaStreamAudioDestinationNode and connects the rest of the nodes in the graph (that would normally be connected straight to AudioContext.destination) to that node. Then, I create an <audio> element, set the source object to the stream, and append it to the document. I then wait for the context to start running, and start playing the audio element. I'm pretty sure this is very similar to the official MDN example of AudioContext.createMediaStreamDestination().
The bug, however, is that occasionally for the first 5-10 seconds of the context being active, the audio is slightly faster/higher pitched and has little gaps, presumably from being played at a higher sample rate than it should be played at. It then fixes itself, and does not happen again until the page is reloaded. Sometimes, it also starts happening maybe half a second after the context is started. I've attached a video demonstrating this issue.
Strangely, while I could reproduce this issue nearly 100% of the time a few days ago, I can only reproduce it maybe half the time today. I had some of my friends test it on Windows to no avail, so I would appreciate if some users running Chromium on Linux with PulseAudio/Pipewire could test this. I still believe it very well could be a Chromium bug, though, since it does not happen in any of the other browser engines I've tried. Maybe it's something to do with how Chromium handles audio on Linux?
I've put together
this MRE, however, it seems to happen even less (perhaps 10-20% of the time) than with the web app. It is more noticeable, though, since it also starts happening later (maybe 1-2 seconds in) for whatever reason.