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

Stéphane Letz letz at grame.fr
Wed Sep 21 02:18:45 PDT 2005


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

>
> Stéphane Letz wrote:
>
>
>>
>> Le 15 sept. 05 à 19:16, Xavier Amatriain a écrit :
>>
>>
>>>
>>> Good that everything stays at home! CSL has been designed by   
>>> S.T.Pope here at CREATE.
>>>
>>
>>
>> Yes I know (-:
>>
>>
>>> He is actually in an office next to mine so I will have a chat  
>>> with  him to know about the rationale behind that design. Thanks  
>>> for the  pointer !
>>>
>>
>>
>>
>> I would be interested to know about his answer, please share !  
>> They  are some good ideas in CSL design ...
>>
>> Stephane
>>
>>
>>
>>>
>>>
>>>
>>>> I think I was not able to explain clearly what I meant... (-:
>>>>
>>>> But after doing some google, I found that in the CREATE CSL    
>>>> documentation (http://www.create.ucsb.edu/CSL/CSL_ICMC_2003.pdf)
>>>>
>>>> A ThreadedFrameStream uses a background
>>>> thread to compute samples. It caches some number of
>>>> buffers from its “producer” sub-graph and supplies
>>>> them to its “consumer” thread immediately on
>>>> demand. It controls the scheduling of the thread of its
>>>> producer. While this obviously introduces latency
>>>> within a DSP graph, it is a known latency with (ideally)
>>>> no latency jitter.
>>>>
>>>> This is typically the kind of solution I was thinking of : use    
>>>> another thread to do the main process and "smooth" CPU use , in   
>>>> the  cost of additional latency
>>>> The same kind of design is also done in Jamin.
>>>>
>>>> And I think doing multithreading correctly will be the next  
>>>> thing  to  do of course on MP machines, but it may help even UP  
>>>> machines.
>>>>
>>>> Stephane
>>>>
>>>>
>>>
>>>
>>>
>>> -- 
>>> /******************************************
>>> *          Xavier Amatriain             *
>>> *          Research Director           *
>>> *            CREATE          *
>>> * University of California Santa Barbara *
>>> ******************************************/
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> CLAM mailing list
>> CLAM at iua.upf.es
>> http://www.iua.upf.es/mtg/clam
>>
>
>
>
> -- 
> /******************************************
> *          Xavier Amatriain             *
> *          Research Director           *
> *            CREATE          *
> * University of California Santa Barbara *
> ******************************************/
>
>






More information about the clam-users mailing list