Claudio Ciccani wrote: > Il giorno mer, 16/01/2008 alle 14.28 +0100, Denis Oliver Kropp ha > scritto: >> Claudio Ciccani wrote: >>> Another inconvenience related to remote music providers is what you >>> described before: you must download the whole data buffer each time the >>> provider writes something into it. This completely fakes the benefit of >>> streaming the compressed file! >> I did not understood the issue here, but in the case of server side music >> providers (remote), the implementation is local to the sound core and can >> directly write into the stream buffer in shared memory. >> > > Sorry, I was talking about sound buffers (IFusionSoundBuffer). > With the music provider's method PlayToBuffer(), you can request the > music provider to store the decode samples in a SoundBuffer and then > access this contents from a callback (e.g., to apply some effects or for > audio visualization). Thus, if you use a remote music provider, decoded > samples should be transferred from the remote instance to the client and > vice versa whenever the buffer gets locked.
I see, it depends on the usage that follows the creation. In theory, a local version of a sound buffer with just a malloced piece of memory and no CoreSoundBuffer would allow a local music provider to write to it, right? But we don't know which way the music provider would be used, same for the buffer :( -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
