[Linux-wildo-devel] Some news from irc

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

I send this e-mail cause maybe someon can think that the fact that none
write here is because the project is dead :)
Nope! We just really use irc a LOT!

This log was enought interesting to be spread a bit.

Best Regards
Gabriele

<lauwenmark> Is that another LW version ?
<darkschneider> nope :)
<darkschneider> but he wants to try from about weeks
<darkschneider> so i'll give him some time :)
<darkschneider> i'm still workign on the codec move to dataserver
<darkschneider> i have to decide who dictates the codec and how...
<darkschneider> if it's the client, i have to add some packets for the
client to comunicate the control client what codec to use <lauwenmark>
I'd say that the room creator defines it. <darkschneider> yeah
<darkschneider> room creator/room admin
<lauwenmark> As for "how", I'd say "as a parameter of the room creation
request" <darkschneider> for now room admin is just one user, in the
future we have to change that to somethign array <darkschneider> mmm
the how <darkschneider> so you think it's better so..
<lauwenmark> Well, it sounds simple, yet doesn't create new issues.
<darkschneider> i was thinkng to addding a a COTS_SET_CODEC
<darkschneider> CTOS
<darkschneider> cause there is no real reason why you can't change the
codec in the middle of a reunion <lauwenmark> Except that all peers
will have to change as well, which may be impossible if they don't have
to correct codec. <darkschneider> you change it, server brodcast it to
all clients, they stop threads, deinstantiate old codec , instantiate
new, start thread again <darkschneider> yes, that true... if a client
does not have the new codec, he will just get an error <lauwenmark>
Then you have to define a set of permissions to give some users the
right to change codecs. <darkschneider> putting the codec option on
servercreation/room regustration would force to deresiter the room and
reregister it (all klikets kicked) <darkschneider> mmm that has some
sense <darkschneider> but now there is just admin and normal user
<darkschneider> mmmm what about admin list users that have special
permissions, and the client struct contains what are those permissions
<lauwenmark> Or you could have it the fun hard way, and make the
dataserver handle the datastreams in a codec-independent way
internally, converting the stream content on the fly for each client :)
<darkschneider> admin is a var in dataserver struct that hold the uid
of admin users <darkschneider> eheh that woudl requite a cluster of
power :P <darkschneider> ok now dinner <lauwenmark> :) <darkschneider>
i'll go for CTOS_SET_CODEC cause i liket he idea of beeign able to
change codec, for now only the room creator (that is all power admin)
will be able to set the codec <aGu> Sorry, I have to go to sleep, maths
exam tomorrow <aGu> Good night <lauwenmark> cya <darkschneider> ok :)
<lauwenmark> (around 500 CPS on the typing test, BTW, although I'm
noticeably slower in English than in French, obviously) <darkschneider>
500 CPM :) <darkschneider> or you have 50 fingers :) <lauwenmark>
yeah :) <darkschneider> lw clietn si terrible :( <lauwenmark> howso ?
<darkschneider> i really need to clean it's interface <darkschneider>
uggly interface... <darkschneider> was really inexperienced when i
wrote it... <darkschneider> interface/API <darkschneider> have to
recheck instatiation of threads audio and codec sequence to be sure
they can be executed in the rigth order... <lauwenmark> Yep. A simple
flag/trigger should enforce that <darkschneider> mm i just figured out
that i ned to change thread structure <darkschneider> the thread should
read the socket even if audio interface or codec are not instatiarted..
<darkschneider> and trash the data <darkschneider> or when we
instantatiate the missing thing we frinsih up with a LOAD of data to
read <darkschneider> (resulting in a permanent delay that can be teaken
out only if the other side does not send data for soem time)
<darkschneider>   STOC_CODEC_NIAR   Not In A Room <darkschneider> have
a better idea for that scronim? <darkschneider> acronim <lauwenmark>
mmm <lauwenmark> When is that message sent ? <darkschneider> when the
client ask for soom codec and he is not in a room <darkschneider>
soom/room <darkschneider> mm STOC_CODEC_NOROOM is better <lauwenmark>
yep <darkschneider> :)
<darkschneider> i somehow love that adding a new command to lw is
trivial... <darkschneider> parsing it in the client is terrible...
<darkschneider> nonono i'll rewrite the client structure asap
<lauwenmark> :)
* darkschneider hoped to hear someone saying "I will do it" apart his
own voice in his own brain :D <lauwenmark> heh
<lauwenmark> Well, once the protocol is frozen, then I'll do it :)
<darkschneider> hehe
<darkschneider> i hope that you will write a GUI only cause the client
API will be so nice to not ned a reqrite :P <lauwenmark> :D
* lauwenmark just got a request from a girl to send her a drawing :)
<darkschneider> eheh :)
<darkschneider> i said you draw good :)
<lauwenmark> lol
<darkschneider>  * added get_dataserver_by_rid()
<darkschneider> is that name enougth clear?
<darkschneider> i want clear function names..
<darkschneider> get_client_by_uid is the next on the list
<darkschneider> aaghhh, design flaaw
<darkschneider> ok too tired to fix it now...
<lauwenmark> Yes, it looks clear e,ough
<darkschneider> register_dataserver is a bad function cause it
creates_dataserver too :( <lauwenmark> Call it
"get_dataserver_instance", then :) <darkschneider> i'm splitting it to
create_dataserver and register_dataserver so it's the same as client
and controlserver <lauwenmark> yup <darkschneider> the list managemnt
fucntions are not so bad.. <darkschneider> maybe cause it's the 10th
time i write a complete list interface
* darkschneider for soem reason allways end up to use lists a lot
<darkschneider> to use/useing
<lauwenmark> Well, I often start by coding/reusing a list and a stack
implementation in my projects, because I use both a lot <darkschneider>
stack impelentation.. ahhh dream it :) <darkschneider> we neeeeeeeeeed
some nice implementation for audio filters... <lauwenmark> lol, that's
not very hard to implement :) <lauwenmark> yes
<darkschneider> so codec willbecome an audio filter..
<darkschneider> and i can normalize and denoise audio
<darkschneider> but i have totally no idea abotu such thing..
<lauwenmark> Ideally, the interface should provide an input, a plug to
get warned about output, and an information method <darkschneider> you
need to load filter module and such.. <darkschneider> yeah
<darkschneider> so codec realoding will be just a case of a audio
filter load <darkschneider> but ihave no skills to write sucha thing..
<darkschneider> and i prefer to go and look xmms code and copy their
interface <darkschneider> what about lw looking like xmms
<lauwenmark> The input part is easy: just use something like
send_audio_chunk(data); as for output, create an
add_audio_listener(functionpointer_to_callback) <lauwenmark> (with
functionpointer_to_callback being an int fnstuff(data)) <lauwenmark>
(and store all callbacks in a dynamic array in the codec. Case
solved :))
<darkschneider> wow
<lauwenmark> And given that callbacks would have the exact same
prototype as the send_audio_chunk() methods, you can transparently
chain as many codecs as you want <darkschneider> dynamic array.. we
need allready some <lauwenmark> Sure - Vector or Chained lists would do
the job. <darkschneider> adding more chained lists.. <darkschneider> mmm
<darkschneider> ithink we will go for vector...
<darkschneider> even if it's really c++
<lauwenmark> (oh, and you'd need a "remove_audio_listener" as well, so
you can "unplug" something as well) <darkschneider> i'll leave to
youimpemenation of all vectors to sho you my generousity <lauwenmark>
lol <darkschneider> :)
<lauwenmark> There's already a Vector class in the STL if I'm correct,
though <darkschneider> yeah
<darkschneider> i need free_packet() functions tooo .... uffff lot of
work... <darkschneider> every line of code i discover i need 100 more
lines :( sometimes i really do nto see the end <lauwenmark> mmm
<lauwenmark> Well, at least you see a working result now - that's
pretty nice <darkschneider> yes.. not even if lw is "working" none
belive in it :(( <darkschneider> i mean a guy taking cvs can't manage
to use it ;:( <lauwenmark> Well, sure, but we'll work to improve that
for sure :) <lauwenmark> Are you planning to modify a lot of things in
the protocol ? <darkschneider> not so many
<darkschneider> i mean OLD things, nope
<darkschneider> none, the only one was this one related to codec
<darkschneider> adding, many.. since there are still many old things
<darkschneider> makfiles need to be cleaned
<darkschneider> and conditional compilation of alsa added
<darkschneider> alsa/ alsa speex and so on
<darkschneider> so we need some AC_SUBST(@ALSA_OBJ@) and so on
<lauwenmark> mhmh. So make the CVS up to date, so I'll use my free time
Tomorrow to rewrite the audio plugins interface <darkschneider> i have
no words... <darkschneider> i can jsut say thanks...
<lauwenmark> You can just say: "and move your ass, so that the plugins
interface is finished in 24 hours !" :) <darkschneider> i'll commit
when i have done (cut the code in cvs will not anymore able to talk,
cause CTOS_SET_CODEC will be impelemented not today) <darkschneider>
cut/but <darkschneider> eheh gros youa re realling helping a lot with
lw <lauwenmark> lol, I don't think so :) <lauwenmark> I'm better at
telling stories faster than hoxu, for what matters :D <darkschneider>
naaa <darkschneider> btw, a thing i fogot to say to you last time,
there is no need to reimpelnet module loading, i have yoru local copy
on my add and plan to merge it asap i can work on makefiles (i didn0t
liked the thing you needed to install the library system wide to have
lw working, it isn't nice in thsoe time fo developemnt.. they chagne
too often) <darkschneider> and you added too many directories to
lw_audio :SD <lauwenmark> lol - one directory per plugin :)
----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org