[EMAIL PROTECTED] wrote:
>
> Hi Wouter !
Wie geht's !
[ mail ]
> Oops - assumed he already did ...
Teunis mailed me after I posted ;)
> > > This is quite a bit different from your current needs which are pretty much
> > > streaming large amounts of PCM data in a synchronized way.
>
> > Streams are handled by GSI 0.8.x. Synchronizing, well, in that case
> > shared memory streams are probably the way to go (not completed in
> > 0.8.x).
>
> Ah. ggiplay is a simple mov-player based on the quicktime4linux library
> I wrote to have a look at the lib. So synchronization is an important issue
> for that stuff as nothing looks worse, than a movie not in sync with the text.
Yes, well, GSI's streaming is command/message based. The command to the
server is a blocksize + block data. The message from the server is the
amount of data the server has processed so if the server is too slow
(held up by disk access etc), or too fast, you can insert silence or
skip transferring a block depending on the case. That should keep the
difference reasonable but a shm/semaphore approach would be better.
> > > 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 ...
>
> > Check out the library oranization of 0.9.x: gsipcm, gsicd, gsisynth
> > (abstraction in this case is a mistake I think, just do midi and new
> > libs for other formats), gsimixer, and (lib)gsi is the network
> > connection stuff.
>
> This sounds good. You mean, that LibGSI already has the ability to as
> transparently as possible run on about every underlying sounddriver ?
Well, not precompiled. What I mean is that it uses an abstracted system
of pcm/mixer/synth/cd in directly accessable libraries. Compile the
libraries for a new audio system and the server would work on the other
API.
Contrary to graphics, there's not much point in having the sound system
dynamically determine what is available as these system are all kernel
based and very few people switch kernels or unload/reload modules just
to use another system. It would be different for using audiosystems like
NAS/esound etc. but this is a nuisance to program (a huge one! for me at
least) and not as useful as for a graphics libs.
Also, I'm a bit put off by the dlopen portability nightmare (haven't
looked at libtool yet). On a related note, I sent a patch to Neal Tucker
for his spin-2 demo (which uses dlopen and some other ld magic) for
FreeBSD, but haven't been able to get it running on OpenBSD.
Due to the abstraction used for all these libraries though, it would be
easy to make it dynamic (the OSS/devaudio/ultra etc code all use the
same api_* functions that can be set to refer to a dlopen'ed symbol).
> Great, then. I should update my copy to have a look (though it works for me
> as is :-).
Not too fast ;) 0.9.x is a devel version. Various things are broken due
to enormous changes. Also, I've been working on other things so
development has been slow last few months. But as Teunis seemed to be
thinking of writing a complete audio system I thought it would be a good
idea to let it be known how 0.9.x is organized.
Regards,
Wouter
