Raspberry Pi 3 - server crashes above 65% CPU
Locked
12
12
 
|
Hello list,
I'm doing some experiments running a project on a Raspberry Pi 3, for which I built SC from source using the instructions here: http://supercollider.github.io/development/building-raspberrypi It's running OK, however once the CPU rises above 65% capacity, the server crashes and scsynth needs to be killed off before the code can be run again. There are usually no error messages. Sometimes the following is printed before the crash: JackEngine::XRun: client = SuperCollider was not finished, state = Running JackAudioDriver::ProcessGraphAsyncMaster: Process error And after the crash, the command: s.avgCPU yields a static result, so I assume that it is the server that has crashed. Firstly, is this to be expected? The CPU is set to "performance" mode and I'm running the code from the command line, without scide/emacs. The jack set up is: /usr/local/bin/jackd -P75 -dalsa -dhw:1 -r44100 -p1024 -n3 This has as large a latency as I'd wish to use on this particular project. Sometimes I can run a program for hours at -p1024, other times, for no apparent reason I need to put 2048 to run something a bit heavy. Temperature of the board? At the moment I'm using a Behringer UCA222 USB interface. Without a powered hub the server crashed at around 35 or 45%. I have an stereo "injector sound card" on order. This sits right on the board and doesn't require additional power. It capable of very low latencies apparently and I hope it will help. The other question I wanted to ask is, might supernova be solution? It didn't get built with the instructions cited above, so I don't know if it can be run on a Raspi 3. Using the "nmon" utility, I see that SC is using only one of the 4 cores. I'd be grateful for any suggestions you can send. All the best! Iain -- _________ Iain Mott http://escuta.org _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ |
Re: Raspberry Pi 3 - server crashes above 65% CPU
|
|
hi,
it sounds a bit strange that the server crashes at around 65%. in my experience one can go higher and when overload you normally start hearing dropouts and crackles (xruns). the server can even take that for a while and recover if the load decreases. seldom does the server totally crash. i think sclang and jack more often locks up first. i'd try to figure this out by writing a synthdef that eats a lot of cpu (a static one - not spawning many new synths from sclang). leave it running for a while and then add another one. how high can you go in server cpu? do you get roughly the same performance when using the pi's internal audio vs the external usb card? if you can push you test synthdef much higher and up toward 100% with both audio cards then it's more likely a problem with your sc code. are you passing a lot of data between sclang and scsynth? network clogged up? or doing something that eats up ram? (did you minimise gpu memory to give a bit more ram to the cpu under raspi-config -> advanced?) overheating can be ruled out by temporarily adding a spare computer fan blowing over the board and see if it takes longer time until crash. heatsinks might help but i doubt this a heat issue if it is only sc crashing. also try with another power supply and other usb cables. bad usb cables / supplies can cause a voltage drop and then the system might crash/glitch or power to external usb devices drop when the pi itself is drawing a lot of current. sorry, don't know if supernova could help or if it is at all possible to install on a pi. good luck, _f > 10 jan. 2018 kl. 22:10 skrev [hidden email]: > > Hello list, > > I'm doing some experiments running a project on a Raspberry Pi 3, for which I built SC from source using the instructions here: http://supercollider.github.io/development/building-raspberrypi > > It's running OK, however once the CPU rises above 65% capacity, the server crashes and scsynth needs to be killed off before the code can be run again. There are usually no error messages. Sometimes the following is printed before the crash: > > JackEngine::XRun: client = SuperCollider was not finished, state = Running > JackAudioDriver::ProcessGraphAsyncMaster: Process error > > And after the crash, the command: s.avgCPU yields a static result, so I assume that it is the server that has crashed. > > Firstly, is this to be expected? > > The CPU is set to "performance" mode and I'm running the code from the command line, without scide/emacs. The jack set up is: > > /usr/local/bin/jackd -P75 -dalsa -dhw:1 -r44100 -p1024 -n3 > > This has as large a latency as I'd wish to use on this particular project. Sometimes I can run a program for hours at -p1024, other times, for no apparent reason I need to put 2048 to run something a bit heavy. Temperature of the board? > > At the moment I'm using a Behringer UCA222 USB interface. Without a powered hub the server crashed at around 35 or 45%. I have an stereo "injector sound card" on order. This sits right on the board and doesn't require additional power. It capable of very low latencies apparently and I hope it will help. > > The other question I wanted to ask is, might supernova be solution? It didn't get built with the instructions cited above, so I don't know if it can be run on a Raspi 3. Using the "nmon" utility, I see that SC is using only one of the 4 cores. > > I'd be grateful for any suggestions you can send. > > All the best! > > Iain > > -- > _________ > Iain Mott > http://escuta.org > > > _______________________________________________ > sc-users mailing list > > info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx > archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ > search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ #| fredrikolofsson.com musicalfieldsforever.com |# _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ |
|
|
Thanks a lot Frederik. I should have thought of trying the built-in
audio. With the built-in I can run the program at up to 100% CPU with no crash, just lots of dropouts, so it must be a hardware problem associated with the USB card and I'll try and isolate the exact issue. I wasn't aware of the GPU adjustment either so I set the GPU to 2Mb. Would still like to make use of all 4 cores. If anyone knows about running Supernova on the Pi, please respond. All the best! Iain Em 10/01/2018 21:41, [hidden email] escreveu: > hi, > it sounds a bit strange that the server crashes at around 65%. in my experience one can go higher and when overload you normally start hearing dropouts and crackles (xruns). the server can even take that for a while and recover if the load decreases. seldom does the server totally crash. i think sclang and jack more often locks up first. > > i'd try to figure this out by writing a synthdef that eats a lot of cpu (a static one - not spawning many new synths from sclang). leave it running for a while and then add another one. how high can you go in server cpu? > do you get roughly the same performance when using the pi's internal audio vs the external usb card? > > if you can push you test synthdef much higher and up toward 100% with both audio cards then it's more likely a problem with your sc code. are you passing a lot of data between sclang and scsynth? network clogged up? > or doing something that eats up ram? (did you minimise gpu memory to give a bit more ram to the cpu under raspi-config -> advanced?) > > overheating can be ruled out by temporarily adding a spare computer fan blowing over the board and see if it takes longer time until crash. heatsinks might help but i doubt this a heat issue if it is only sc crashing. also try with another power supply and other usb cables. bad usb cables / supplies can cause a voltage drop and then the system might crash/glitch or power to external usb devices drop when the pi itself is drawing a lot of current. > > sorry, don't know if supernova could help or if it is at all possible to install on a pi. > good luck, > _f > >> 10 jan. 2018 kl. 22:10 skrev [hidden email]: >> >> Hello list, >> >> I'm doing some experiments running a project on a Raspberry Pi 3, for which I built SC from source using the instructions here: http://supercollider.github.io/development/building-raspberrypi >> >> It's running OK, however once the CPU rises above 65% capacity, the server crashes and scsynth needs to be killed off before the code can be run again. There are usually no error messages. Sometimes the following is printed before the crash: >> >> JackEngine::XRun: client = SuperCollider was not finished, state = Running >> JackAudioDriver::ProcessGraphAsyncMaster: Process error >> >> And after the crash, the command: s.avgCPU yields a static result, so I assume that it is the server that has crashed. >> >> Firstly, is this to be expected? >> >> The CPU is set to "performance" mode and I'm running the code from the command line, without scide/emacs. The jack set up is: >> >> /usr/local/bin/jackd -P75 -dalsa -dhw:1 -r44100 -p1024 -n3 >> >> This has as large a latency as I'd wish to use on this particular project. Sometimes I can run a program for hours at -p1024, other times, for no apparent reason I need to put 2048 to run something a bit heavy. Temperature of the board? >> >> At the moment I'm using a Behringer UCA222 USB interface. Without a powered hub the server crashed at around 35 or 45%. I have an stereo "injector sound card" on order. This sits right on the board and doesn't require additional power. It capable of very low latencies apparently and I hope it will help. >> >> The other question I wanted to ask is, might supernova be solution? It didn't get built with the instructions cited above, so I don't know if it can be run on a Raspi 3. Using the "nmon" utility, I see that SC is using only one of the 4 cores. >> >> I'd be grateful for any suggestions you can send. >> >> All the best! >> >> Iain >> >> -- >> _________ >> Iain Mott >> http://escuta.org >> >> >> _______________________________________________ >> sc-users mailing list >> >> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx >> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ >> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ > > #| > fredrikolofsson.com musicalfieldsforever.com > |# > > > _______________________________________________ > sc-users mailing list > > info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx > archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ > search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ -- _________ Iain Mott http://escuta.org _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ |
Re: Raspberry Pi 3 - server crashes above 65% CPU
|
|
Not EXACTLY what you're looking for, but after failing to get Supernova working, I've used all 4 cores on my linux laptop before without Supernova by running 2 servers. I have a quad-core chip, so two of the cores are "virtual" - I'm not clear on what that means, but I am able to hit 100% cpu usage with just 2 servers. Experimentally, I don't go much higher than 70-80% overall usage, as it tends to cause audio glitches if I go any higher. Depending on your setup, maybe you could do something similar. You could send each new note to an alternating server, or you could run different "instruments" on two servers. You could have one server's output passed to another via jackd. You can receive messages in one sclang which could figure out the load balancing to your heart's content. What you CAN'T do is share buffers or transparently re-order nodes between servers. Hope someone figures out Supernova, or this helps in the meantime! <3 On Thu, Jan 11, 2018 at 7:03 AM, <[hidden email]> wrote: Thanks a lot Frederik. I should have thought of trying the built-in audio. With the built-in I can run the program at up to 100% CPU with no crash, just lots of dropouts, so it must be a hardware problem associated with the USB card and I'll try and isolate the exact issue. I wasn't aware of the GPU adjustment either so I set the GPU to 2Mb. |
|
|
Thanks. I'd heard about using more than one server but wasn't sure how to go about doing it. By creating two servers, will these automatically run on two different cores or do you need to specify a core for each server (couldn't see how that would be done). I didn't understand the idea of two virtual cores on a 4 core machine. Is it not possible to run 4 servers, one on each core? Cheers, Iain Em 11/01/2018 15:02,
[hidden email] escreveu:
-- _________ Iain Mott http://escuta.org |
Re: Raspberry Pi 3 - server crashes above 65% CPU
|
|
This is all experimental, so please forgive the lack of specifics: I had a second script that I would run after that for the second server. Linux automatically started the second server on its own core. I am also not sure what's up with only needing two servers; it's possible that my "quad" core is really more of a physical dual core, with some machine virtualization on top of it :) If I were using this method on a regular basis, I would probably figure out a way to merge the scripts, but most of what i do just doesn't require that much power. For your purposes, you may want to look into pinning a process to a given core: https://baiweiblog.wordpress.com/2017/11/02/how-to-set-processor-affinity-in-linux-using-taskset/ On Thu, Jan 11, 2018 at 12:42 PM, <[hidden email]> wrote:
|
|
|
Many thanks sludgefree. Managed to get servers running on the 4 cores of the Pi3. I've pasted my method for this at the end of this message. The only problems is that I don't know how to access the servers once they're all created. For example, the following command in a terminal shows that the 4 servers are running (and I've tested them with taskset and they are associated with each of the 4 cores on the Pi3): pi@raspberrypi:~/scripts $ ps -ef | grep scsynth The first Server was created with NetAddr("127.0.0.1", 57200) - see below Running sclang again, I thought then that I might be able to
create an instance of the server with the following: n = NetAddr("127.0.0.1", 57200); This however results in the following: s1 : setting clientID to 0. It also kills off Server 1 running on core 1. Any suggestions please on what I can do to access the servers created on cores 1-4? I'll paste below the technique I used to create the 4 servers. All the best, Iain
Created 4 .scd files. Contents of launchserver1.scd: n = NetAddr("127.0.0.1", 57200); Contents of launchserver2.scd: n = NetAddr("127.0.0.1", 57201); Contents of launchserver3.scd: n = NetAddr("127.0.0.1", 57202); Contents of launchserver4.scd: n = NetAddr("127.0.0.1", 57203); Then to launch everything, a bash script with the following: #!/bin/bash killall -9 sclang scsynth /usr/bin/taskset -c 0 sclang /home/pi/scripts/launchserver1.scd /usr/bin/taskset -c 1 sclang /home/pi/scripts/launchserver2.scd /usr/bin/taskset -c 2 sclang /home/pi/scripts/launchserver3.scd /usr/bin/taskset -c 3 sclang /home/pi/scripts/launchserver4.scd exit 0 Em 11/01/2018 17:42,
[hidden email] escreveu:
-- _________ Iain Mott http://escuta.org |
|
|
In reply to this post by sludgefree
adding to my last message, the curious thing is that if I do exactly the same thing on my desktop computer, it works. Any reason why it doesn't work on Pi? I also tried using only 2 servers on the pi (on cores 0 and 1 and again on cores 0 and 2) but the same error results: "could not register, too many users". Any ideas? Thanks
___________________ Many thanks sludgefree. Managed to get servers running on the 4 cores of the Pi3. I've pasted my method for this at the end of this message. The only problems is that I don't know how to access the servers once they're all created. For example, the following command in a terminal shows that the 4 servers are running (and I've tested them with taskset and they are associated with each of the 4 cores on the Pi3): pi@raspberrypi:~/scripts $ ps -ef | grep scsynth The first Server was created with NetAddr("127.0.0.1", 57200) - see below Running sclang again, I thought then that I might be able to
create an instance of the server with the following: n = NetAddr("127.0.0.1", 57200); This however results in the following: s1 : setting clientID to 0. It also kills off Server 1 running on core 1. Any suggestions please on what I can do to access the servers created on cores 1-4? I'll paste below the technique I used to create the 4 servers. All the best, Iain
Created 4 .scd files. Contents of launchserver1.scd: n = NetAddr("127.0.0.1", 57200); Contents of launchserver2.scd: n = NetAddr("127.0.0.1", 57201); Contents of launchserver3.scd: n = NetAddr("127.0.0.1", 57202); Contents of launchserver4.scd: n = NetAddr("127.0.0.1", 57203); Then to launch everything, a bash script with the following: #!/bin/bash killall -9 sclang scsynth /usr/bin/taskset -c 0 sclang /home/pi/scripts/launchserver1.scd /usr/bin/taskset -c 1 sclang /home/pi/scripts/launchserver2.scd /usr/bin/taskset -c 2 sclang /home/pi/scripts/launchserver3.scd /usr/bin/taskset -c 3 sclang /home/pi/scripts/launchserver4.scd exit 0 Em 11/01/2018 17:42, [hidden email]
escreveu:
-- _________ Iain Mott http://escuta.org |
|
|
Found a solution which is to increase the maxLogins option of each server to 2. It seems that on the pi, when sclang is killed off after the creation of each server, the client remains attached. On the desktop Ubuntu machine it doesn't. I'm using the following to kill sclang after each server is booted: s.waitForBoot { I tried using 0.exit but that had the unwanted effect of also
killing the scsynth. Is there a better way? I'm happy at least that it's working and I can run synths on the 4 cores. All the best, Iain Em 12/01/2018 10:42, [hidden email]
escreveu:
-- _________ Iain Mott http://escuta.org |
|
|
Hi Iain, Why don't you start the four servers from one sclang client? Will they be created on the same core then? Best, Eric
|
signature.asc (507 bytes) |
|
Hi Eric, it's a good question and someone better qualified might be able answer, but if I run the following lines (on this 8-core machine) in a single sclang client: n = NetAddr("127.0.0.1", 57200); and then run: ps -ef | grep scsynth in a Linux terminal to get the 4 individual PIDs, running "taskset -cp PID" on each one gives: current affinity list: 0-7 So it's a range and not specific core for each PID and perhaps
there's no telling where each core is running. Whereas by running
each server using the taskset utility to set the specific core
number, "taskset -cp PID" returns a specific and unique core
number (as specified in the script) for each server. Iain Em 12/01/2018 13:22,
[hidden email] escreveu:
-- _________ Iain Mott http://escuta.org |
|
|
mott wrote
> Hi Eric, it's a good question and someone better qualified might be able > answer, but if I run the following lines (on this 8-core machine) in a > single sclang client: > > n = NetAddr("127.0.0.1", 57200); > ~s1 = Server.remote("serv1", n ); > ~s1.boot; > n = NetAddr("127.0.0.1", 57201); > ~s2 = Server.remote("serv2", n ); > ~s2.boot; > n = NetAddr("127.0.0.1", 57202); > ~s3 = Server.remote("serv3", n ); > ~s3.boot; > n = NetAddr("127.0.0.1", 57203); > ~s4 = Server.remote("serv4", n ); > ~s4.boot; > > and then run: ps -ef | grep scsynth in a Linux terminal to get the 4 > individual PIDs, running "taskset -cp PID" on each one gives: > > current affinity list: 0-7 > > So it's a range and not specific core for each PID and perhaps there's > no telling where each core is running. Whereas by running each server > using the taskset utility to set the specific core number, "taskset -cp > PID" returns a specific and unique core number (as specified in the > script) for each server. I'm not an "Expert" expert either, but I don't think it's a good idea to lock them to specific cores. Suppose one core gets busy with another, non-scsynth process. By locking scsynth to a core, you've now forced one of your scsynth instances to compete with that other process for CPU cycles. But if you don't lock them, then the OS's load balancing can shift the processes around to use the cores more effectively. I think you should try it without setting processor affinity and see if the result is acceptable. Linux may very well be better at load balancing than manual intervention by a human. hjh -- Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ |
|
|
Thanks James. So the best idea in your view is to spread the load of the
various processes over 4 or servers (or more? - for a 4 core processor) and leave the system to manage their movement across the cores. I have another question: I understand that it isn't possible to pass audio from a node on one server to a node on another directly within SC, but there's no reason why jack couldn't be used as a go-between, is that correct? For example if a global reverberator is run on one server, other nodes on other servers could connect to the reverberator via jack on specific output buses. I haven't tried this yet, but please let me know if there's a better way of doing it. All the best, Iain Em 12/01/2018 18:02, [hidden email] escreveu: > mott wrote >> Hi Eric, it's a good question and someone better qualified might be able >> answer, but if I run the following lines (on this 8-core machine) in a >> single sclang client: >> >> n = NetAddr("127.0.0.1", 57200); >> ~s1 = Server.remote("serv1", n ); >> ~s1.boot; >> n = NetAddr("127.0.0.1", 57201); >> ~s2 = Server.remote("serv2", n ); >> ~s2.boot; >> n = NetAddr("127.0.0.1", 57202); >> ~s3 = Server.remote("serv3", n ); >> ~s3.boot; >> n = NetAddr("127.0.0.1", 57203); >> ~s4 = Server.remote("serv4", n ); >> ~s4.boot; >> >> and then run: ps -ef | grep scsynth in a Linux terminal to get the 4 >> individual PIDs, running "taskset -cp PID" on each one gives: >> >> current affinity list: 0-7 >> >> So it's a range and not specific core for each PID and perhaps there's >> no telling where each core is running. Whereas by running each server >> using the taskset utility to set the specific core number, "taskset -cp >> PID" returns a specific and unique core number (as specified in the >> script) for each server. > I'm not an "Expert" expert either, but I don't think it's a good idea to > lock them to specific cores. Suppose one core gets busy with another, > non-scsynth process. By locking scsynth to a core, you've now forced one of > your scsynth instances to compete with that other process for CPU cycles. > But if you don't lock them, then the OS's load balancing can shift the > processes around to use the cores more effectively. > > I think you should try it without setting processor affinity and see if the > result is acceptable. Linux may very well be better at load balancing than > manual intervention by a human. > > hjh > > > > -- > Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html > > _______________________________________________ > sc-users mailing list > > info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx > archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ > search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ -- _________ Iain Mott http://escuta.org _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ |
|
|
mott wrote
> Thanks James. So the best idea in your view is to spread the load of the > various processes over 4 or servers (or more? - for a 4 core processor) > and leave the system to manage their movement across the cores. Probably. Also, disable hyperthreading in the BIOS settings. > I understand that it isn't possible to pass audio from a node on one > server to a node on another directly within SC, but there's no reason > why jack couldn't be used as a go-between, is that correct? For example > if a global reverberator is run on one server, other nodes on other > servers could connect to the reverberator via jack on specific output > buses. I haven't tried this yet, but please let me know if there's a > better way of doing it. The problem is, the global reverb cannot run until after all of its sources have finished. Supernova handles this by putting the sources (which, if they're independent chains, may be split among cores) into a parallel group, and then the reverb comes after that group. When you have four separate processes, you have no control over this. It becomes probable that the reverb will start processing before all its inputs are ready for some soundcard cycles, and not for other cycles, producing glitches. It *may* be possible to use jack2 (jackdmp), which I've vaguely heard might arrange dependencies between processes and parallelize where possible. But the best you could do in that case would be 3 scsynth instances feeding into the one with the reverb, which might (not guaranteed) parallelize 3 servers but run the 4th in series after them. It's worth reading Tim Blechmann's research on parallel audio processing. People often have exaggerated expectations of the performance gains. He found performance may even be worse in some use cases, where high degrees of parallelism are not possible (but the multicore-aware audio engine still needs to spend time on thread sync). It's not just a case of "pitch things at multiple cores and everything runs faster." http://tim.klingt.org/rd.html hjh -- Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ |
|
|
In reply to this post by mott
mott wrote
> Thanks James. So the best idea in your view is to spread the load of the > various processes over 4 or servers (or more? - for a 4 core processor) > and leave the system to manage their movement across the cores. Probably. Also, disable hyperthreading in the BIOS settings. > I understand that it isn't possible to pass audio from a node on one > server to a node on another directly within SC, but there's no reason > why jack couldn't be used as a go-between, is that correct? For example > if a global reverberator is run on one server, other nodes on other > servers could connect to the reverberator via jack on specific output > buses. I haven't tried this yet, but please let me know if there's a > better way of doing it. The problem is, the global reverb cannot run until after all of its sources have finished. Supernova handles this by putting the sources (which, if they're independent chains, may be split among cores) into a parallel group, and then the reverb comes after that group. When you have four separate processes, you have no control over this. It becomes probable that the reverb will start processing before all its inputs are ready for some soundcard cycles, and not for other cycles, producing glitches. It *may* be possible to use jack2 (jackdmp), which I've vaguely heard might arrange dependencies between processes and parallelize where possible. But the best you could do in that case would be 3 scsynth instances feeding into the one with the reverb, which might (not guaranteed) parallelize 3 servers but run the 4th in series after them. It's worth reading Tim Blechmann's research on parallel audio processing. People often have exaggerated expectations of the performance gains. He found performance may even be worse in some use cases, where high degrees of parallelism are not possible (but the multicore-aware audio engine still needs to spend time on thread sync). It's not just a case of "pitch things at multiple cores and everything runs faster." http://tim.klingt.org/rd.html hjh PS Please trim your quotes... there are messages in this thread with 20 lines of new content and hundreds of lines of quotes. Inconvenient for scrolling. -- Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ |
Re: Raspberry Pi 3 - server crashes above 65% CPU
|
|
Hello, I had some random Pi glitches which I thought were overheating but it turned out that the Pi3 uses a lot more electricity than previous Pis, so the mobile phone charger I was using was not an adequate power supply. The temperature is stored in cheers, Les -- Dr. Charles Céleste Hutchins http://www.berkeleynoise.com/celesteh/podcast/ http://www.bilensemble.co.uk |
|
|
In reply to this post by ddw_music
Just to report back:
Make good progress with the Pi with multiple servers. Set it up so that various sound "sources" are launched on 3 of 4 servers with a system to check which of these has the least number of nodes running, so that new nodes are created on those particular servers. Nodes in the 1st 3 servers are streaming audio (1, 2 and 4 channel) from disk and performing ambisonic encoding and/or transformations then sending 4-cahnnel B-format audio to the output buses. The 4th server, at this point, is set up with a single node that receives the 4-channel audio from nodes in the first 3 servers via jack, performs some global ambisonic transformations and then passes the audio on to the stereo outs via a binaural decoder (all ATK stuff). There's some other serial data being processed too. Before doing this I was running a routine with the above all happening on one server. It was possible to comfortably spatialise 3 sources at any one time without audio glitches. This is without running the X server. SC was running apparently on one core only (always core #3 when I checked) and this ran at between 60 and 75% capacity. The other cores were running at usually well below 5%. With 4 servers and running the same routine, the 4 cores are each running at below 25%, so I'm confident of being able to at least double the number of sources and the limiting factor may be the Pi's ability to read audio from the SD memory. I haven't tried pinning the servers to the cores yet and at this point there doesn't seem to be any need, the load looks well distributed between the cores. So in this experience so far, there does seem to be a distinct advantage in using several servers on the Pi. Thanks everyone for your comments and suggestions, it was a big help! All the best, Iain Em 12/01/2018 22:24, [hidden email] escreveu: > mott wrote >> Thanks James. So the best idea in your view is to spread the load of the >> various processes over 4 or servers (or more? - for a 4 core processor) >> and leave the system to manage their movement across the cores. > Probably. > > Also, disable hyperthreading in the BIOS settings. > > >> I understand that it isn't possible to pass audio from a node on one >> server to a node on another directly within SC, but there's no reason >> why jack couldn't be used as a go-between, is that correct? For example >> if a global reverberator is run on one server, other nodes on other >> servers could connect to the reverberator via jack on specific output >> buses. I haven't tried this yet, but please let me know if there's a >> better way of doing it. > The problem is, the global reverb cannot run until after all of its sources > have finished. Supernova handles this by putting the sources (which, if > they're independent chains, may be split among cores) into a parallel group, > and then the reverb comes after that group. > > When you have four separate processes, you have no control over this. It > becomes probable that the reverb will start processing before all its inputs > are ready for some soundcard cycles, and not for other cycles, producing > glitches. > > It *may* be possible to use jack2 (jackdmp), which I've vaguely heard might > arrange dependencies between processes and parallelize where possible. But > the best you could do in that case would be 3 scsynth instances feeding into > the one with the reverb, which might (not guaranteed) parallelize 3 servers > but run the 4th in series after them. > > It's worth reading Tim Blechmann's research on parallel audio processing. > People often have exaggerated expectations of the performance gains. He > found performance may even be worse in some use cases, where high degrees of > parallelism are not possible (but the multicore-aware audio engine still > needs to spend time on thread sync). It's not just a case of "pitch things > at multiple cores and everything runs faster." > > http://tim.klingt.org/rd.html > > hjh > > PS Please trim your quotes... there are messages in this thread with 20 > lines of new content and hundreds of lines of quotes. Inconvenient for > scrolling. > > > > -- > Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html > > _______________________________________________ > sc-users mailing list > > info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx > archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ > search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ -- _________ Iain Mott http://escuta.org _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ |
Re: Raspberry Pi 3 - server crashes above 65% CPU
|
|
Glad to hear it, congrats! Are you using jackd to route the audio between servers? On Mon, Jan 15, 2018 at 2:19 AM, <[hidden email]> wrote: Just to report back: |
|
|
thanks - yes, 3 servers feeding 4 channels to a 4th server via jack. Cheers, iain Em 15/01/2018 14:18,
[hidden email] escreveu:
-- _________ Iain Mott http://escuta.org |
|
|
The bug that causes non-IDE sclang to consume 100% of of available CPU still exists, right? Could that be contributing here? Tom
|
«
Return to SuperCollider Users New (Use this!!!!)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |