Audio is regularly delayed, often multiple seconds, before playing, entirely due to network conditions. There are 3 things that could be done to nearly eliminate the issue.
The same could be done for images, but is less critical.
1. Fetch every audio file on the previous card during a quiz. There are multiple ways to preload a file without playing it.
2. Clone all audio files to a more efficient, compressed audio format.
3. Use a free or cheap Cloudflare CDN plan to mirror files on edge nodes, making them far faster to load, increase caching, and reducing outbound network costs from your server.
1. Something like this is planned for later this year
2. The sentence audio needs to be redone at a lower bitrate (it's on my to-do list), but the format is already pretty small, and I'm not, at least at the moment, looking to handle multiple formats based on what the client can handle.
3. Outbound costs are 0 beyond what I pay for base server costs, so that's not an issue. I'd prefer to work on #1/2 first, then see how it works. Additionally, working on regional "paths" to the renshuu server which have shown higher speeds and less variance compared to the usual path that most users' clients take to the server.
Curiosity got the best of me, so I tried a separate batch of the word audio using webm - but the file size actually increased due to the overhead in the files, and how small they were to begin with. Trying out .ogg (for compatible clients), much better results
Making good progress with the sentence audio getting smaller. Almost 66% of the size was cut out, as the voice artists send me the files in high quality formats, and I never got around to resizing them.
I will have settings available tomorrow to test both the new sentence audio, and the new word audio (word is using .ogg). If both work, I can switch the sentences over to the .ogg as well for even more of a speedup.
Curious if you are using Ogg Vorbis or Ogg Opus. Opus seems like a more modern standard for web voice audio.
Do you have network file compression added as well? May not see much more of a boost, but could benefit anyone on a slower network.
For any devops, CDN edge nodes are usually one of the first things setup for a new site with any media content. It is incredibly simple and can sometimes cut ~75% of the egress time, thanks to reduced latency. Self-hosted/rented servers are rarely egress optimized, and don't get priority on networks.
Another simple improvement could be adding long expiration cache headers (if not set already). The files basically never change, and many files will be repeatively requested day over day. The now-decreased file sizes will allow far more to be stored before cache eviction.
Another improvement that could improve speed perception is to auto-trim dead space at the start and end of the audio files. I regularly encounter ones that take a sec to start after each time clicking the button.
That would need some trial and error to make sure to tool correctly trims. Either way, make sure the originals are solidly backed up :)
Thanks again for taking a look. Glad to pique your curiosity
It's honestly something I do need to look into. I feel like the images world be harder to do, as my current setup calls them with a height parameter, and it builds a new sized filewhen necessary, and webp if client allowed.I imagine all of that works have to be done prior to pushing a file to the cdn? Audio world be much easier, I imagine.
Oh, and to answer your earlier question: I tried opus first, but sizes were too big. Looks like the overhead is just a few thousand bytes, but when you are doing 1-3 second files (words, some sentences), the overhead makes it less efficient than mp3 or vorbis.
If there are consistent blocks of the files and you want to get really efficient, you could cut those from the blobs before sending and append it to all audio files on the client.
Plenty of other optimizations available before that though
There's a new setting under experimental to run things off of the cdn I'm testing. Brand new, so most things are not cached yet. Looking into pre-caching on the network.
For sentence and word questions, also pre-fetching audio for the question term (so it loads faster when playing on the result panel.)
It seems to be mostly working well, but ~50% of quizzes starting with an audio file (or intro to new words with speaker icon clicked) take a long time to load. I have very restricted bandwidth currently, so it makes it very noticeable. Files past the first work great!
I haven't looked at the html, but suspect all assets may be loaded at once, giving the main audio file equal priority with the preloaded ones.
If that is the issue, you could try:
- delay preloading until first one is completely loaded (maybe using loading="lazy" attribute), not certain if it works with audio or just add preloads to the Dom after completion or a timer
- use the preload attribute, possibly switching from "metadata" to "auto" with some delay
It could be nice to have an indication on the audio button when clicked. I'm never sure if the click failed, the load failed, or it is just still pending.
Most buttons don't have much of a clicked state, but usually Kao shows up dancing
I've made a number of changes that should hopefully help.
Note: while it's using the html5 audio tag under the hood, this is wrapped around the howler.js library for preloading, etc.
If that first "slow load" is still occurring, and you have access to the web inspector/developer, I'd love to see if you notice anything there - repeated calls, hanging on something else, etc.
