[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Re: will there ever be real multiprocessor support?
Josh I think you're talking about something slightly different to JH's
suggestion. I don't think creating extra audio threads is the way to
do it: for a start, CoreAudio (and other apis, I think) use a callback
mechanism which means we aren't actually managing the audio thread
ourselves.
I think it could be possible to implement JH's approach using OpenMP,
where a parallel-group is implemented using an OpenMP "parallel
region" inside scsynth. Check out an OpenMP tutorial to see what I
mean. Others may know more about the likelihood of this approach...
Dan
2009/3/6 Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:
> And I think I understand it now - yes - this does make some sense...
>
> I think I may have an idea about how to do this even. I'll take a look at
> scsynth later today and see if my hunch is correct. My guess is, somewhere
> the audio thread is added... I wonder if the answer may be an OSC message to
> create a second audio thread on the same server, and if this is possible?
> The 'second thread' would be the second group node that James is talking
> about. Shares memory and busses with the first one, but the two thread's
> synths can't reliably feed into each other?
>
> Not even sure of this is how it all works. I'll try to take a look later.
>
> Josh
>
> On Mar 6, 2009, at 6:15 AM, Dan Stowell wrote:
>
>> I had missed this suggestion. It's a very interesting suggestion,
>> essentially it would be the same approach as Max currently uses,
>> allowing the user to explicitly define a parallelisable subgraph.
>> Would one be able to add serial-groups inside a parallel-group? Hope
>> so.
>>
>> I'm trying to remember the parallellisation APIs I read a while back.
>> I think they would make this possible - no technical objections spring
>> to mind yet...
>>
>> (btw it could probably simply be a new property of a group - default
>> serial but can flag as parallel - which would mean very little change
>> to scsynth's osc interface)
>>
>> Dan
>>
>>
>> 2009/3/6 James Harkins <jamshark70@xxxxxxxxx>:
>>>
>>> Is there a technical objection to my suggestion of a second group node
>>> type,
>>> that allows parallelism within it?
>>> It seems to me this is a fairly simple and elegant idea that just might
>>> do
>>> exactly what we need: tell the server that this bunch of nodes must
>>> follow
>>> this other node, and precede the next node, but within it, it's a
>>> free-for-all.
>>> The group node that we have now would be a "serial group," and the new
>>> type
>>> would allow parallelism among its immediate children. So if you wanted to
>>> distribute several source --> effect chains among different threads, you
>>> would have a "parallel group" containing a number of "serial groups."
>>> Within
>>> the serial groups, order of execution is guaranteed, but each of these
>>> serial groups contained within the parallel group could run independently
>>> on
>>> a separate processor.
>>> This is loosely inspired by Faust's parallelism operator, adapted to sc's
>>> node structure. There could easily be a technical reason why this would
>>> simply not work, but in the absence of that reason, it seems to me this
>>> is a
>>> reasonably small conceptual leap for end-users and it would also involve
>>> the
>>> least surgery. (I would say, whatever the final user interface is, it has
>>> to
>>> be simple. SC is confusing enough as it is!)
>>> hjh
>>
>> --
>> http://www.mcld.co.uk
>>
>> _______________________________________________
>> sc-users mailing list
>>
>> info (subscription, etc.):
>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: https://listarc.bham.ac.uk/marchives/sc-users/
>> search: https://listarc.bham.ac.uk/lists/sc-users/search/
>
> ******************************************
> /* Joshua D. Parmenter
> http://www.realizedsound.net/josh/
>
> “Every composer – at all times and in all cases – gives his own
> interpretation of how modern society is structured: whether actively or
> passively, consciously or unconsciously, he makes choices in this regard. He
> may be conservative or he may subject himself to continual renewal; or he
> may strive for a revolutionary, historical or social palingenesis." - Luigi
> Nono
> */
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: https://listarc.bham.ac.uk/marchives/sc-users/
> search: https://listarc.bham.ac.uk/lists/sc-users/search/
>
--
http://www.mcld.co.uk
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/