Hello, I am an ultra-newbie trying to run ChucK for the very first time, and am experiencing difficulties trying to run any of the demos. The source compiled well on OSX 10.3.7, and trying to run ChucK without any input yields: [chuck]: no input files ...... (try --help) which is what the install readme says should happen (?). However, when I try to run any examples, for example demo0.ck, I get a bus error. The last paragraph in the console output says: JAR: DeviceSetProperty inSelf 17915232 JAR: DeviceSetProperty 'sfmt' JAR: Sample Rate: 44100.000000 JAR: Encoding: 1819304813 JAR: FormatFlags: 43 JAR: Bytes per Packet: 4 JAR: Frames per Packet: 1 JAR: Bytes per Frame: 4 JAR: Channels per Frame: 1 JAR: Bits per Channel: 32 time=0.0000s Bus error The jack server is running, and I have the same thing using portaudio as the driver (not coreaudio), as well as built in audio, and not my sound card. Could someone give me some direction in getting this to work? Thanks alot for your time, regards, Stuart Woolford. Australia. ChucK 1.1.5.4 dual 800MHz Quicksilver G4, 768 Mb Ram, Interface: Delta Audiophile 24/96 OSX 10.3.7 _________________________________________________________________ Searching for that dream home? Try http://ninemsn.realestate.com.au for all your property needs.
Hi Stuart! Your bus error may be the result of you being one of the first (ever) to try ChucK on Jack over OS X (which is very cool). We didn't know we are actually supporting this platform - but now is a good time to start. Of all the platform we currently support (OSX-CoreAudio, Linux-ALSA/OSS/Jack, Windows-DirectSound), Jack needs the most work - we have had similar problems (bus error and instability) with Jack on Linux. Dave Robillard, from the Linux Audio Developer List, was good enough to look through our Jack code for ways to improvements and have found some. We hope to integrate the changes soon. What do you think Dave? Back to the bus error, we should also make sure that it's not some other part of ChucK. Have you tried compiling/running ChucK using CoreAudio? If not, that would be the next thing to try. Best, Ge! On Sun, 23 Jan 2005, jimmak cataract wrote:
Hello,
I am an ultra-newbie trying to run ChucK for the very first time, and am experiencing difficulties trying to run any of the demos.
The source compiled well on OSX 10.3.7, and trying to run ChucK without any input yields:
[chuck]: no input files ...... (try --help)
which is what the install readme says should happen (?).
However, when I try to run any examples, for example demo0.ck, I get a bus error. The last paragraph in the console output says:
JAR: DeviceSetProperty inSelf 17915232 JAR: DeviceSetProperty 'sfmt' JAR: Sample Rate: 44100.000000 JAR: Encoding: 1819304813 JAR: FormatFlags: 43 JAR: Bytes per Packet: 4 JAR: Frames per Packet: 1 JAR: Bytes per Frame: 4 JAR: Channels per Frame: 1 JAR: Bits per Channel: 32 time=0.0000s Bus error
The jack server is running, and I have the same thing using portaudio as the driver (not coreaudio), as well as built in audio, and not my sound card.
Could someone give me some direction in getting this to work?
Thanks alot for your time,
regards,
Stuart Woolford. Australia.
ChucK 1.1.5.4 dual 800MHz Quicksilver G4, 768 Mb Ram, Interface: Delta Audiophile 24/96 OSX 10.3.7
_________________________________________________________________ Searching for that dream home? Try http://ninemsn.realestate.com.au for all your property needs.
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
From: Ge Wang
Hi Stuart!
Back to the bus error, we should also make sure that it's not some other part of ChucK. Have you tried compiling/running ChucK using CoreAudio? If not, that would be the next thing to try.
Try using the --silent flag. When fiddeling around in the Linux world we've found this a good way to quick-test if its the audio routines or something else that was broken. It has always been the audio stuff that was wrong BTW. It's quick and dirty, but may be usefull as a first separator of attention. Cheers, Magnus
Hi Ge, If ChucK still relies on RtAudio for its audio I/O support, then there is no Jack support for OS-X. I honestly don't know why someone would want to use Jack in OS-X, since it is built on top of CoreAudio (RtAudio supports CoreAudio directly). And also note that RtAudio supports ASIO on Windows. --gary On Jan 23, 2005, at 11:39 AM, Ge Wang wrote:
Hi Stuart!
Your bus error may be the result of you being one of the first (ever) to try ChucK on Jack over OS X (which is very cool). We didn't know we are actually supporting this platform - but now is a good time to start. Of all the platform we currently support (OSX-CoreAudio, Linux-ALSA/OSS/Jack, Windows-DirectSound), Jack needs the most work - we have had similar problems (bus error and instability) with Jack on Linux. Dave Robillard, from the Linux Audio Developer List, was good enough to look through our Jack code for ways to improvements and have found some. We hope to integrate the changes soon. What do you think Dave?
Back to the bus error, we should also make sure that it's not some other part of ChucK. Have you tried compiling/running ChucK using CoreAudio? If not, that would be the next thing to try.
Best, Ge!
On Sun, 23 Jan 2005, jimmak cataract wrote:
Hello,
I am an ultra-newbie trying to run ChucK for the very first time, and am experiencing difficulties trying to run any of the demos.
The source compiled well on OSX 10.3.7, and trying to run ChucK without any input yields:
[chuck]: no input files ...... (try --help)
which is what the install readme says should happen (?).
However, when I try to run any examples, for example demo0.ck, I get a bus error. The last paragraph in the console output says:
JAR: DeviceSetProperty inSelf 17915232 JAR: DeviceSetProperty 'sfmt' JAR: Sample Rate: 44100.000000 JAR: Encoding: 1819304813 JAR: FormatFlags: 43 JAR: Bytes per Packet: 4 JAR: Frames per Packet: 1 JAR: Bytes per Frame: 4 JAR: Channels per Frame: 1 JAR: Bits per Channel: 32 time=0.0000s Bus error
The jack server is running, and I have the same thing using portaudio as the driver (not coreaudio), as well as built in audio, and not my sound card.
Could someone give me some direction in getting this to work?
Thanks alot for your time,
regards,
Stuart Woolford. Australia.
ChucK 1.1.5.4 dual 800MHz Quicksilver G4, 768 Mb Ram, Interface: Delta Audiophile 24/96 OSX 10.3.7
_________________________________________________________________ Searching for that dream home? Try http://ninemsn.realestate.com.au for all your property needs.
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
Hi Gary! Thanks once again for RtAudio - in addition to straightfoward use and good performance (on most platforms), it really allows us to comfortable focus on designing the language. As you know, most of the software from the soundlab uses RtAudio (including sndpeek, rt_lpc, mosievius, and more), which performs quite solidly on CoreAudio, ALSA, and Win32. The only consistent problem area is with Jack, though part of this may be due to the current state of Jack (it's still pretty sensitive). For example, RtAudio seems to bus error when Jack initialization fails - which we hope to track down soon. I will start a thread on chuck-dev. As for Jack on OSX - I was aware that RtAudio doesn't support it, so it is somewhat surprising the ChucK compiled for Jack on OS X without modifications. This leads me to think that perhaps fixing Jack related issues (whatever they are) under Linux will also help on OS X. It would certainly also make a lot of soundlab software better under Jack. Thanks again, Gary! soundlab software (list to grow soon): http://soundlab.cs.princeton.edu/software/ Best, Ge! On Sun, 23 Jan 2005, Gary P.Scavone wrote:
If ChucK still relies on RtAudio for its audio I/O support, then there is no Jack support for OS-X. I honestly don't know why someone would want to use Jack in OS-X, since it is built on top of CoreAudio (RtAudio supports CoreAudio directly). And also note that RtAudio supports ASIO on Windows.
Hi Ge, My current Linux system is still Fedora 1, so I need to get that updated. Once I do that, I'll look into the Jack bus error thing (since I wasn't having a problem like that before). This is the first time I've heard about this problem ... though I admit I don't always have time to read the ChucK posts. --gary On Jan 23, 2005, at 6:12 PM, Ge Wang wrote:
Hi Gary!
Thanks once again for RtAudio - in addition to straightfoward use and good performance (on most platforms), it really allows us to comfortable focus on designing the language. As you know, most of the software from the soundlab uses RtAudio (including sndpeek, rt_lpc, mosievius, and more), which performs quite solidly on CoreAudio, ALSA, and Win32. The only consistent problem area is with Jack, though part of this may be due to the current state of Jack (it's still pretty sensitive). For example, RtAudio seems to bus error when Jack initialization fails - which we hope to track down soon. I will start a thread on chuck-dev.
As for Jack on OSX - I was aware that RtAudio doesn't support it, so it is somewhat surprising the ChucK compiled for Jack on OS X without modifications. This leads me to think that perhaps fixing Jack related issues (whatever they are) under Linux will also help on OS X. It would certainly also make a lot of soundlab software better under Jack.
Thanks again, Gary!
soundlab software (list to grow soon):
http://soundlab.cs.princeton.edu/software/
Best, Ge!
On Sun, 23 Jan 2005, Gary P.Scavone wrote:
If ChucK still relies on RtAudio for its audio I/O support, then there is no Jack support for OS-X. I honestly don't know why someone would want to use Jack in OS-X, since it is built on top of CoreAudio (RtAudio supports CoreAudio directly). And also note that RtAudio supports ASIO on Windows.
_______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
Hello Ge, Gary, Magnus, everyone! I recompiled the source (make osx), and I get audio now, atleast (running CoreAudio). But I still get these error messages on the console: JAR: Initialize [inSelf, name] : 5332272 chuck JAR: kAudioHardwarePropertyProcessIsMaster err theSize 0 4 JAR: kAudioHardwarePropertyProcessIsMaster err outData 0 0 cannot connect to jack server cannot connect to default JACK server JAR: jack server not running? (**outputs to here, then audio starts) ^C[chuck]: cleaning up... (**stop audio, console prints the following) JAR: Teardown [inSelf, name] : 5332272 chuck JAR: Teardown : AudioHardwareStreamsDied JAR: error code : kAudioHardwareNoError JAR: Teardown : no connection to HAL Is this normal? Anyway, I get audio now, so I can have some fun :) Thanks again for your help, Stuart. _________________________________________________________________ Click here for the latest chart ringtones: http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp
On Sun, 2005-23-01 at 11:39 -0500, Ge Wang wrote:
Hi Stuart!
Your bus error may be the result of you being one of the first (ever) to try ChucK on Jack over OS X (which is very cool). We didn't know we are actually supporting this platform - but now is a good time to start. Of all the platform we currently support (OSX-CoreAudio, Linux-ALSA/OSS/Jack, Windows-DirectSound), Jack needs the most work - we have had similar problems (bus error and instability) with Jack on Linux. Dave Robillard, from the Linux Audio Developer List, was good enough to look through our Jack code for ways to improvements and have found some. We hope to integrate the changes soon. What do you think Dave?
I did run through the code and find some problems with how RTaudio implements it's Jack support. I havn't actually _fixed_ these problems (properly), being very (very) busy with other coding projects at the moment. I understand what RTaudio does, but not completely how ChucK and RTaudio talk to each other (which is important to making things correct of course). As long as audio processing in ChucK is callback driven (ie data is "pulled" by the audio system) making it jack-correct will be simple. If ChucK's audio processing is done in it's own self-driven thread that runs and "pushes data in" to the audio system... things are going to be more difficult to do well (ie a bit of redesign will be necessary) I'll see if I can look at the problem a little more deeply some time soon.. are there any plans for the next release date, roughly? -DR-
On Sun, 2005-23-01 at 11:39 -0500, Ge Wang wrote:
Dave Robillard, from the Linux Audio Developer List, was good enough to look through our Jack code for ways to improvements and have found some. We hope to integrate the changes soon. What do you think Dave?
(Back from the dead!) I have time to look at this now, but it would make the task much easier if someone can just tell me a few things so I don't have to wade through so much code to figure out how everything works (frankly, that RTAudio stuff isn't the most pleasant code in the world to deal with): I noticed RTaudio has a blocking I/O and a callback-driven API. The blocking I/O version will need to be disabled completely for the Jack driver - you can't do that sort of I/O with jack, and there's no way of shoehorning it in there (nicely). There is a Big Nasty Mutex(TM) in the RTAudio jack callback function that needs to go away, which seems to be protecting this I/O based API, but may have other purposes I havn't seen yet (I just took a cursory glance) - Does ChucK use the callback driven API or the I/O one? (please, please say the callback) - Where in ChucK is all the DSP dirty work done? (ie what is the "master" DSP processing function) - Has ChucK been written with an eye towards realtime correctness (ie deterministic dsp processing times), or does it do bad things like allocate memory and lock mutexes in the audio callback? Personally I would rather just not deal with RTaudio and implement a native jack driver, but I understand why you wouldn't like that. Hopefully fixing the jack support will make other things like sndpeek (which I have never, ever gotten to work) and whatever else (STK?) work better under realtime Jack/Linux Cheers, -DR-
On Mar 12, 2005, at 5:29 PM, Dave Robillard wrote:
(Back from the dead!)
Welcome back.
I have time to look at this now, but it would make the task much easier if someone can just tell me a few things so I don't have to wade through so much code to figure out how everything works (frankly, that RTAudio stuff isn't the most pleasant code in the world to deal with):
RtAudio code may not win beauty pageants, but it works. Except on Jack from time to time. Having RtAudio has made ChucK development easier and faster. It is quite solid, too.
I noticed RTaudio has a blocking I/O and a callback-driven API. The blocking I/O version will need to be disabled completely for the Jack driver - you can't do that sort of I/O with jack, and there's no way of shoehorning it in there (nicely). There is a Big Nasty Mutex(TM) in the RTAudio jack callback function that needs to go away, which seems to be protecting this I/O based API, but may have other purposes I havn't seen yet (I just took a cursory glance)
We need to look into this Big Nasty Mutex. I will move this thread to chuck-dev and we will figure it out there.
- Does ChucK use the callback driven API or the I/O one? (please, please say the callback)
callback.
- Where in ChucK is all the DSP dirty work done? (ie what is the "master" DSP processing function)
All the DSP happens in the VM. The native audio engine of ChucK computes the audio before sending it to the soundcard. The ChucK model is completely deterministic down to the sample, and is robust against system timers and external scheduling. It's all in the VM. The actual code that ticks the samples is in the shreduler, in chuck_vm.cpp.
- Has ChucK been written with an eye towards realtime correctness (ie deterministic dsp processing times), or does it do bad things like allocate memory and lock mutexes in the audio callback?
The model in ChucK guarantees that the synthesis is sample-accurate and correct even when real-time breaks. There aren't many tricks to keep things real-time safe, though the virtual machine has pretty good control over getting things to work nicely with audio callbacks and such. It doesn't allocate memory in the callback in steady state, but other bad things could be afoot...
Scratch most of the other questions, I've looked at some of the code and realized some things. Mainly that RTaudio isn't the problem, ChucK itself is doing some /incredibly/ evil things in the audio callback.
Yeah, like we said, there are some egregious things in parts of the code. We designed the thing, however, so that bad things we identified could be modularly swapped out. At least that was the idea.
(looping and checking a "finished processing" flag, and _sleeping_ for a while if it's not?!!). Running a race between the audio callback and some other thread like this just can't happen, it will need to be changed for any sort of decent realtime performance.
This in steady state is not nearly as bad as it looks. The callback should be using the result of the previous block from the synthesis process, and only allows a tiny wait to alleviate potential jitter. The blocking never happens in most cases. We could make this more stable by computing a buffer ahead at the cost of slightly higher latency, but we currently don't. Best, Ge!
On Sat, 2005-12-03 at 23:42 -0500, Ge Wang wrote:
I noticed RTaudio has a blocking I/O and a callback-driven API. The blocking I/O version will need to be disabled completely for the Jack driver - you can't do that sort of I/O with jack, and there's no way of shoehorning it in there (nicely). There is a Big Nasty Mutex(TM) in the RTAudio jack callback function that needs to go away, which seems to be protecting this I/O based API, but may have other purposes I havn't seen yet (I just took a cursory glance)
We need to look into this Big Nasty Mutex. I will move this thread to chuck-dev and we will figure it out there.
The mutex is no big deal, you can literally just comment it out and have things work. If you're using the callback API, it doesn't seem to do anything. It's wrong and needs to be fixed, but the real problem is how chuck uses the audio lib - I've (hackily) removed the mutex in my tree, and ChucK still dies just about as often.
(looping and checking a "finished processing" flag, and _sleeping_ for a while if it's not?!!). Running a race between the audio callback and some other thread like this just can't happen, it will need to be changed for any sort of decent realtime performance.
This in steady state is not nearly as bad as it looks. The callback should be using the result of the previous block from the synthesis process, and only allows a tiny wait to alleviate potential jitter. The blocking never happens in most cases. We could make this more stable by computing a buffer ahead at the cost of slightly higher latency, but we currently don't.
"In most cases" is exactly the problem. So ChucK isn't going to fail and ruin my live performance.. in most cases? Great! :) There can't be one thread doing the audio, and the audio thread peeking at it to see if it's done yet, and expect good RT performance. This is going to have to be changed. Running a race between threads is just not a good idea, and that's exactly what this is - a race. On a properly configured realtime system, the audio thread will be the highest priority thing there is, so you ARE going to lose sometimes. It's much less efficient anyway. Somehow, the audio callback is going to have to be where the audio processing is done - it has to "drive" everything, so to speak. This way the audio callback is deterministic, and does all the DSP directly, instead of attempting to syncronize with some other thread and /blocking/ intentionally. I hope it's not that severe an architechtural change, but for things to work well and be trustworthy, that's what has to be done. :/ -DR-
"In most cases" is exactly the problem. So ChucK isn't going to fail and ruin my live performance.. in most cases? Great! :)
Good point - except that is not what I meant by "in most cases". The callback is designed in a way such that it always favors the synthesis thread to compute apart from the callback thread. But even if the callback thread has to wait (a reasonable amount), which it doesn't "in most cases", it does not interfere with real-time audio. When the processor is maxed, bad things will happen to real-time audio no matter what system you are running. The guarantee in ChucK is that the computations and audio synthesis will still be correct, though potentially late. I am going to save the other points for chuck-dev. We are totally open to changes if it makes ChucK more reliable - but there are reasons for doing things as they are. (I know that may seem shocking!) Best, Ge!
On Sat, 2005-12-03 at 17:29 -0500, Dave Robillard wrote:
On Sun, 2005-23-01 at 11:39 -0500, Ge Wang wrote:
Dave Robillard, from the Linux Audio Developer List, was good enough to look through our Jack code for ways to improvements and have found some. We hope to integrate the changes soon. What do you think Dave?
(Back from the dead!)
(And replying to myself)
I have time to look at this now, but it would make the task much easier if someone can just tell me a few things so I don't have to wade through so much code to figure out how everything works (frankly, that RTAudio stuff isn't the most pleasant code in the world to deal with):
Scratch most of the other questions, I've looked at some of the code and realized some things. Mainly that RTaudio isn't the problem, ChucK itself is doing some /incredibly/ evil things in the audio callback. (looping and checking a "finished processing" flag, and _sleeping_ for a while if it's not?!!). Running a race between the audio callback and some other thread like this just can't happen, it will need to be changed for any sort of decent realtime performance. This is the one I need to know:
- Where in ChucK is all the DSP dirty work done? (ie what is the "master" DSP processing function)
I think this is going to be a lot more work than I thought at first :( -DR-
participants (5)
-
Dave Robillard -
Gary P.Scavone -
Ge Wang -
jimmak cataract -
Magnus Danielson