Il giorno mer, 16/01/2008 alle 14.28 +0100, Denis Oliver Kropp ha scritto: > Claudio Ciccani wrote: > > Il giorno mar, 15/01/2008 alle 21.51 +0100, Denis Oliver Kropp ha > > scritto: > >> Denis Oliver Kropp wrote: > >> This is what I did with the image providers. The server side had the actual > >> implementation using libpng and the client sent the compressed data for > >> loading > >> an image to a surface. > >> > > > > This was the first solution I tried (and of course it could be the best > > one since the original file format can provide better compression than > > FusionSound), but I encountered a lot of problems submitting the file to > > the server. The question is that music providers don't use > > IDirectFBDataBuffers, but DirectStreams instead. So my initial solution > > was to stream the file using a UDP connection on the Voodoo port, but > > this way you can have only one music provider running simultaneously. > > Using different ports for different files is not a safe method because > > it requires to drop any firewall protection. > > You can do a very simple multiplexing, by putting a header with an ID > in front of the compressed data. You'd need a hash table on server side > to lookup the music provider, well, why not simply use the Instance ID > of the music provider interface on server side? > > But I'd prefer adding an IDirectFBDataBuffer between the > IFusionSoundMusicProvider > and the actual data. In many cases the server could even use a local > IDirectFBDataBuffer > implementation, e.g. playing network radio stations. > > But if you're going to play a (client side) file you run the real > implementation on client > side with a dispatcher and use a requestor on server side. This way the > server will ask the > client to send the data as it needs it (synchronous GetData() calls). > > > 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. _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
