This is a great start, thanks @Hanna!
So one of the principles behind the GlkOte protocol is that the Glk API implementation might not even be on the same computer as the GlkOte client! (Indeed, that’s why the initial implementation was called RemGlk + GlkOte - it was designed to be remote.) This means some compromises have to be made for how the Glk API is implemented. I had forgotten that the sound system had one of them.
GlkOte already has one use of a pseudo-RPC for glk_fileref_create_by_prompt. If the stylehint measuring functions ever get implemented they’ll need to be RPCs as well. So it would be possible to use an RPC for glk_schannel_play so that we can return an error.
But I don’t think it would be worth it. Unlike, for example, the file functions, errors wouldn’t be common here. If the sound file is corrupt it’s likely to not play in other interpreters too. The Glk implementation needs access to the blorb and not just the storyfile, so I’d say it would be enough to check if the blorb has the requested sound resource and if it can play that type of resource (ie, does it support MOD files or not), and if it does glk_schannel_play can return 1.
On the delays if you start playing a sound and then try to do many seconds of further work, I don’t think that’s something we should worry about here. Delays are inevitable with GlkOte. (In practice they’re minimal as most uses are single machine, but if it’s actually going over a network then everything will be delayed.) And glk_select_poll is kind of soft-deprecated too:
The GlkOte implementation also needs a blorb, so I think glk_sound_load_hint can just be a NOP, and it doesn’t need to be represented in the protocol.