CSL's ThreadedFrameStream (was Re: [CLAM] RT and port sizes (was Re: AudioPorts Usage))

[Pau Arumi]

Stéphane Letz wrote:

>
> Le 20 sept. 05 à 19:26, Xavier Amatriain a écrit :
>
>> After talking to S.T. Pope about his ThreadedFrameStream, this is  
>> more or less what he told me:
>>
>> - The ThreadedFrameStream idea is ONLY used on distributed graphs,  
>> when samples are being streamed onto a different processor or  better 
>> still to a
>> different machine in the network.
>
>
> OK.
>
>> - He basically agrees that because of the cost of context switching  
>> (let appart hiperthreading) is not worth it to thread these things  
>> on a uniprocessor machine.
>> - For these cases they use a different idea that they call the  
>> BlockResizer [1], which is basically the implementation of an  
>> "eager" or "pull" scheduling scheme.
>>
>> [1] http://www.create.ucsb.edu/CSL/doxygen/_block_resizer_8h- 
>> source.html
>>
>>
>
> Ok but I still maintain that when you have to block-resize to  
> implement some kind of algorithm, you may end with implementations  
> that cannot meat RT constraints, and that could run only if you use  
> an aditionnal thread and (possibly) more latency.
> You actually have the same idea in a hard-disk system that use an  
> aditionnal thread allowing the costly disk access (in the context of  
> the RT callback) to be "spread" an executed in the other thread, and  
> having some frames in advance ... even on a uniprocessor machine.
>
> Stephane


Stephane,
Now that you mention this disk-access-in-RT technique, do you
(or other people listening) have any good pointer to documents
on that kind of technique? I'm interested in it for my research.
And not only restricted to disk but in general, which and how
blocking operations are to be avoided. And other RT patterns.

Going back to clam, the point is that disc access in clam is not
RT safe (it just blocks), so we will have to fix that, at some
point.
Of course, when you do callback-based clam apps, you usually
don't need accessing the disk, so it is not a very big problem...

Xavier, I've had a look at the code of CSL for the first time (BTW,
nice naming convention). It seems interesting though I need
to clarify general ideas on their approach. I'll try with their
ICMC2003 paper.

Thanks!
Pau