latest RtAudio version

yes please for 0.06!
i had to do this as well to use the STK.


Hey jesus

can you post the modifications, I’m just preparing the linux version and suppose it will be no problem to compile 4.0.4.

see u

sure. here it is.

It was some days ago. I’m fairly sure I only changed ofSoundStream.cpp, but I might be wrong. I don’t have a good diff tool on the mac (anyone knows a good alternative to WinMerge for os x? FileMerge sucks) to check now but if there are problems let me know.

These are the changes that I remember:

  • the signature of receiveAudioBufferAndCallSimpleApp has changed and now accepts in & out buffers
  • in audio->openStream (ofSoundStreamSetup) we were passing RTAUDIO_FLOAT64 as the format but then casting the in&out buffers to float in the callback. This gave me errors. I changed it to RTAUDIO_FLOAT32 and now it works
  • parameters to openStream are now passed as RtAudio::StreamParameters

I think that’s it.

As a disclaimer: This code compiles for me and I’m able to use it with the audio examples and some experiments that I did, but I’m just a beginner tinkering, so watch out for explosions :slight_smile:

grab it here…–4.0.4.cpp


I’ve adapted your changes to the new version with events, and it compiles and run, but in the audioOutputExample I get some noise mixed with the sinusoidal wave the previous version generated.

Did you change something in the example too? Perhaps is only a linux issue

hey arturo. that sounds like the problem I had with RTAUDIO_FLOAT64 vs RTAUDIO_FLOAT32. I’ll check later today (sorry, cannot do it now) and let you know.

Turned out I could.

I’ve made a test, duplicating again the of0.05_FAT folder and then just changing the version of RtAudio and the ofSoundStream that I uploaded and I can run and hear audioOutputExample without problems. So perhaps a linux issue? I’m in a hurry now but I’ll do more thorough testing later.

joerg… what platform are you on? any glitches you run into?



now it’s getting better although there are still some glitches.

I’ve done these changes in ofSoundStreamSetup:

RtAudio::StreamParameters outputParameters;  
outputParameters.deviceId = audio->getDefaultOutputDevice();  
outputParameters.nChannels = 2;  
RtAudio::StreamParameters inputParameters;  
inputParameters.deviceId = audio->getDefaultInputDevice();  
inputParameters.nChannels = 2;  
unsigned int bufferFrames = 256; // 256 sample frames  
try {  
	audio ->openStream( &outputParameters, &inputParameters, RTAUDIO_FLOAT32, sampleRate, &bufferFrames, &receiveAudioBufferAndCallSimpleApp);  
} catch (RtError &error) {  


RtAudio::StreamParameters * outputParameters=NULL;  
if(nOutputChannels >0){   
	outputParameters = new RtAudio::StreamParameters();  
	outputParameters->deviceId = audio->getDefaultOutputDevice();  
	outputParameters->nChannels = nOutputChannels;  
RtAudio::StreamParameters * inputParameters = NULL;  
	inputParameters = new RtAudio::StreamParameters;  
	inputParameters->deviceId = audio->getDefaultInputDevice();  
	inputParameters->nChannels = nInputChannels;  
unsigned int bufferFrames = 256; // 256 sample frames  
try {  
	audio ->openStream( outputParameters, inputParameters, RTAUDIO_FLOAT32, sampleRate, &bufferFrames, &receiveAudioBufferAndCallSimpleApp);  
} catch (RtError &error) {  

Also that variable bufferFrames = 256 with that fixed value doesn’t look very good, but don’t know exactly what it is. Any ideas?

about bufferFrames

The bufferFrames parameter specifies the desired number of sample frames that will be written to and/or read from a device per write/read operation. This parameter can be used to control stream latency though there is no guarantee that the passed value will be that used by a device. In general, a lower bufferFrames value will produce less latency but perhaps less robust performance. A value of zero can be specified, in which case the smallest allowable value will be used.


it might be indeed related to your glitches. try to rise that value.

Nice to see your changes.


I can also see the glitches in the wave visualization, so i suposse the problem is with the wave generation. Is like a change in phase, visually it seems like the wave is going backwards.

The weird thing is I can also see the same effect with the previous version, but the sound is perfectly clear.

I’ve uploaded the modifications over Jesus code to:…-m4.0.4.cpp

or with events:…-events.cpp

also rtAudio compiled for linux:


unsigned int bufferFrames = 256; // 256 sample frames

was the bufferSize parameter in the ofStreamSetup

I cannot get rid of the glitches and not sure if it’s only my computer or is some bug in the code, so if anyone else can test…

cool. the modified code works for me on osx. let’s see if some other can test on linux or win.

hope this goes into the next release!

OK I had a look at RtAudio problems under Linux.
The clicks you are experiencing Arturo are most likely buffer underruns, which means RtAudio is not providing audio samples fast enough to the sound card…therefore there are gaps in the audio stream which manifest as clicks.

Some changes in RtAudio 4.0.4 (haven’t tested the earlier 4.0 series) have made the api a little less responsive or at least more vulnerable to buffer underruns it seems, at least under Linux. Different sound cards will have different results, however I am testing on a standard Intel integrated sound chip found in many laptops. These are crappy sound cards and often experience these problems.

The buffer underruns are worse when using Events, however I was still not able to get a clean stream using regular OF. I tried both ALSA and JACK.

A common way to fix buffer underruns is to increase the size of the audio buffer (i.e. from 256 to 1024, 2048 etc…) however this also increases the latency of the audio application. However doing this in my case improves the stream but I still get occasional pops.

What did fix the problem however was to run the application as super-user. This raises the priority of the app and ensures the samples are fed to the card in time.

One way to proceed with this could be to test earlier versions of RtAudio version 4 to see if they are better, or to contact Gary Scavone, the author of RtAudio and raise a bug. He may however just ignore the request…as integrated laptop sound cards are not really meant for “real-time” audio processing.

I noticed that the test sine wave in Pure Data using Alsa also experienced some clicks…so it’s not necessarily just an RtAudio problem.

Another reason for the clicks could be an interrupt conflict.
When I type:

cat /proc/interrupts   

I discover that my sound card is sharing an interrupt with the nvidia driver.
This probably explains why I get a click when I tab between windows while playing audio in non-super-user mode. A fix for this would be to use a real-time audio kernel.

Some useful links:

So I guess for now the solution for Linux is to stay with 3.0.3 (unless another version works), or perhaps look at some of the other real-time libraries, such as PortAudio (

perhaps a solution can be installing the linux-rt package in the install_codeblocks script? that installs the pre-emptive kernel that should solve this problems, indeed ubuntu studio, the ubuntu distribution for audio, has that kernel by default.

will do some tests


I tried to install the linux-rt package but got the following:

* nvidia (177.80)… nvidia (177.80): Installing module.
Kernel source for 2.6.27-3-rt not installed. Cannot install this module.

I didn’t like the look of this so I rolled back the install. Let me know if you have any luck.

OK , in order to install the linux-rt package and have my closed-source nvidia driver working I would have to do a manual reinstall of the driver against the real-time kernel headers used in linux-rt.

While this is certainly feasible and I will give it a try, it’s probably not a good idea to include this sort of thing in the install script as it could break most people’s video drivers if they don’t know what they are doing. Using a manual driver install also means you have you reinstall the driver every time the kernel upgrades.

hey pierre

i’ve installed linux-rt, linux-image-rt, linux-headers-rt and linux-restricted-rt and it works without problem.

also it should be there but, be sure that the dkms package is also installed, it’s a service responsible for compiling every needed module every time you install a new kernel.

anyway, you need to choose the right kernel on boot. perhaps is too much to include this in the install_codeblocks script but we can have a install_realtimekernel script.

Also what is the advantages of having rtaudio4 instead of 3?

I reinstalled linux-rt and it worked for me this time. I probably installed some extra packages that must have fixed the problem. However audio in the RT kernel doesn’t improve on my laptop. Even running Pure Data + Alsa with the realtime flag as root still gives me pops and clicks during the sine-wave test…as do the OF audioOutput examples. To be honest, I think Jack benefits most from a real-time kernel.

I actually don’t think there’s any real advantage of RtAudio 4.0+…perhaps some better error handling.

If I get some free time next year :slight_smile: I will write an OpenAL pluggable (+ possibly portaudio) back-end. The open source OpenAL guy has begun to write a small library called Alure which simplifies streaming and buffered playback, using libsndfile, mpg123 and vorbisfile libraries. I’ve tried it and it looks good. This way FMOD could become an addon and we could unify the audio sub-system.

for me the rt kernel solves the problem with the audio output example, but it’s very unstable. I have some crashes of the whole gnome session, also i’m testing with 64bits so perhaps is that.

Hey pierre

did you managed to run rtAudio with jack?

Have compiled rtAudio with jack support. When the app starts i can see the rtAudioApi in jackctl connected to the output, but doesn’t manage to get any sound, although other applications work ok…

I can’t remember but I think I didn’t try Jack, although I probably compiled it against jack. Generally if you see the audio connections in jackctl then everything is working Ok…
I can give it a shot when I get home tonight