So... it just posts a request off to Google every time a user clicks the play button? No caching at all? Wrapping it with WANObjectCache::getWithSetCallback() would give you caching, stampede protection and latency metrics via the WANObjectCache key group dashboard.

No, it saves the audio to a FileBackend, and then subsequent requests (for the same IPA, text and lang combo) use the URL of that file and don't hit Google at all.

My understanding was that WANObjectCache shouldn't be used for larger values (multiple kilobyte, up to maybe 40 or something). Is that not correct?

In T314297#8183839, @Samwilson wrote:

No, it saves the audio to a FileBackend, and then subsequent requests (for the same IPA, text and lang combo) use the URL of that file and don't hit Google at all.

OK, I see that now, sorry.

My understanding was that WANObjectCache shouldn't be used for larger values (multiple kilobyte, up to maybe 40 or something). Is that not correct?

No, the traditional limit for memcached values is 1MB, and we use WANObjectCache for revision text which can be around that size. I see it uses MP3, so it should be <24 KB/s, so you should be able to store ~40 seconds of audio in a single memcached key. Is there any limit on the size of the text?

In T314297#8183927, @tstarling wrote:

No, the traditional limit for memcached values is 1MB, and we use WANObjectCache for revision text which can be around that size. I see it uses MP3, so it should be <24 KB/s, so you should be able to store ~40 seconds of audio in a single memcached key. Is there any limit on the size of the text?

There are hard limits imposed by Google, but we're not limiting from our side (which, come to think of it, we probably should be). Supercalifragilisticexpialidocious is the longest word in our test corpus and produces an audio file ~2 seconds long, so I can't imagine we'll be approaching 1MB/~40 seconds.

What if someone wanted Taumatawhakatangi­hangakoauauotamatea­turipukakapikimaunga­horonukupokaiwhen­uakitanatahu or Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu ? :-)

Note: The chemical composition of titin is probably going too far, although it would still fit in the 5,000 bytes per request Google API limit.

Memcache could have been an option if we had stick with the API approach. Right now we (will) return a path to a file at parsing time so we need it on disk
See T315481: Call IPA Engine from parser hook