[chuck-dev] Asio Build and "Debug Assertion Failed" Error.

Gary Scavone gary at music.mcgill.ca
Sat Jun 23 14:21:38 EDT 2007


Hi Philippe,

The latest release of RtAudio is 3.0.3.  It was a minor update from  
3.0.2.  I am working on version 4.0, which will include a number of  
new features that will likely be of interest to ChucK users.  The  
main changes include:

- new support for non-interleaved user data
- additional input/output parameter specifications, including channel  
offset
- new support for dynamic connection of devices (like USB)
- new support for stream time
- revised callback arguments, including separate input and output  
buffer arguments
- revised C++ exception handling
- discontinued support of blocking functionality

There are a few API changes, mainly in the openStream() and callback  
functions.  The new stream parameters allow one to specify a channel  
"offset" on a multichannel device, for example, allowing you to use  
only channels 7 and 8 if desired.  I am also discontinuing support  
for the SGI "al" API, given that I cannot test it anymore.

I've finished the CoreAudio and Windows APIs (DirectSound and ASIO).   
As well, I've made a JACK interface that works in both OS-X and  
Linux.  However, I have yet to work on the ALSA and OSS  
implementations.  Given my current "to do" list, it is unlikely I  
will finish this up before the end of the summer.

So, if you're in a hurry, go with version 3.0.3 but keep in mind that  
you'll probably want to switch to 4.0 when it becomes available.

Regards,

--gary

On 23-Jun-07, at 12:57 PM, Philippe Lamarche wrote:

> I will try to integrate the new version of RTaudio and see what  
> comes up with it. If i understand correctly version RTAudio 3.0.2  
> is alreay in Chuck. This version has  multiple API capacity. I  
> think that I am already compiling for multiple API, but since ChucK  
> doesn't provide any argument to the Rtaudio constructor, it always  
> take ASIO because it's higher in the list than DS.
> If we can provide an argument to RTaudio constructor, probably  
> coming from the command line, it should work.
>
> I will try it in a few days.
>
> Thanks,
> Philippe.
>
> On 6/23/07, Kassen <signal.automatique at gmail.com> wrote: On  
> 6/23/07, Ge Wang <gewang at cs.princeton.edu> wrote:
>
>
> Next we should also figure out how to best roll this into the  
> distro.  Should we include two exe's?  Another eventual option is  
> to finally upgrade to the newest RtAudio, which has runtime support  
> for multiple API's - this will happen sooner or later we think, and  
> we hope to work with Gary Scavone to make transition smoothly.   
> What to do in the meantime?
>
>  I looked over the RTAudio notes on multiple API's in anticipation  
> of the arival of the .exe and that definately seems like the way to  
> go in the future. I'd say that would also be the way to go for Linux.
>
> If you want only one of the two I think ASIO is the obvious choice  
> because there is ASIO4ALL to turn a WM style soundcard into a ASIO  
> suporting one but the other way around doesn't exist (And would be  
> similar to trying to sell a kit that can turn a Ferari into a  
> Trabant). On that topic I think it's very good news that this works  
> with ASIO4ALL according to Consul.
>
> This Windows Media style of audio drivers is realy, realy, terribly  
> slow which I can't stress enough is very bad for realtime (musical)  
> performance. The one thing that's good about it -to me- is that it  
> made me think a lot about creative input quantisation. I realise  
> Princeton is basically all Mac's. If you're used to a Mac I think  
> it might be hard to imagine how attrociously bad and slow Windows  
> Media drivers are.
>
> Maybe two exe's would be best. The files should be very similar  
> which hopefully the zip compression will pick up on?
>
> Also, in the interest of getting lots of feedback on this I still  
> think this should go to the main users list as well but I think  
> that's for Philippe or you to post. It'd be good to know about  
> incompatibilities, issues or potential fire-hazards before this  
> goes into the main distribution.
>
> Kas.
>
> _______________________________________________
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
>
>
> _______________________________________________
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev



More information about the chuck-dev mailing list