[Linux-wildo-devel] dataserver packets

[Gabriele D. C. <dar...@io...>]

I am currently rewriting all the dataserver packet structure, this is
basically managed by a few functions but i think it is worth to know
what you think about those 2 ideas and which one is better for you.

We have decided to send along with each data packet (containing the
audio data or whatever) an informational struct that currently contains
the uid (and is planned to contain only it to keep it small, but if
needed can contain something else).

Along with this we can already modify how the payload of those packet
is created, keep in mind that currently we just read and encode the
audio but maybe in future we want to pass it througth various filters.
We can:

A) design the new filter plugin API so that it internally support
filter chains, so each filter will call the next filter on his buffer.
This is a sort of nesting or onion structure.

B) keep the current API (with few changes that are already planned)
and write a variadic AssembleDataServerPacket(DataServerPacketInfo_t
info, ...)
or similar that get called with the list of filters you want to run and
calls them in series managing the buffers internally.
That will make the Filter API much simpler.
This is sort of serialization approach.

C) like B, but you call AddFilterToChain and it gets added to a
internally managed chain of filters, then the we call a ProcessBuffer
that calls all the filters, this is faster than B for sure cause the
filter chain do not need to be re-generated after each call, but
naturally you can't change the filters on the fly cause you need to
re-generate the filter chain.
This is a serialization approach where we can probably use some more C++

A big note is that I have NO idea of which is faster or less resource
consuming, and I would like to hear opinions of everyone on that.

The other BIG note is that those functions are called very often,
probably about every 20ms and we want them to be fast. Instantiating a
class that managed the packet itself instead of a struct looks to me a
bit too slow.


Currently I like idea B/C, C allows us to go on with current code more
easily cause the modifications touch a few the structure, (you just call
a different function after setting up the chain that is anyway done in
some new function).


Best Regards
Gabriele Dini Ciacci

----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org