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