| Author |
Message |
Stochastic
Joined: Feb 25, 2008
Posts: 45
Location: Vancouver
|
 Posted: Mon Oct 06, 2008 6:14 pm Post subject:
Chuck computation lags?
Subject description: do I have to process things in realtime? |
  |
|
Hi, I'm in the process of designing a few things and I keep running into the question of efficiency (i.e. will my processor be able to handle all this in realtime). I'm wondering if there's any way to tell the VM to only start producing audio after all x computations have been completed? Does the VM already do such planning (that'd surprise me)? I've yet to implement my ideas, but I'm aware of how computationally intensive they'd be and it scares me.
_________________
http://greyrock.blogspot.com |
|
|
Back to top
|
|
 |
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 267
|
| Posted: Wed Oct 08, 2008 2:08 pm Post subject:
|
|
|
I dunno 'bout that fancy stuff you're saying, lol, but I notice that even with simple guitar processing programs there are gaps. Well not in the really simple ones but those of greater complexity really.
I'm working on a ChucK-like hardware synthesizer called EChucK that someday soon would enable you to offload some processing burden to some degree, if you don't mind programming dsPIC chips. Before long it may become practical to prototype in ChucK and then manually recode to EChucK for performance reasons.
There I go again advertising my silly little projects, but what the heck...
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
Posted: Wed Oct 08, 2008 2:55 pm Post subject:
Re: Chuck computation lags?
Subject description: do I have to process things in realtime? |
|
|
| Stochastic wrote: | | Hi, I'm in the process of designing a few things and I keep running into the question of efficiency (i.e. will my processor be able to handle all this in realtime). I'm wondering if there's any way to tell the VM to only start producing audio after all x computations have been completed? Does the VM already do such planning (that'd surprise me)? I've yet to implement my ideas, but I'm aware of how computationally intensive they'd be and it scares me. |
Well you don't give much detail here, but if you want to do a lot of computation in a shred without interrupting the audio output, you should stick some "time" into the middle of the computation. Say you have a loop... every 10 times around the loop, advance by a few ms..
| Code: | for (0 => int i; i<1000000> now;
} |
The chuck VM will just run the shred on and on until it sees time advance, so doing something like this will let other things continue while your code continues to iterate. This kind of concurrency without needing to think too hard about synchronizing with other shreds is something that makes chuck pretty awesome imho. Though I'm not entirely sure this is what you're asking.
If you really want to offload calculation as Inventor suggests, you could send data out to another process over OSC and then have it send it back when it's done, which would let another processor core take care of the work. |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 267
|
| Posted: Wed Oct 08, 2008 3:13 pm Post subject:
|
|
|
Nice tricks, radarsat1! Can we have multiple ChucKs running at the same time, one on each processor?
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
Stochastic
Joined: Feb 25, 2008
Posts: 45
Location: Vancouver
|
| Posted: Wed Oct 08, 2008 9:34 pm Post subject:
|
|
|
I guess the other option would be to work out the data that's needed before hand, then save it in a file, then read from that file when it's needed. Is this an option? Is an audio file the only type of file in/out that chuck has implemented thus far?
_________________
http://greyrock.blogspot.com |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 267
|
| Posted: Wed Oct 08, 2008 9:44 pm Post subject:
|
|
|
Yes, sadly this is true, Stochastic. People have worked out tricks to store information, however. You can store the information in ChucK source code format, or you can pack it into sound files. Some folks have posted here on the subject. What is the nature of the data that you need to store? Can you work out the data in an initialization segment of your code and then only have a starting up delay?
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
Posted: Thu Oct 09, 2008 8:29 am Post subject:
Re: Chuck computation lags?
Subject description: do I have to process things in realtime? |
|
|
| radarsat1 wrote: |
| Code: | for (0 => int i; i<1000000> now;
} |
|
Say what?
Remember the HTML...
_________________
Kassen |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Thu Oct 09, 2008 11:05 am Post subject:
|
|
|
| Code: | for (0 => int i; i<1000000> now;
} |
holy crap, sorry. i definitely didn't write it like that. i've disabled html by default in my profile now. how annoying. should have been:
| Code: | // .. do stuff a million times without blocking other shreds
for (0 => int i; i<1000000; i++) {
// .. do stuff ..
3::ms => now;
} |
|
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Thu Oct 09, 2008 11:09 am Post subject:
|
|
|
| Inventor wrote: | | Nice tricks, radarsat1! Can we have multiple ChucKs running at the same time, one on each processor? |
you could but they'd only be able to communicate using something like OSC. Not as convenient as using a public class's static data.
also, you'd have to launch them separately. don't count on chuck being parallelizable in the near to medium future. ;-) |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Thu Oct 09, 2008 1:06 pm Post subject:
|
|
|
using OSC means leaving strong timing behind though, in fact OSC isn't even realtime (formal sense).
I think this is a issue and it's a issue that's akin to the question of waiting for files to be read or soundfonts to be filled that was on debate on the list, recently. We may well want to use some set of parameters for synthesis that may be hard to calculate and only start synthesis after those are "in". Right now all we can do is calculate them, advance time by some amount estimated to be enough for the calculation, and only connect to the dac after that. me.yield() by itself isn't enough.
demo;
| Code: |
now => time start;
float foo;
//calculate ten million square roots
//this takes a bit of time at least
for ( int n; n < 10000000; n++)
{
Math.sqrt(n) => foo;
me.yield();
}
//notice "now" doesn't increase
//yet this should give a cpu a bit of a workout
//don't abort the shred; it should get out of it on it's own
<<<now -start>>>; |
Instead of yielding we might advance time by -say- a ms but advancing time by a ms will result in a 1MHz cpu that just so happens to be able to run (almost) any command in a single cycle. Such a CPU might've ended WWII a year sooner but if you actually need to calculate a million numbers it's quite slow....
_________________
Kassen |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Thu Oct 09, 2008 3:25 pm Post subject:
|
|
|
| Kassen wrote: | | using OSC means leaving strong timing behind though, in fact OSC isn't even realtime (formal sense). |
Maybe i'm not understanding the problem here... can't you just connect the dac after receiving the OSC message?
The problem of waiting until some calculations are done to start the synthesis, and the problem of ensuring these calculations are done by a particular time, are two separate issues. Of course offloading calculations to another process sacrifices real-time-ness, but I don't see why that would be a problem for what was proposed in this thread. He wants to do a bunch of stuff before real-time-ness becomes an issue (for that particular shred, i assume).
If you've got more work to do than fits in an audio vector computation timeblock, then you have to advance 'now' if you want to allow the ugens to continue. There's no real way around that, but I also don't see the problem with doing it.
| Quote: | | I think this is a issue and it's a issue that's akin to the question of waiting for files to be read or soundfonts to be filled that was on debate on the list, recently. |
I think that could be handled by starting the I/O transfer and having an event broadcast itself when it's done. You could then have a shred wait on that event.
Maybe it could be a property of a "File" object:
| Code: | int i[];
File f("listofintegers.txt");
i @=> f.targetArray;
f.doneEvent => now; |
(maybe that reference syntax is a little rough)
| Quote: | | Instead of yielding we might advance time by -say- a ms but advancing time by a ms will result in a 1MHz cpu that just so happens to be able to run (almost) any command in a single cycle. Such a CPU might've ended WWII a year sooner but if you actually need to calculate a million numbers it's quite slow.... |
but advancing time lets every other shred do its stuff. if you advance time by exactly the number of samples in a buffer, it'll just allow that buffer to drop into the dac, and then continue computing without much of a pause.
besides, in your example you don't have to advance time after every sqrt(), you can do it after every 100 sqrt() for example. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Thu Oct 09, 2008 3:59 pm Post subject:
|
|
|
| radarsat1 wrote: |
Maybe i'm not understanding the problem here... can't you just connect the dac after receiving the OSC message? |
In that case yes, I agree, but at the cost of starting a second VM, which -to me- seems like a somewhat roundabout solution to what is a relatively elementary problem.
| Quote: | | The problem of waiting until some calculations are done to start the synthesis, and the problem of ensuring these calculations are done by a particular time, are two separate issues. |
I think I agree. They are different issues but closely related.
[quote]
If you've got more work to do than fits in an audio vector computation timeblock, then you have to advance 'now' if you want to allow the ugens to continue. There's no real way around that, but I also don't see the problem with doing it.[quote]
Well, how would I know there is more work to do then fits in this audo computation? the question may be; "when do I advance time when I want to advance time when I need to in order not to break up audio?". I just saw your post to the list and agree it's hard to talk about this but I maintain it's a real question.
| Quote: | I think that could be handled by starting the I/O transfer and having an event broadcast itself when it's done. You could then have a shred wait on that event.
|
Right now I think that might be a solution, yes. I suspect events may be the one way out of this issue.
| Quote: |
but advancing time lets every other shred do its stuff. if you advance time by exactly the number of samples in a buffer, it'll just allow that buffer to drop into the dac, and then continue computing without much of a pause.
besides, in your example you don't have to advance time after every sqrt(), you can do it after every 100 sqrt() for example. |
Yes, I know, I was just demonstrating the problem. The problem (as I see it) may be "how do I advance time as quickly as I can, without breaking up any audio that may be running?".
_________________
Kassen |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Thu Oct 09, 2008 4:33 pm Post subject:
|
|
|
| Kassen wrote: | | Yes, I know, I was just demonstrating the problem. The problem (as I see it) may be "how do I advance time as quickly as I can, without breaking up any audio that may be running?". |
right, that's a better question. :)
well, to reiterate the mailing list (argh, worlds colliding!), knowing what actual time it is would help, and you're right in saying that you can't do that right now in chuck.
it would also be nice to know how long an audio buffer is in samples and milliseconds.
then you could compare the current "real" time vs. the time of a buffer to see if you're taking too long.
however, as a general rule you can assume the buffer will be at least 5 ms or so. as for how long the calculations will take, that of course depends on the computer hardware and will even change when chuck becomes more optimized. so yeah, until a way of getting the real time is provided, you'd have to use a guestimate. i don't think it's so terrible though. ;-) unless it's like waaay off a good guess will get you pretty far with this problem. even then, just make this a command-line argument or something so it can be easily changed.
anyways it would be great to put a hook to 'gettimeofday' (unix) and 'QueryPerformanceCounter' (windows) into the Std library. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Thu Oct 09, 2008 4:56 pm Post subject:
|
|
|
| radarsat1 wrote: |
anyways it would be great to put a hook to 'gettimeofday' (unix) and 'QueryPerformanceCounter' (windows) into the Std library. |
If you'd look at the list archives you might see that I (in more abstract terms) suggested that some time ago. Well, a long time compared to ChucK's age. admittedly at the time I was looking for a chiming clock and not a solution to a fundamental language problem.... :¬).Still it's a good question and it's one that keeps popping up in various forms lately.
_________________
Kassen |
|
|
Back to top
|
|
|
Stochastic
Joined: Feb 25, 2008
Posts: 45
Location: Vancouver
|
| Posted: Mon Oct 13, 2008 12:24 pm Post subject:
|
|
|
I didn't get any response when I posted this question to the list, so I'm re-posting it here.
If there's an algorithm that requires the last sample's value+ a bunch of heavy computations before it's able to determine the next sample's value, is there any way of writing this soundwave to a file without getting computation-interrupts between every sample value?
If say the rec.ck file (from the examples) was chucked to the VM along with this code, would things just work itself out timing wise? Would the advancement of time in the rec.ck file need to be set to 1::samp=>now; or would the stream of samples out of the dac (no matter what the real-world speed was) fall into the right place in the ,wav file?
_________________
http://greyrock.blogspot.com |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Oct 13, 2008 2:17 pm Post subject:
|
|
|
| Stochastic wrote: |
If there's an algorithm that requires the last sample's value+ a bunch of heavy computations before it's able to determine the next sample's value, is there any way of writing this soundwave to a file without getting computation-interrupts between every sample value?
|
Sure. Let's assume you did set up a WvOut with filenames and stuff and called it "w". Let's assume your "heavy computation" is in some sort of function.
| Code: | Step s => w => blackhole;
while(1)
{
s.last() => heavyComputation() => s.next;
samp => now;
} |
Depending on how heavy "heavy" is this may need to run in --silent mode but it'll work.
Does that answer your question?
_________________
Kassen |
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » ChucK programming language
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
