[CLAM] Network Editor: Looks fine but no action/sound?

[Pau Arumi]

En/na Johan Ekenberg ha escrit:
>> It may be a bug we recently detected: the flow control doesn't cope with 
>> certain audio system buffer sizes. It leads to some token passing deadlock 
>> and the results are the same you are saying. But we are still caracterizing 
>>     
>
> I tried raising the period to 512 frames and it works. The latency starts to suck of course (now at 34 msec), but there is sound. Perhaps low latency is not an option doing heavy analysis and processing with Clam? Perhaps it's not even relevant?
>   
Interesting. And this goes in the direction of David's suspicions. 
There's a bug in the FlowControl when deciding how to do the 
(processing) firings. Under the conditions of call-back driven.
We'll work on this problem today.
> In another project where I do a lot of FFT and pitch detection, I let the jack callback just append to an internal ring buffer which is significantly larger than the jack buffer, and then a separate thread does work on the ring buffer as soon as it fills up. That way I can use extreme low latency settings in jack (3-4 msec) and still not get any xruns because of computational delays. 
>   
We do all processing in a single thread since we use the analysis data 
to do re-synthesis. Output ports manage the necessary (circular) buffers 
to accommodate reading different buffer sizes, regardless of the size of 
the call-back provided buffer.

I've filled information for this bug and added a new one about the crash 
related to disconnecting from  SMSAnalysisCore.
Feel free to fill further bugs in the bug-tracker. However, it's also 
good to give notice to the list so we are aware of it.
http://clam.iua.upf.edu/bugreporting.html

Thanks for the feedback.

Pau