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

[Pau Arumi]

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)
>   

interesting.

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.