> I've been playing a 'wee' bit with ggiplay (the quicktime movie player).
Ah - good. Nice to see someone uses/enhances it.
> - smooth scaling (bad habit for me :)
*grin* - how about finally writing a scale target ?
> - What do I do for sound? I could use GSI (which does -not- work
> for me... the daemon -never- starts)... Maybe I should look
> at a GGI-style sound management library?
Hmm - last time I looked, GSI was geared towards action style games.
I.e. free running midi/CD plus 3D positioned sound-effects.
This is quite a bit different from your current needs which are pretty much
streaming large amounts of PCM data in a synchronized way.
Yes - a GGI-like Lib would be interesting, as there are at least:
OSS, Kernel native drivers, ALSA, network audio servers, dumb /dev/audios,
the Win stuff ...
Unifying this would be great ... but it will need quite some effort and
study of all possible targets to get it right.
> -> Sound-management -requires- threads! (or at least
> processes ie: fork() + SYSV semaphores && shared mem,
> though most sound can be done with just fork() and a pipe)
I see. Yes - at least in the way OSS supports stuff now. With ALSA style
access to DMA pointers and stuff, I can see single-threaded versions, but it
would still be a bit clumsy.
> - Also threading and portability. Linux threads are not
> compatible with Windows threading. And not with any other Unix's
> AFAIK. Maybe another idea? I really don't know. Linux's
> threading model is -very- efficient. Do you know if there's a
> pthread-lib for Windows?
Well - there is always one - forgot the name -, but IIRC it is not preemptive.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
