We started this topic after we 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.
Branded/Custom Browsers: Many mobile phone brands are released with custom browsers. These are mostly buggy, lack some media implementations we require, rarely updated, etc. Fix: Use a well known browser. If chromium based ones are also problematic, please try Firefox.
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.
Confirmed Problems
Whenever we catch a problem we fix it in the next release if we can.
First of all, thanks for this upgrade! There are so many useful features now. Still, there are some problems too: when I try to send fixed transcript, it is sended, but I don’t get a new transcript for check. Instead I get the same text I had before editing and sending (e. t. original transcript)
when I try to send fixed transcript, it is sended, but I don’t get a new transcript for check. Instead I get the same text I had before editing and sending (e. t. original transcript)
Yes, this is correct. In Spontaneous Speech, it is a chain, you cannot get what you did in the next stage, another person should do it. This is intentional, it is a security feature and dataset quality requirement.
So, if person A edited a transcription, another person B should vote it.
If B also edits, you would need person C…
Hi, I know that and it is fully logical, but I spoke about something else.
Someone wrote a transcription for existing audio.
I get this transcript made by someone else and check it on “Review” panel
I send it and instead of getting another transcript for another audio, which I need to check, I get the old transcript for the same audio, that I already approved/fixed mistakes in it.
This behavior happens on my phone.
Hi @Libra, this topic was about the audio issues, thus I kept it short. I answered it in your GitHub issue.
This and some other text/data flow/state management related issues need major code changes, which we solved mostly in code-switching code (which is still not public), and currently we are working on merging them into one code-base so these issues have been resolved.
