Is anyone else noticing that the autoplay audio is taking a while to play when doing reviews?
Before:
Now:
Could be related to the issue where those with external audio devices would get the audio cut off. But yeah Iâve noticed that it doesnât work well at times.
In lessons it might just fail to load and I need to go back to previous item to get it working.
For me its just not even playing at all anymore with a lot of the stuff from my recent lessons
Yeah, Iâm having the same issue. Weird that there are no other threads about it and it hasnât been addressed at all? Noticed it for maybe a week now
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 
I experience the same
I checked my previous comment regarding when the audio is actually loaded. Please keep in mind Iâm not a web developer, and I am just guessing from the web developer console that Safari shows me.
During review the audio is not pre-loaded. Only when you get a reading-answer right, it is loaded.
I suppose that is the reason why the audio is delayed for people with slow internet connection.
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.
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.
Thanks.
This seems reasonable.
Iâm going to mail WK about this so that it will hopefully be looked at.
Please fix this, Wanikani. For anyone who likes to do their reviews fast, itâs like the audio isnât playing at all.
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 hello@wanikani.com. 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!
-Nick at WK
Any updates on this front?
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.
Thanks for clearing things up! I like the very informative explanations about how WaniKani works in the background and why things are like they are. Very convincing.
But I thought WK was fixing and consolidating the code so the same logic can be used in multiple places?
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.
So if there is only one reading, preloading the audio on new question (not on correct answer) would make sense?
Sigh. Iâm just a simple user who just wants to learn Japanese on the side on my daily commute.
I really didnât expect this slow audio playback and itâs slowing down my reviews a lot and not helping with my learning as much as it did.
Is it possible to get a refund of my life time membership?
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.
