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.
/ Client /
SoundStream(Requestor) ~~ MusicProvider(Requestor) ~~
DataBuffer(Impl/Disp) <- [File]
' ^ ''
| | ||
v v VV
[Core] <= SoundStream(Impl/Disp) <= MusicProvider(Impl/Disp) <-
DataBuffer(Requestor)
/ Server /
The arrows between Client/Server are combined request and response data flow
and should have been
proportional to the traffic.
Most data flows from Client to Server Data Buffer Instance, which is the
compressed file data. Requests
to send the data are very small compared to it (bytes against kbytes).
Some amount of data will be requests from the client to the server Music
Provider to start, stop, pause,
get track information...
Least communication should happen between client and server SoundStream, maybe
some buffer state queries.
The horizontal arrows show the data flow of the compressed (->) and
uncompressed data (=>) on client and
server.
--
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
