#Very strange audio artifacting on browser (chrome) version (but not Desktop) - sounds are dull
140 messages · Page 1 of 1 (latest)
i really dont know what causes this, google really fucked something up in chrome though
i was able to reproduce the issue on the latest chrome in windows, but after i wiped the %localappdata%/Google folder (caution this will destroy all of your browser data!!!), the issue went away and now i cannot reproduce it anymore
hm yeah that does stop the issue
looking through the old folder for what could possibly be the issue is certainly a fools errand; i might try reporting this to google instead
its the most google thing of all time honestly
i really wish i had a better answer, it frustrates me a lot too
they just uber fucked something up in an update i guess
this issue made me switch to tetrio desktop and actually im thinking ill stay using that
but yea... classic 
the issue is basically that the sound start and stop points are like, not what i asked chrome to play
so the sound bleeds into the next one or previous one a little and it's uber broken
like it's off by a factor of 10 milliseconds sometimes which is catastrophic
unfortunately, this issue is upstream and has nothing to do with tetrio specifically, we haven't even updated the sound effect part of the program in quite a while
this made me turn off sound effects
have you submitted a Chromium bug report for this? if not, can you still reproduce it? I'd be happy to bisect and report it
(speaking in a personal capacity, not representing my employer)
i haven't
unfortunately i cannot reproduce the issue because i dont have the old appdata files, i kind of casually deleted them without thinking it would actually fix anything
i was not able to repoduce the issue on linux at all, either, neither with chromium or proprietary chrome
i was only able to reproduce this on windows
I suspect it's some experiment (A/B test) being rolled out to a portion of the population, and deleting the AppData files would "reset" your client ID for experiments
mmm
is it only proprietary chrome that has a/b testing? or does chromium do it too?
I'm fairly sure that only official (proprietary) Chrome gets Google's experiments, it's disabled in Chromium
that's what i figured
also, when i tried it from canary i didn't get the issue, but i think someone else did
or wait, no, it's the other way around
i still had the issue on canary but someone else did not
it appears the issue mainly revolves around AudioBufferSourceNode::play right, because it seems to not be the start and end times i put to it, and can be off by a factor of 10 millis
if someone is able to reproduce it, I'd appreciate it if they could share from chrome://version:
- Google Chrome version (e.g. 145.0.x.x)
- OS
- Active Variations (can be used to identify users! please DM me this if you do share it)
thanks for the pointer, lemme see if there's some recent changes in Blink to that
the problem is tetrio puts all the sound effects right next to each other in one AudioBuffer and just plays directly from that
so if the start and end times are off at all we start playing samples from the other sounds
"can be off" might?? be an anti-fingerprinting feature too, although that's just a theory
i dont particularly understand how that could be, it's just choosing an offset and length in an AudioBuffer, yknow?
it just means the computer has to play the samples from the offset for the length
do you know approximately when reports of this started coming in? around Feb 10?
Feb 10 was when M145 was pushed to Stable
mm if i recall correctly, <t:1770642000:f> was the earliest one i knew of
ah, if it's an A/B test then Chrome versions might not be too useful. "Active Variations" (i.e. experiment states) would be more useful
unfortunately I too am on Linux right now, and I can't seem to reproduce it
i was never able to reproduce it on linux, i was only able to produce it on stock chrome in windows 11
that goes for all the people who have this issue as well, they're all windows users
I might try to reproduce this on my personal computer then (Windows 10) after I get home from work
unfortunately not - but you might be able to manually enable the necessary flags to simulate being put into an experiment group
in theory, all experiments being run should be put into https://crsrc.org/c/testing/variations/fieldtrial_testing_config.json, and you can enable all of these with a command line flag or possibly a chrome://flags flag
chrome://flags#enable-benchmarking seems to have a "Match Field Trial Testing Config" option which should do that
enabling that flag does cause the issue to reoccur
so the qustion is… which specific thing is it, i wonder?
awesome! you can bisect which issue experiment it is by using a tool
let me remove the slowmode on this channel
I think there's some better end-user documentation about how to run this, gimme one sec
nevermind, that's only for bisect_builds.py
you might need to just copy and paste this and its dependent split_variations_cmd.py to a folder (or clone Chromium, but that's overkill)
alright, so i have those both
take a look at the docstring at the top of bisect_variations.py - ignore the vpython3 stuff (you can just use any ol' Python 3)
I can do this for you after work if you wish, but if you're happy to bisect it that'd be easier
its no problem
my job revolves around making a browser game anyway so experience with this kind of thing is useful
im just going through the process lol
once you figure out which flag / experiment it is, you can report it at https://crbug.com/new probably under the "Chromium > Blink > WebAudio" component
you will need a Google account for this
that aspect might be problematic lol
I'd be happy to report it for you in this instance, but that might be an issue if you want to report more bugs in the future
i assume i can make an account specifically for that, then?
AFAIK the name on your Google account isn't shared, and the avatar / email is redacted to the public - see https://crbug.com/460678756 for an example
the bisection is complete
yeah, you should be able to create an account specifically for that. let me know if you encounter any anti-bot issues, I can possibly help you out with that
this is it
--force-fieldtrials=AudioInputConfirmReadsViaShmem/Enabled/ --enable-features=AudioDecoderAudioFileReader<AudioDecoderAudioFileReader
ill make an acc and report it
although i dont know what exactly i should write
the wizard on https://crbug.com/new should be quite explanatory
you don't need to submit a feedback report as you've already bisected down the issue
an easy way to reproduce the issue would be nice, but probably not required
like an example webpage? can i upload files?
yeah, you can upload files like an .html file showing the issue
in that case, a zip would probably work
i dont suppose you can allow me to avoid requiring the use of a phone number, could you?
no, unfortunately :/
yeah, that's fine
i have a proxy number i'll just use
damn, they know it's one
well, alright lol
not a big deal, i just have to erase the recovery number after the fact
sms recovery is not safe in any way, at all, so
unrelated to the account: can you try running Chrome with --force-fieldtrials=AudioInputConfirmReadsViaShmem/Enabled --disable-features=AudioDecoderAudioFileReader (e.g. your minimal repro, but disabling AudioDecoderAudioFileReader instead)?
it seems like the AudioInputConfirmReadsViaShmem experiment might be a no-op, so maybe it's just as a result of AudioDecoderAudioFileReader
the former feature was enabled by default a while back: https://crrev.com/c/6367214
yeah it appears the issue doesnt show up on tetrio at least
seems like the issue is just with AudioDecoderAudioFileReader then
I'm familiar with tetr.io and lurk in a few discords in my personal account, and saw someone complaining about this
no problem, I'm always happy to report / fix bugs that are annoying people
im just making the minimal reproduction if i can
I'm decently familiar with the Chromium codebase (although not so much about Blink) so feel free to reach out to me if you need anything
well i'll try to use the official channels as much as i can, i dont want to bother you and all
the other useful tool is bisect-builds.py if it's an issue with a Chrome update, not an A/B test: https://www.chromium.org/developers/bisect-builds-py/
i got a minimum repro it looks like
oh i found more details it looks like
it depends on the codec of the original file, so ill be sure to include that information
i can only reproduce it when i put the old folder back, in which case it happens without fail and without any other setup
dw, i've already bisected it flowerling
ah okay
#1474905565191995463 (0 messages) was moved here.
same issue
#1475662216630898710 (0 messages) was moved here.
yup same here
in my environment, it would happened when i use firefox with a very lag timing
update, google refused to fix the bug and claims its working as intended when something is seriously wrong
https://issues.chromium.org/issues/485920243
i dont know, maybe ill have to do their job for them or something, this is really irritating
i dont know if the pre-skip is being applied twice somewhere or what
i put a comment, they better fucking do something about this or kill the A/B test until they get it together…
It seems to be fixed on my end. I'm not sure if there is slight or not, but it is playable now.
that's because we're using some hacks to use a different codec (aac) for all chrome users on version 145 and up
since opus is just busted
but I'm gonna change it to a more elegant solution that checks the decoded audio buffer of a test file to see if it's busted
I have noticed it after a quick play run still. Worth noting it isn't completely gone, but mostly.
they've removed the B in M145, so your only option would be to work around it
lemme know if you want me to push to get this fixed / investigated - I can also look into it and reaffirm your findings
I had posted a zip file already in the latest comment with a very simple tool
if you inspect the float32array of a decoded opus file in chrome, you can very clearly see the first 312 samples that should be there are missing
so the pre skip is getting applied twice
I'm very disappointed with the way the assignee handled this issue, because they just didn't check and assumed that chrome was fine for whatever reason
and just assumed that until now, there was a 6.5ms gap in all opus decodes which there obviously wasn't
and then shifts the blame saying "hey, it's the web standard"
my only option is to decode a test opus file and see if the samples are just literally wrong, and if they are, fall back to AAC
so chrome users will get the worse codec for a while I suppose
...
if you have the time, I'd really appreciate it
as I've said, there's a zip file of a page in the latest comment that does a very simple comparison of samples
done, I've reproduced the issue and you're right - preskip is being cut off twice
thank you, i really appreciate it
i was nervous the bug report was going to go into the ether
I took a deeper look - the fix seems easy but I'm not sure at what level we should apply the fix, so I'm delegating this to the owner