[clam-devel] Sample by Sample Processing in Network Editor

Pau Arumi parumi at iua.upf.edu
Thu Dec 21 11:43:58 PST 2006

En/na Xavier Amatriain ha escrit:
> a dummy network with some general-purpose processings (no biggie). Also
> this requires modifying the default Network policy to Blocking and using
> RtAudio instead of PortAudio so this is something I am not sure you want
> to go back to.
no way back. rtaudio is about to be deprecated.
but you can choose blocking NP in linux.
ok now i remember: you need to develop in windows, then let's maintain
the rtdependency as a delta till we implement AudioOut in PortAudio
(blocking mode). this task should be really straightforward.

don't you have more important changes beside that?

> If you think it would be interesting as I said adding a couple of
> processings and the network is simple but what about the other issue?
> Add a few defines here and there?
the other issue is blocking-NP in windows i guess.
for me is ok both options:
- maintain the delta in NetworkEditor/main
- add defines and get rid of delta
it's not really important since we can test it (blocking NP) in linux.

>> 1. redrawing methods depend on timers (since NetEdit4) and it's not done 
>> on Do basis. what are the synthoms?
> I am profiling with Rational Quantify on Windows and I see the Graphics
> thread consuming more time than the processing one. Functions like
> PortWire::draw were called on the order of 2x times the Do was called
> (12000 vs. 5000 for instance). I am saying "were" because in the latest
> profile runs that I have just done I am not seeing this behavior (weird,
> I will report on this later but I am thinking that this might not the
> issue).
david asks: and how many times NetworkCanvas::draw gets called?
>> 2. i think it could be more efficient if we get rid of 
>> different-port-size matching. but more in a policy way than a TData 
>> specialiation. but lets analyse first the situation.
>> are you compiling in release? all regions related checkings are done (or 
>> should) only in debug and they are expensive.  apart from checkings what 
>> operations of produce() and consume() are expensive? have you done any 
>> profiling?
> Hey, who do you think you are talking to? I am the master of
> profiling ;) So, yes, I am running with full optimizations active and
> the problem is not in the debug checkings. Just so you have an idea,
> here is one of the most expensive operations:
> WritingRegion::Produce
> (and inside of it the SreamImpl::RegionHasAdvanced and
> PhantomBuffer::Touch)


how about PhantomBuffer::UpdateBeginning and UpdatePhantom? they should
be zero.

StreamImpl::RegionHasAdvanced should do all things inline. can you see
more about this?

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the clam-devel mailing list