Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane

From: James McCartney <asynth-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
Subject: Re: Re: supernova v0.1
Newsgroups: gmane.comp.audio.supercollider.devel
Date: Thursday 1st October 2009 22:21:39 UTC (over 9 years ago)
Taking any kind of lock even a spinlock is a no-no on a real time
thread such as the CoreAudio I/O thread. You then have no guarantee
that you will meet your deadline, and if you take too long the Mac OS
X scheduler will degrade your priority. Besides this, you no longer
have any determinate order of access to the bus (do readers get there
before or after writers?), which is important for pipelining data. How
is this dealt with?

On Thu, Oct 1, 2009 at 9:23 AM, Tim Blechmann
 wrote:
>>> the idea is basically to provide an additional osc argument (/p_new),
>>> that allocates a `parallel group' on the server. all nodes in one
>>> `parallel group' can be executed at the same time and can therefore
>>> distributed to different threads. the number of dsp threads can be
>>> configured at startup as command line argument.
>>
>>     Just out of curiosity, the synths in this parallel group can they
>> access busses in the same way as the “normal” supercollider ?
>
> yes, ugens can access busses, which are guarded with reader-writer
> spinlocks ... so multiple In.ar ugens can read from the same bus, while
> only one Out.ar ugen can write to a bus ... the same synchronization
> primitives have to be used for buffers
>
>> Would
>> the type of dsp inside the synthdefs actually matter ?
>
> no, i consider a synth as an atomic unit ....
>
>> What is your
>> thoughts on automatic parallelization of the synthdefs themselves,
>> difficult to do, or just not worth the effort, meaning, it’s enough to
>> have individual synths across several cores.
>
> while a synthdef graph is basically parallel, the units (ugens) are very
> small, so the synchronization overhead could be quite significant ... on
> the other hand, synths may benefit from being executed on one cpu, since
> they usually use little local memory for storing internal audio data,
> which is usually kept in the cpu caches ...
> huge multi-channel synthdefs could benefit from parallelizing, but otoh,
> this may also be done by allocating one synth per channel ...
>
> cheers, tim
>
> --
> tim-xpEK/[email protected]
> http://tim.klingt.org
>
> Wherever we are, what we hear is mostly noise. When we ignore it, it
> disturbs us. When we listen to it, we find it fascinating.
>  John Cage
>
>



-- 
--- james mccartney

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
 
CD: 81ms