We just released v1.156.2 with possible breaking changes
Feedback For Audio Pipeline Errors
Dear contributors, dear language leads.
We want a fully responsive, fully working Common Voice, as far as it can be achievable.
In the last weeks we refactored our audio pipeline.
Fixed many ongoing bugs on the front-end (state handling, race conditions, …)
We are now handling audio corruptions (due to communication errors) better, and have better UX for false positives
Introduced a better Apple device detection to fix audio codec problems
We alpha and beta tested, but we cannot cover all possibilities of diverse combinations, especially valid for location specific random communication disruptions. There can also be something we introduced, which breaks already working setups - although low probability.
Possibly, there can also be cases which you are already aware of and learned to live with it, without reporting because it is a known issue.
What to check
If you encounter any errors which disrupts your workflows, please report them here.
You should check these:
You can record continuously more than 25-30 sentences without any problem
You can listen to your own recordings
You don’t have many cracking sounds (is your device’s battery and reception OK, is it in battery saving mode?)
You can submit 5 recordings per batch and they get uploaded without a problem (check the green bar at the top)
No other problem encountered (If you have, report it please)
How to report
While reporting, please give the following information (the issues we deal with are very much device dependent):
Device make/model/operating system with versions (e.g. iPhone 13 Pro Max, iOS 18.7)
Browser make/version (e.g. Mobile Safari 18.7)
Device and session status (if relevant): How is your battery level? Is battery saving mode on? Are there any hard privacy related settings turned on? Do you have a good/stable signal reception? Are you behind a company/country level firewall? Etc.
Description of the problem you encountered. (e.g. “After recording sentence I cannot listen to any of my own recordings”)
If displayed what message did you get? (e.g. “When trying to submit I get 500 error”)
If possible, share a snapshot of the problem screen.
If possible/if any, share the errors displayed in browser developer tools console.
We also expect language leads to collect and forward problems which your community encountered.
We thank you for every effort you are doing individually and as a community.
Xiomi HyperOS: Has problems with audio, for chromium based browsers it introduces cracks. Fix: Firefox work fine.
Apple iPad & Mac Air: On some browsers, in desktop mode there might be problems (you cannot record or listen to your own voice, or says it is too silent). Please make sure to report these, but also try with other browsers, especially with Firefox.
Cached data: There is an issue in Common Voice, where the data on the device does not retire. For example, if you move away from your device in the middle of recording sentences, and come back a couple of hours later, that data might be stale, or even invalid. Most mobile browsers are very harsh on caching, they might release the data, and when you try to continue errors might come out. Also, after releases, the program in your device memory (e.g. you keep the tab open) will be the old one, which might have unknown effects. This is under our radar and will be fixed after a large refactoring. Fix: Make sure you post 5 recording batches and/or refresh your page after you come back. New program and fresh data will be there…
Use of InApp browsers: When you do a campaign using Social Media (Facebook, etc), your links will open inside that mobile App (InApp browser or WebView). These browsers are stripped versions, have limited capabilities and higher security measures, and are slow in responses. These may introduce processing or upload problems, corrupt audio, or even a user will not be able to record at all. We now catch these corruption errors and show a specific message with directions. Fix: Please do not use InApp browsers, use a proper native browser app (copy paste the link), test with Firefox, Brave etc, and give feedback below.
Low-end devices / low battery: Especially for low-end/old phones and notebooks, if the battery is low and/or if the device is in battery saving mode, their operating system shuts down CPU cores and/or drops their frequencies to lower levels, and audio processing requirement might not work in real-time, resulting in cracks. Fix: Use your device with high battery level, shut down battery saving, or use it plugged-in.
Very low/dropping wireless reception: On mobile devices, if both GSM and WiFi is enabled, WiFi takes precedence, and if it has disruptions, the audio might be corrupt while sending. Common Voice currently cannot work offline. Fix: Make sure you have a stable and online connection.
Example for the problem described (showing from an actual report we received yesterday)
Battery level is 1%
Although the device has good GSM reception, it is connected to WiFi, which is nearly not existing.
