I guess it’s related to the thread were no audio is played at all. See my post there:
Basically, I tested a few scenarios, and the interesting thing I found was that if I use my University VPN then the audio plays noticeably later. I usually have a relatively fast internet connection, therefore the audio plays immediately and I never noticed it. But when I turn on the VPN, there will be an additional delay, and I hear the sound often only 1-1.5 seconds later.
I would suggest that if autoplay is enabled, then the audio should be prefetched - but right now it doesn’t.
WaniKani is currently changing a lot on their backend to improve it long-term, but short-term it definitely feels a bit “work-in-progress”. Maybe we can send them an e-mail (or hope a mod notices this thread) so that this issue gets on their current issue tracker, so they can improve it in the next updates
But here the interesting thing: During lessons, the audio is pre-loaded. Before you reach the ‘Reading’-tab, the audio is already loaded at ‘Kanji Composition’ and therefore you experience no delay when the audio should be played.
However, as soon as you get into the lesson-quiz, which has a similar code-base as the review-session, the audio again is only loaded when you get the answer right, thus you experience a delay again.
The best thing would be that the audio is loaded as soon as you reach the reading-question of a certain review item. So that when you get the answer right, it is immediately played (assuming that you cannot read+understand+write the answer all within 1 second ).
Someone could probably even write a userscript to pre-load the audio Or we just wait for WaniKani staff to fix it.
I might send an email too - it’s a long chain of stuff like this that’s caused me to lose a lot of faith in WK over the past few months. Extremely disappointing to see, but hopefully it all gets resolved.
Hey everyone! flippfuzz sent us an email a few days ago letting us know about the issue! We are taking a look into it but if anyone else is experiencing a problem like this, or any issue for that matter, please reach out to us at firstname.lastname@example.org. Describe your issue and include your browser/OS information (and version), and we will do our best to troubleshoot with you or report your issue as a bug!
Hey everyone. I just wanted to jump in and clear up the way audio works at present on Wanikani to hopefully help you understand the reasons it works the way it does and the design decisions I made when updating the audio.
Historically we used a library called Howler to play the audio, but we had quite a lot reported audio issues some of which remained unresolved. When I updated the lesson and reviews at the beginning of the year I decided to simplify the audio code to use plain old HTML5 audio elements everywhere in order to reduce the number of reported bugs. We already used HTML5 audio on the item pages, and the lesson slides aren’t any different so they got updated to match. On the item pages and the lesson slides there is an HTML5 audio element for each voice actor and corresponding reading. The browser will take care of preloading that audio, and different browsers will do this different ways depending on environmental factors (e.g. a mobile device in low power mode will not generally load the audio until there is an explicit user interaction to play it). This should hopefully explain why you see what you see in the network tab on lesson and item pages.
As for quizzes (reviews, lesson quiz, and extra study) I only load the audio after you have answered the question. The reason for this is the audio that is loaded is dependant on the answer that you give. An item may have more than one possible reading each with its own audio pronunciation and we only play the audio of the matching answer as it would be weird to do otherwise. It seemed wasteful (especially for users on mobile networks) to preload all the possible audio when only a fraction of it would be used. This is why you see what you see on the network tab for quizzes.
I thought that as we use a CDN to deliver all the audio, and the CDN is configured to keep the audio as close to the end user as possible, that latency would not be an issue. This is something we will keep an eye on, and your feed back has been noted. Like @WaniConti said, if anyone else has this issue please do send an email so we can get a sense of how large of an issue this latency is.
While this info doesn’t solve your latency issues, hopefully it gives you insight into why it is the way it is currently.
All review formats (general review, extra study quiz, lesson quiz) share the same code base, yes. In these cases the audio is only loaded after you submitted the answer, hence the delay.
As for the lesson study, the audio is (pre-)loaded as soon as the vocab is shown on your screen (that means, already at the “Kanji Composition”-tab).
A technical rigid and better explanation is given by tofugu-scott 3 posts above.
The optimal solution here is to always preload the first audio file, which will cover 95% of cases, eliminating the issue for most vocabulary. Then when the user hits enter, if they have typed in something closer to another reading, load that audio and play it. Otherwise play the preloaded file. Problem solved.
To add to that, how many vocab items actually have multiple readings on here? Seems to me like quite a small number, so does it really matter if every once in a while an extra tiny audio file is being preloaded?
I’m also experiencing this issue, often hearing the audio while on the next item and sometimes it just gets cut off halfway through the recording.