hi list,
i recorded 3 times in a studio last year that uses a daw/pc interconnection by pyramix, basically it is a hacked windows system, where one or two cores of a multicore cpu are completely hidden from the system. these cores are then acessed directly by the daw and used as a very powerful dsp. the system is incredible! lowest latencies, high trackcount, and the breakout to the adc/dac is a simple network cable.
see here for additional info:
http://www.merging.ch/products/pyramix/masscore
i since wondered if this would be a way to go for puredata? at least on linux it seems very easy to deactivate a core (but i don't know if it than can be used directly by a process) : echo 0 > /sys/devices/system/cpu/cpu1/online for core2 for example.
is this a completely stupid idea? note that i have no idea how hard it would be to implement something like this
thanks for any insight
On Wednesday, September 7, 2016 12:51 PM, Simon Iten itensimon@gmail.com wrote:
hi list,
i recorded 3 times in a studio last year that uses a daw/pc interconnection by pyramix, basically it is a hacked windows system, where one or two cores of a multicore cpu are completely hidden from the system. these cores are then acessed directly by the daw and used as a very powerful dsp. the system is incredible! lowest latencies, high trackcount, and the breakout to the adc/dac is a simple network cable.
see here for additional info:
i since wondered if this would be a way to go for puredata? at least on linux it seems very easy to deactivate a core (but i don't know if it than can be used directly by a process) : echo 0 > /sys/devices/system/cpu/cpu1/online for core2 for example.
is this a completely stupid idea? note that i have no idea how hard it would be to implement something like this
thanks for any insight
Hi Simon, That quite an intriguing design.
It hurts my brain too much to try to assess the difficulty of such an undertaking to
refactor Pure Data to this design.
So let me try a shortcut:
Inside d_ugen.c (which is essentially just dsp algos, so there should be few if any system calls) I see a t_getbytes call. t_getbytes calls calloc.
With the design you linked to, do Pd devs have to reimplement malloc? If the answer is yes, then I'd call this a massively difficult undertaking. If d_* relies on the system calls, then you can bet x_*, m_*, s_*, and g_* do, too, and to a much greater extent.
If the answer is no, I'd like to learn more about the design.
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I believe the solution to these things lies in using Xenomai or other RT extensions for Linux. With Xenomai you take control of the scheduler and you can have one process taking up an entire CPU, while the Linux kernel waits ( or uses other CPUs). Giulio
From: Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>
To: Simon Iten itensimon@gmail.com; Pd-List pd-list@lists.iem.at Sent: Wednesday, 7 September 2016, 18:50 Subject: Re: [PD] disable cores on linux to use as dedicated dsp
On Wednesday, September 7, 2016 12:51 PM, Simon Iten itensimon@gmail.com wrote:
hi list,
i recorded 3 times in a studio last year that uses a daw/pc interconnection by pyramix, basically it is a hacked windows system, where one or two cores of a multicore cpu are completely hidden from the system. these cores are then acessed directly by the daw and used as a very powerful dsp. the system is incredible! lowest latencies, high trackcount, and the breakout to the adc/dac is a simple network cable.
see here for additional info:
i since wondered if this would be a way to go for puredata? at least on linux it seems very easy to deactivate a core (but i don't know if it than can be used directly by a process) : echo 0 > /sys/devices/system/cpu/cpu1/online for core2 for example.
is this a completely stupid idea? note that i have no idea how hard it would be to implement something like this
thanks for any insight
Hi Simon, That quite an intriguing design.
It hurts my brain too much to try to assess the difficulty of such an undertaking to refactor Pure Data to this design. So let me try a shortcut:
Inside d_ugen.c (which is essentially just dsp algos, so there should be few if any system calls) I see a t_getbytes call. t_getbytes calls calloc.
With the design you linked to, do Pd devs have to reimplement malloc? If the answer is yes, then I'd call this a massively difficult undertaking. If d_* relies on the system calls, then you can bet x_*, m_*, s_*, and g_* do, too, and to a much greater extent.
If the answer is no, I'd like to learn more about the design.
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
interesting, bela uses this approach!
so it should not be that hard to adapt it for desktops and laptops
On 09/07/2016 08:01 PM, Giulio Moro wrote:
I believe the solution to these things lies in using Xenomai or other RT extensions for Linux. With Xenomai you take control of the scheduler and you can have one process taking up an entire CPU, while the Linux kernel waits ( or uses other CPUs).
Giulio
------------------------------------------------------------------------ *From:* Jonathan Wilkes via Pd-list <pd-list@lists.iem.at> *To:* Simon Iten <itensimon@gmail.com>; Pd-List <pd-list@lists.iem.at> *Sent:* Wednesday, 7 September 2016, 18:50 *Subject:* Re: [PD] disable cores on linux to use as dedicated dsp > On Wednesday, September 7, 2016 12:51 PM, Simon Iten <itensimon@gmail.com <mailto:itensimon@gmail.com>> wrote: > hi list, > i recorded 3 times in a studio last year that uses a daw/pc > interconnection by pyramix, basically it is a hacked windows system, > where one or two cores of a multicore cpu are completely hidden from the > system. these cores are then acessed directly by the daw and used as a > very powerful dsp. the system is incredible! lowest latencies, high > trackcount, and the breakout to the adc/dac is a simple network cable. > see here for additional info: > http://www.merging.ch/products/pyramix/masscore > i since wondered if this would be a way to go for puredata? at least on > linux it seems very easy to deactivate a core (but i don't know if it > than can be used directly by a process) : echo 0 > > /sys/devices/system/cpu/cpu1/online for core2 for example. > is this a completely stupid idea? note that i have no idea how hard it > would be to implement something like this > thanks for any insight Hi Simon, That quite an intriguing design. It hurts my brain too much to try to assess the difficulty of such an undertaking to refactor Pure Data to this design. So let me try a shortcut: Inside d_ugen.c (which is essentially just dsp algos, so there should be few if any system calls) I see a t_getbytes call. t_getbytes calls calloc. With the design you linked to, do Pd devs have to reimplement malloc? If the answer is yes, then I'd call this a massively difficult undertaking. If d_* relies on the system calls, then you can bet x_*, m_*, s_*, and g_* do, too, and to a much greater extent. If the answer is no, I'd like to learn more about the design. -Jonathan _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
In Bela we use it, but the BeagleBone Black is single-core, so we do not run it 100% CPU because that would prevent Linux from running altogether. My upper limit currently is "how much CPU can I use for my audio while I can still be ssh'd into the board and nicely SIGINT the process", and that is about 92.5%.Above that the audio keeps running but the board becomes irresponsive, so not very practical to do it while developing (needs a power cycle to stop your running program!). Also, not sure how nicely that would play if the kernel does not run for many seconds/minutes/hours ... Will have to try it out. Giulio
From: Simon Iten <itensimon@gmail.com>
To: Giulio Moro giuliomoro@yahoo.it; Jonathan Wilkes jancsika@yahoo.com; Pd-List pd-list@lists.iem.at Sent: Wednesday, 7 September 2016, 21:22 Subject: Re: [PD] disable cores on linux to use as dedicated dsp
interesting, bela uses this approach! http://bela.io/#about so it should not be that hard to adapt it for desktops and laptops
On 09/07/2016 08:01 PM, Giulio Moro wrote:
I believe the solution to these things lies in using Xenomai or other RT extensions for Linux. With Xenomai you take control of the scheduler and you can have one process taking up an entire CPU, while the Linux kernel waits ( or uses other CPUs). Giulio
From: Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>
To: Simon Iten itensimon@gmail.com; Pd-List pd-list@lists.iem.at Sent: Wednesday, 7 September 2016, 18:50 Subject: Re: [PD] disable cores on linux to use as dedicated dsp
On Wednesday, September 7, 2016 12:51 PM, Simon Iten itensimon@gmail.com wrote:
hi list,
i recorded 3 times in a studio last year that uses a daw/pc interconnection by pyramix, basically it is a hacked windows system, where one or two cores of a multicore cpu are completely hidden from the system. these cores are then acessed directly by the daw and used as a very powerful dsp. the system is incredible! lowest latencies, high trackcount, and the breakout to the adc/dac is a simple network cable.
see here for additional info:
i since wondered if this would be a way to go for puredata? at least on linux it seems very easy to deactivate a core (but i don't know if it than can be used directly by a process) : echo 0 > /sys/devices/system/cpu/cpu1/online for core2 for example.
is this a completely stupid idea? note that i have no idea how hard it would be to implement something like this
thanks for any insight
Hi Simon, That quite an intriguing design.
It hurts my brain too much to try to assess the difficulty of such an undertaking to refactor Pure Data to this design. So let me try a shortcut:
Inside d_ugen.c (which is essentially just dsp algos, so there should be few if any system calls) I see a t_getbytes call. t_getbytes calls calloc.
With the design you linked to, do Pd devs have to reimplement malloc? If the answer is yes, then I'd call this a massively difficult undertaking. If d_* relies on the system calls, then you can bet x_*, m_*, s_*, and g_* do, too, and to a much greater extent.
If the answer is no, I'd like to learn more about the design.
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The linux tools you're looking for are CPU sets. You can pin processes to the cores you want. Google "cpuset linux" to get started. The basic command used is "cset"
On Wednesday, September 7, 2016, Simon Iten itensimon@gmail.com wrote:
hi list,
i recorded 3 times in a studio last year that uses a daw/pc interconnection by pyramix, basically it is a hacked windows system, where one or two cores of a multicore cpu are completely hidden from the system. these cores are then acessed directly by the daw and used as a very powerful dsp. the system is incredible! lowest latencies, high trackcount, and the breakout to the adc/dac is a simple network cable.
see here for additional info:
http://www.merging.ch/products/pyramix/masscore
i since wondered if this would be a way to go for puredata? at least on linux it seems very easy to deactivate a core (but i don't know if it than can be used directly by a process) : echo 0 > /sys/devices/system/cpu/cpu1/online for core2 for example.
is this a completely stupid idea? note that i have no idea how hard it would be to implement something like this
thanks for any insight
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
-
Charles Z Henry -
Giulio Moro -
Jonathan Wilkes -
Simon Iten