We’ve cleaned up the code for playing pronunciation audio. The changes are all under the hood and should improve audio playback quality and address other bugs.
We no longer write an audio tag through jQuery and append it to the page to play audio. You can still play the audio from your script by simulating a click or keyboard shortcut. You can also get the URLs to the audio by checking jStorage and then play the URL your way.
Is it intentional that the audio now starts playing whenever I extend/collapse the item info after answering a vocabulary reading review correctly? (only happens if I have “Autoplay audio in reviews” enabled)
Sounds great, thanks @WaniKaniJavi! I can confirm this breaks at least one script, as the Double-Check script now plays audio twice during reviews on the preview site, it’s a little demonic. I’ve notified rfindley on the script’s thread.
It looks like the new wkEnableAudio function doesn’t allow you to pass it a boolean to control whether audio is autoplayed and only uses the value of window.audioAutoplay from the initial page load instead of whatever the current value is at the time the function is called. These two changes combined make it difficult to turn off autoplay after the page is loaded. The browser doesn’t guarantee that user scripts load before your code has read the value of window.audioAutoplay, so there is no good way for scripts to disable autoplay currently. Would you consider reinstating either the boolean argument or checking the value of window.audioAutoplay each time the function is called?
The ideal fix would be to both make it accept the boolean argument then change additionalContent.enableButtons to call the function with the current value of audioAutoplay. This would match what you currently do for when you call additionalContent.audio.
Also, can you confirm that the property window.wkEnableAudio is only written to once on initial page load and won’t be written to multiple times throughout the review session?
Is it intentional that audio now stops playing when you move to a different tab for the same item in lessons? On the old site, it continues playing until you move to a different item.
Some updates:
I changed a couple of things on preview.wanikani.com so that it consistently reads from window.audioAutoplay and window.WaniKani.default_voice_actor_id might build our own features on top of these later on… edit to add more detail, opted to do this, because these settings are likely to stick around, but not sure yet about all the other functions you mentioned (will communicate before that changes though) @est_fills_cando
For the questions on the intended behavior or not:
expanding the item does autoplay the embedded player (it’s because there is now more shared code between the player in that item info and the button right below the input field). thought the consistency would be good, but open to feedback on this (can also now control this if you want with the window.audioAutoplay) @Sinyaven
interrupting the audio as you advance vs continuing playing in the background, is intentional, partly for cleaning up the audio instances from memory, and in some cases very delayed playback gives the impression that the audio is mismatched (had a couple of bug reports related to this) @est_fills_cando
For the thing @Sinyaven mentioned about autoplay when expanding item info, my initial reaction to the change has been negative, but I’m continuing to use the preview site to see if it grows on me. The main current annoyance is that sometimes, I will rapidly hit <enter> followed by f to answer the question and then open the info panel so I can look at the alternate meanings. However, if I get the question right, this results in the audio playing twice, with the second playback starting before the first finishes. So it might be good to cancel any attempted infobox audio playback that happens while other audio is still playing.
I’m not sure if it is a coincidence, but I’ve noticed sometimes it takes more than a half second for audio to autoplay on the reading tab during lessons on the preview site. (It only happens sporadically.) Have you considered starting to buffer the audio in lessons when the item is first displayed instead of when the reading tab is opened? I think that would eliminate this and maybe some of the reports of very delayed audio you are receiving.
If your audio loading code is very closely coupled to the audio widget being displayed and that makes this difficult, then you might consider appending <link rel="preload" as="audio" href="audiofile.mp3> for each audio file in the current set of lessons to the head of the document. This has the benefit that it might be easier to implement without needing to modify your existing code.
Just wanted to give a little more context on the autoplay on expanding item info from a learning point of view. I think it’s a positive addition, because the more we hear a word we’re learning, the better we’ll associate it with the kanji. Associating phonology with writing is great for remembering the pronunciation, and ultimately for learning to read. That’s why, during testing, the team asked Javi to keep this feature. (That said, it’s not expected for the audio to play one on top of the other.)
I’ll let Javi answer your more technical points, but wanted to jump in about autoplay
I definitely agree that as a general principle, having more opportunities to hear the pronunciation is good. After doing some more reviews, I have a couple of concrete examples of instances when it bothered me and why:
(1) I have just answered a reading question correctly and have previously answered the meaning question correctly too. However, in the intervening time since answering the meaning question, I have forgotten the meaning and want to check the meaning again by opening the infobox. In this case, hearing the reading is distracting me from my goal of looking up the meaning. Furthermore, I just answered the meaning question correctly, so I heard the meaning audio a few seconds ago and it is repetitive hearing it again so soon. I think this scenario could be fixed by disabling the infobox autoplay when the reading answer is already correct.
(2) I have just answered a reading vocab question incorrectly because I mixed up one of the kanji with another visually similar kanji. In this case, my goal in opening the infobox is to figure out what the correct kanji actually is. In this case, it seems like hearing the correct reading before seeing the correct kanji could make me associate the reading with the incorrect visually similar kanji instead of the actual kanji. This issue is harder to fix since there isn’t an easy way for WaniKani to tell whether I am opening the infobox because of a reason like this vs. knowing the kanji but forgetting the reading.
I should also mention that my perspective is influenced by the fact that I use the Review Audio Tweak 2 script, which causes the reading audio to be played after both reading and meaning questions (but only if you have already gotten the reading right). So I already get exposed to the reading audio about 50% more compared to the default WaniKani experience and don’t feel much urgency to hear the audio even more beyond that.
In this case, hearing the reading is distracting me from my goal of looking up the meaning. Furthermore, I just answered the meaning question correctly, so I heard the meaning audio a few seconds ago and it is repetitive hearing it again so soon.
I personally think you can’t really hear the reading too often (unless they are on top of one another - I’ll concede that that is too much! ). And by hearing the reading when looking up the meaning, for example, you’re hopefully getting another opportunity to associate the two.
I have just answered a reading vocab question incorrectly because I mixed up one of the kanji with another visually similar kanji. In this case, my goal in opening the infobox is to figure out what the correct kanji actually is. In this case, it seems like hearing the correct reading before seeing the correct kanji could make me associate the reading with the incorrect visually similar kanji instead of the actual kanji.
I definitely agree with you on this one! Unless I’m misunderstanding the circumstances, however, the audio shouldn’t play at all if you answer the reading incorrectly. I just double checked and it doesn’t play for me. I wonder if this could be an effect of the Review Audio Tweak 2 script?
I checked again and you’re right. I must have misremembered.
I guess I maybe don’t see much difference between “more audio is good so we should play the audio when you open the infobox even if the same audio just finished playing half a second ago” vs. going even further and saying “more audio is good so we should always play the audio twice in a row even if you don’t open the infobox.”
I'm also not really liking this change in behavior. It feels more like a bug than a feature to me.
We already have a button and hotkey for playing the audio, so having the item info button duplicate this behavior seems wrong to me. It’s especially weird that the audio also plays when collapsing the item info.
I’m not strongly against this change, but I prefer how it was before. But maybe that’s just me, and most people like this feature, so here’s a poll:
How do you feel about the item info button not only expanding/collapsing the item info, but also playing the vocab reading (after correctly answering the reading question during review)?
That’s great!
I guess that’s fine.
I don’t really care, but I prefer the way it was before.
I don’t like it.
I don’t have “autoplay audio” activated, so it doesn’t affect me.
I will note that although I think it’s great, I rarely use the website so it affects me a whole lot less. But I do play the audio a few times on a correct review up until Master at least, so that’s my vote.
Audio is no longer autoplaying for me on the reading pane during lessons on preview.wanikani.com. Also, the j keyboard shortcut to play audio while on the reading pane is not working on the preview site either. I have confirmed:
Both issues still occur with all scripts disabled.
The word actually does have audio and manually clicking the audio button causes it to play.
Trying the exact same actions on www.wanikani.com works as expected.
Besides the audio issue in lessons mentioned in the post immediately before this one, I am also noticing that in reviews, if I answer a question correctly and then press f to open the infobox, the window does not automatically scroll down on preview.wanikani.com like it does on www.wanikani.com. This issue occurs with all scripts disabled. Interestingly, if I close the infobox with f and reopen it with f again, this second opening does cause the window to scroll down.
Edit: Unrelated to the above, but I also noticed that both preview.wanikani.com and www.wanikani.com both have an l/audioAutoplay jStorage variable in addition to window.audioAutoPlay what is the relationship between these two things and if we want to change autoplay, should we be changing both of them? I noticed that just changing window.audioAutoPlay seems to change whether audio autoplays, but then I wonder what the purpose of the jStorage variable is.
Just an update on this, I deployed a change to preview.wanikani.com yesterday that removed the auto play on showing the information panel while doing a lesson quiz or review. This makes it consistent with www.wanikani.com.
There was a regression where this caused autoplay to not work on the reading pane when doing lessons (before quizzes). Fixed that just now.
Didn’t account for this scroll behavior, though this is strange because it should be outside of the audio code in both the current and new version. Will look into it.
l/audioAutoplay is still around for the current code on prod, but the new code on preview does not make use of it. There’s no need to update l/audioAutoplay when the preview code goes to prod.
I’m not sure if this is related to the changes, but over the last few days, I have occasionally gotten an error message when trying to load the preview site. The error message appears to be generated server-side. (The only thing that loads is a blank white page where the only text is a short generic message that an error occurred, without further details.) Trying again after a few minutes has always resolved the issue, but you may want to look into it.
This isn’t related to changes in audio. On lessons because we have fewer subjects, all that data is loaded right away. In reviews they are lazy loaded. When you get the scroll issue, the network request to load the data finishes after the scroll/resize resulting in an incorrect scroll/resize. But on second attempt like you described, it works fine as the data no longer needs to be fetched. (Making this work better is on the list, but not part of the audio work)
Will look into it more, but for sure preview.wanikani has fewer resources than www.
Yeah this is a follow-up to investigate/experiment with after refactoring the audio code so that performance tweaks can be done in one place.
I’ve released 
). And by hearing the reading when looking up the meaning, for example, you’re hopefully getting another opportunity to associate the two.
