> 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]> =

Reply via email to