We've sent a verification link by email
Didn't receive the email? Check your Spam folder, it may have been caught by a filter. If you still don't see it, you can resend the verification email.
Started November 19th, 2023 · 5 replies · Latest reply by frederic.font 1 year, 1 month ago
So far only tested on a OnePlus Nord N20 5G running Android 12. Chromium browsers are affected, Firefox isn't. Not one to say if this is some hard limitation of them, or something to be accounted for. The same thing is happening with audio embeds on cohost.org
https://freesound.org/people/Saltbearer/packs/39756/
https://cohost.org/Saltbearer/post/3567029-uh-oh-this-public-r
From page load, if you preview the 8 kHz file, and then preview the 44.1 kHz file, the latter will play at 8 kHz. This can happen in loaded instances of the sites' players across tabs, and regardless of filetype.
Hi @Saltbearer,
I don't seem to be experiencing these issues, at least on a desktop computer, and thinking of the code I can't imagine so far how the two players could affect each other. Can you provide clear steps to reproduce the issue? The issue is that depending on the order in which the sounds are played, their "content" changes?
Don't understand the technicals at all, but only silly suggestion I have is that files are somehow being retrieved from local cache.
Here's a recording of it happening in Chrome and Brave, then *not* happening in Firefox:
https://youtu.be/BxzECTJ9PHw
(Mono audio is a limitation of any screen capture on this phone)
Hmm this is interesting, this looks like a android+chromium bug (Brave is also chromium based), as technically on the Freesound side we don't tell the browser "how to play a file", but just provide the file and the browsers figures it out, so I don't think there is code on our side that we could add to fix this. Thanks for reporting anyway, hopefully it gets fixed in future releases.