[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] will there ever be real multiprocessor support?

To: sc-users@xxxxxxxxxxxxxxxx
Subject: Re: [sc-users] will there ever be real multiprocessor support?
From: Dan Stowell <danstowell@xxxxxxxxx>
Date: Thu, 5 Mar 2009 10:32:03 +0000
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=CxR9m1sNw6Xoig1FXUmZafeJMcge/QYwD2XK9vghpKU=; b=TyOkXyxp2CKZJC4rEHJyAvL8Fz6jlV8GuGAkXckusdoCPI99SMH7lEbvMyPOQlmrcV hKh0lcZT41CsNrdMcLjT9OB9AzyzrRkE8riIlaLnGZ5cDQ6nKmOvmjwXLZ+4xsp3+Z4d koc3yKf66xzmeWylHXlWbVELV0p2e1XAuYkpc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=cZorwJEE/9EA2aqUbiQPopyRCSn2hgiKSTNQ+XpKjOEN0tnkZoOseS9s9TynQVO8id VhrO2kdRaQbhhmkT9kT2NCwDooMgpFrnqCVMJzg/Dm12RtEv88mRcoThobpWqnlpiG83 PWerbNc8svtRyj+VlUKM1Mn+1VtpRmku0r/T0=
In-reply-to: <003AA58D-5A0E-4565-B466-D0EEA2EF24AF@xxxxxxxxxx>
List-id: SuperCollider users mailing list <sc-users.create.ucsb.edu>
References: <83C3FE71-F7FD-4E0A-B20C-2AB216ED9F25@xxxxxxxxxxxxxx> <49AEDD4E.1000207@xxxxxxxxxxxxxxxxx> <4F9C2C6B-9FB5-4758-9F8A-5905358AB356@xxxxxxxxxxxxxx> <49AF2F03.8070208@xxxxxxxxxxxxxxxxx> <1BB8D981-FD57-4DAE-BFC9-7542DF943D5F@xxxxxxxxxxxxxxxxx> <003AA58D-5A0E-4565-B466-D0EEA2EF24AF@xxxxxxxxxx>
Reply-to: sc-users@xxxxxxxxxxxxxxxx
Sender: owner-sc-users@xxxxxxxxxxxxxxxx

Yes, it will need to be attempted, but I'm not sure what approach is
going to suit. I'd like to see scsynth able to run its synths on
different cores, but that will need some kind of dependency graph
analysis in order to understand what can be run before what.

The thing is that a lot of DAWs have a fairly old-school attitude
where each track has an independent processing chain, which makes it
easy to spread the chains over cores. More interesting software like
sc makes that much more tricky...

Max/MSP does support multicore but not automatically. You need to use
a special object that explicitly multicorifies a bit of the graph.

Dan

2009/3/5, Scott Wilson <s.d.wilson.1@xxxxxxxxxx>:
> It may well be that DAWs and other programming environments are
> multiprocessor, but I would be very curious to know how the work is being
> distributed.
>
>  SC *is* multiprocessor. The language and server run in different processes.
> Different threads can run on different processors. Any background OS stuff
> can possibly run on a different core.
>
>  What is not multiprocessor is the audio thread. In order to make it so you
> would in any case need some way of specifying which audio processes are not
> interdependent. Although it may be possible to somehow do this
> automatically, I suspect that any solution would not be syntactically very
> different from just sending things to multiple running server processes, as
> you can do now.
>
>  I also suspect that the DAWs you mention may be dividing things up in a
> similar fashion to SC, e.g. graphics on one core, audio on another. But as I
> said I'd be curious to know more.
>
>  S.
>
>
>  On 5 Mar 2009, at 02:21, Josh Parmenter wrote:
>
>
> > Hi Miguel,
> >
> > This isn't a trivial endeavor. It will require rewriting quite a bit of
> the foundational code in SuperCollider. I imagine it will happen, but not
> quickly. Part of the discussion for work of this scale will also include a
> discussion on possible architecture changes (I would imagine).
> >
> > The major DAWs pay their coders quite a bit for those tools. That is their
> job. Nobody's job here is to build SC. We all have other jobs, and do this
> in our other time. So they really can't be compared. Some of us have already
> looked at this next step, and it is a big one. It is certainly not easy, and
> it will require of most developers the learning of a new tool set. Then -
> add in cross-platform concerns, and a whole new mess is created.
> >
> > Josh
> >
> > On Mar 4, 2009, at 5:46 PM, Miguel Negrao wrote:
> >
> >
> > > But all the major daws (protools, logic, cubasem nuendo, etc) support
> multi-processors, and now even max/msp supports them and csound has
> experimental multi-core on 5.0.9.
> > > I guess putting several servers sending audio to each other through jack
> might be a temporary solution, but still that's a big headache...
> > > Off course I'm not saying it's easy, but it just seems to me that it
> will have to be adressed at some point in order for the sc to not become
> obsolete. Fierceless sc programmers out there, sink your teeth into this
> problem so that you can have the glory of being the one to make sc
> multi-core friendly ! We promise we will build a statue for you! :-)
> > >
> > > Miguel
> > >
> > > ps: how much of delay is there introduced by sending audio between two
> apps using jack ?
> > >
> > > Wouter Snoei escreveu:
> > >
> > > > Hi Miguel,
> > > > as far as I understood this issue gives headaches even to the most
> experienced dsp programmers in the world. AFAIK none of the existing audio
> programming languages deals well with multiprocessor machines; there is
> always some drawback where users have to spawn multiple processes which
> can't interact. I hope some kind of solution will be found for it at some
> point, but I don't think it will soon.
> > > > Please anyone tell me if I'm wrong about this ..
> > > > cheers,
> > > > Wouter
> > > > Op 4 mrt 2009, om 20:58 heeft Miguel Negrao het volgende geschreven:
> > > >
> > > > > A bit out of topic, but what are the prospects that supercollider
> becoming trully multi-processor friendly ?
> > > > > In my case my synths all send audio to each other so i can't even
> use several servers and I'm stuck with using just one core... Computers are
> only going to become more multi-processor from now on, with mac pros with 16
> corea around the corner, so is there a plan to adress this in the future ?
> > > > >
> > > > > --
> > > > > Miguel Negrão // ZLB
> > > > > http://www.friendlyvirus.org/artists/zlb/
> > > > >
> > > > > Wouter Snoei escreveu:
> > > > >
> > > > > > Hi,
> > > > > > I'm researching the possibility to use JackOSX for solving the
> problems I'm experiencing with multiple servers on our WFS system. So far it
> seems to work, but I'm bumping into some kind of maximum inside Jack. When I
> try to boot 8 servers with 96 channels output each (which is what I need for
> our system) it stops after booting the 4th. I've set jack to verbose mode
> and posted the messages I got below. It says "JAR: Cannot register ports" as
> most important message. Could anyone give me a hint on why this happens, and
> if there is a way around it (maybe increasing memory size somewhere)?
> > > > > > It works fine when I set it to less channels (but to me there is
> no use for that), although I need to wait ±5s between every server start. If
> I don't it only starts 3 or 4 in JackRouter and the rest in built-in. The
> occasional boot failures are still present here, but that is not my biggest
> problem. What I hope to accomplish here is to get rid of the clicking, as
> discussed earlier on the list. I'm using SC3.3a rev8828, OSX 10.5.6, jack
> v#0.81.
> > > > > > jack message at first failed server (there are already 4 scsynths
> running here):
> > > > > > SC_AudioDriver: sample rate = 44100.000000, driver's block size =
> 1024
> > > > > > JAR: JackRouterDevice::IsSafeToExecuteCommand
> theAnswer = 1
> > > > > > JAR: JackRouterDevice::StartCommandExecution
> > > > > > JAR: JackRouterDevice::AddIOProc
> > > > > > JAR: JackRouterDevice::Open id 368 name scsynth
> > > > > > JAR: AllocatePorts fInputChannels = 8 fOutputChannels = 96
> > > > > > JAR: Cannot register ports
> > > > > > JAR: DisposePorts
> > > > > > JAR: DisposePorts input 0
> > > > > > JAR: DisposePorts input 1
> > > > > > JAR: DisposePorts input 2
> > > > > > JAR: DisposePorts input 3
> > > > > > JAR: DisposePorts input 4
> > > > > > JAR: DisposePorts input 5
> > > > > > JAR: DisposePorts input 6
> > > > > > JAR: DisposePorts input 7
> > > > > > JAR: DisposePorts output 0
> > > > > > JAR: DisposePorts output 1
> > > > > > JAR: DisposePorts output 2
> > > > > > JAR: DisposePorts output 3
> > > > > > JAR: DisposePorts output 4
> > > > > > JAR: DisposePorts output 5
> > > > > > JAR: DisposePorts output 6
> > > > > > JAR: DisposePorts output 7
> > > > > > JAR: DisposePorts output 8
> > > > > > JAR: DisposePorts output 9
> > > > > > JAR: DisposePorts output 10
> > > > > > JAR: DisposePorts output 11
> > > > > > JAR: DisposePorts output 12
> > > > > > JAR: DisposePorts output 13
> > > > > > JAR: DisposePorts output 14
> > > > > > JAR: DisposePorts output 15
> > > > > > JAR: DisposePorts output 16
> > > > > > JAR: DisposePorts output 17
> > > > > > JAR: DisposePorts output 18
> > > > > > JAR: DisposePorts output 19
> > > > > > JAR: DisposePorts output 20
> > > > > > JAR: DisposePorts output 21
> > > > > > JAR: DisposePorts output 22
> > > > > > JAR: DisposePorts output 23
> > > > > > JAR: DisposePorts output 24
> > > > > > JAR: DisposePorts output 25
> > > > > > JAR: DisposePorts output 26
> > > > > > JAR: DisposePorts output 27
> > > > > > JAR: DisposePorts output 28
> > > > > > JAR: DisposePorts output 29
> > > > > > JAR: DisposePorts output 30
> > > > > > JAR: DisposePorts output 31
> > > > > > JAR: DisposePorts output 32
> > > > > > JAR: DisposePorts output 33
> > > > > > JAR: DisposePorts output 34
> > > > > > JAR: DisposePorts output 35
> > > > > > JAR: DisposePorts output 36
> > > > > > JAR: DisposePorts output 37
> > > > > > JAR: DisposePorts output 38
> > > > > > JAR: DisposePorts output 39
> > > > > > JAR: DisposePorts output 40
> > > > > > JAR: DisposePorts output 41
> > > > > > JAR: DisposePorts output 42
> > > > > > JAR: DisposePorts output 43
> > > > > > JAR: DisposePorts output 44
> > > > > > JAR: DisposePorts output 45
> > > > > > JAR: DisposePorts output 46
> > > > > > JAR: DisposePorts output 47
> > > > > > JAR: DisposePorts output 48
> > > > > > JAR: DisposePorts output 49
> > > > > > JAR: DisposePorts output 50
> > > > > > JAR: DisposePorts output 51
> > > > > > JAR: DisposePorts output 52
> > > > > > JAR: DisposePorts output 53
> > > > > > JAR: DisposePorts output 54
> > > > > > JAR: DisposePorts output 55
> > > > > > JAR: DisposePorts output 56
> > > > > > JAR: DisposePorts output 57
> > > > > > JAR: DisposePorts output 58
> > > > > > JAR: DisposePorts output 59
> > > > > > JAR: DisposePorts output 60
> > > > > > JAR: DisposePorts output 61
> > > > > > JAR: DisposePorts output 62
> > > > > > JAR: DisposePorts output 63
> > > > > > JAR: DisposePorts output 64
> > > > > > JAR: DisposePorts output 65
> > > > > > JAR: DisposePorts output 66
> > > > > > JAR: DisposePorts output 67
> > > > > > JAR: DisposePorts output 68
> > > > > > JAR: DisposePorts output 69
> > > > > > JAR: DisposePorts output 70
> > > > > > JAR: DisposePorts output 71
> > > > > > JAR: DisposePorts output 72
> > > > > > JAR: DisposePorts output 73
> > > > > > JAR: DisposePorts output 74
> > > > > > JAR: DisposePorts output 75
> > > > > > JAR: DisposePorts output 76
> > > > > > JAR: DisposePorts output 77
> > > > > > JAR: DisposePorts output 78
> > > > > > JAR: DisposePorts output 79
> > > > > > JAR: DisposePorts output 80
> > > > > > JAR: JackRouterDevice::FinishCommandExecution
> > > > > > AudioDeviceAddIOProc failed 1852797029
> > > > > > start audio failed.
> > > > > > JAR: HP_Device::Do_StopAllIOProcs
> > > > > > JAR: JackRouterDevice::IsSafeToExecuteCommand
> jack_client_thread_id = 0 pthread_self = -1607059680
> > > > > > JAR: JackRouterDevice::IsSafeToExecuteCommand
> theAnswer = 1
> > > > > > JAR: JackRouterDevice::StartCommandExecution
> > > > > > JAR: HP_Device::StopAllIOProcs 0
> > > > > > JAR: JackRouterDevice::StopAllIOProcs
> > > > > > JAR: JackRouterDevice::FinishCommandExecution
> > > > > > JAR: JackRouterPlugIn::Teardown 1
> > > > > > RESULT = 1
> > > > > > ERROR:
> > > > > > server failed to start
> > > > > > cheers,
> > > > > > Wouter
> > > > > > _______________________________________________
> > > > > > 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/
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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/
> > > > >
> > > > _______________________________________________
> > > > 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/
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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/
> >
>
>
>  _______________________________________________
>  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/

Follow-Ups:
- Re: [sc-users] will there ever be real multiprocessor support?
  - From: Wouter Snoei

References:
- [sc-users] [jack] max amount of channels for Jackosx?
  - From: Wouter Snoei
- Re: [sc-users] [jack] max amount of channels for Jackosx?
  - From: Miguel Negrao
- Re: [sc-users] will there ever be real multiprocessor support? (was: [jack] max amount of channels for Jackosx?)
  - From: Wouter Snoei
- Re: [sc-users] will there ever be real multiprocessor support?
  - From: Miguel Negrao
- Re: [sc-users] will there ever be real multiprocessor support?
  - From: Josh Parmenter
- Re: [sc-users] will there ever be real multiprocessor support?
  - From: Scott Wilson

Prev by Date: Re: [sc-users] win release status
Next by Date: Re: [sc-users] win release status
Previous by thread: Re: [sc-users] will there ever be real multiprocessor support?
Next by thread: Re: [sc-users] will there ever be real multiprocessor support?
Index(es):
- Date
- Thread