intfiction.org

I shied away from the NSPipe method early in development and I forget exactly why. I recall reading some scattered reports online that NSPipes had a relatively low lifetime data limit - some tens of MB before they get clogged. I switched to Distributed Objects for moving data around, in much the same way cocoaglk does it except not as well engineered.

I took another crack at CFRunLoop last night, and learned it's safe to send Mach messages inside a signal handler (!!). So CFRunLoop can listen on a Mach port and wake up when it sees the message. Now everything works great - hardware sleep, lower CPU when idle - except timers, which is convenient since I have to rewrite that code anyhow.

The only discussions I see about NSPipe look like buffer size problems, not lifetime transfer problems. (Or people who are failing to read their buffers.) But if your plan works, great. :)

I am going to take this as a signal to go ahead and write up the sound API proposal.

Write away.

The draft chapter is posted:

https://github.com/erkyrath/glk-dev/wik ... ec-changes

Please let me know what I got wrong. :)

Well, I got one obvious thing wrong: the glk_schannel_play_multi() call has no way to start the two sounds on two different channels, which makes it pointless.

For technical reasons, the only practical way to define this capability is to say:

glui32 glk_schannel_play_multi(schanid_t *chanarray, glui32 chancount, glui32 *sndarray, glui32 soundcount, glui32 notify);

...and require that the channel and sound arrays be the same length. Does that seem sufficiently sane?

I also left in some new gestalt selectors from an earlier draft. gestalt_Sound2 is the only new selector in this proposal.

Can you just say that sounds do not start immediately when requested, but are queued up and all start simultaneously at the next glk_select call?

Well, that's a not entirely unelegant solution. :)

What do people think?

Would we want to queue other sound commands as well? (Volume changes, stops, pauses...)

It seems a slightly arbitrary rule to introduce. Given that we're introducing pause and unpause calls, would it perhaps be better to have calls to pause and unpause several channels at once? These could then be the only calls that operate on multiple channels. If you want multiple sounds to start all together, create the channels, pause them, play sounds on them, then unpause them all together. This would require that the spec make it explicit that playing a sound on a paused channel sets it up ready to go but doesn't unpause, though.

That would work too.

However, I'm looking at the OSX/iOS audio toolbox API, and it doesn't have a synchronized pause call. (There's an "unpause at a given time" call, but using that to do synchronized unpauses would require a bit of guesswork.) So I suspect that the Mac/iOS implementation of this stuff will fall more naturally into a synchronized-play model, where the app code synchronizes its decoding of sound data to the audio queue rather than pausing the audio queue itself.

Possibly I'm overthinking this, since I haven't looked at how the current Mac libraries do it. :)

Nobody appears to be enthusiastic about these variations, so I'm sticking with my original proposal (plus the correction I added above).