Brian Vassallo | 22 Nov 14:31 2014


Dear Sir's,

I have downloaded AUDACITY 2.0.6 and i noticed a note 'Portaudio V-19 devel' ( Built sept.20. 2014 21:45:33)
in the devices menu section.

Would appreciate if you can help me understand since i am new to this,
therefore, if this will change or effect in any way my settings in ASIO,and in latency, that i have in my CUBASE recording software and in my USB audio devide - 'UR22'.

What i wish is to use AUDACITY with Portaudio V-19 devel, which is included,
but without modifying or having modified my original settings in CUBASE & UR22 ASIO , especially in latency.

Perhaps i am confusing the two scenarios, but just want to be sure that my original settings of Cubase & UR22, remained the same and latency settings wise.

Much appreciated
Portaudio mailing list
Portaudio <at>
Dinesh Iyer | 11 Nov 20:17 2014

Audio playback stalls when playing back audio on Mac OS X

Hi all,
I am designing an application which allows users to playback multiple audio signals at different sample-rates to the same audio device. I implement this by opening a new stream to playback each signal. I let CoreAudio perform the mixing. The playback does not start simultaneously i.e the user can playback one signal, then after an arbitrary amount of time playback the next one even when the first signal is playing.

The stall occurs about 30% of the time. 

I am able to consistently reproduce a stall when I am playing back two signals at 8192 hertz and attempt to open a stream at 44100 hz. The stall occurs at __psync_mutexwait in the call to Pa_OpenStream(). 

I am not receiving this stall when I match the sample rates of all my streams.

I cam across this article in Apple's knowledge base about AUGRAPH stalls:

I am not sure if it is relevant.

I am able to reproduce this using both the March 2011 and Jan 2014 versions of the library.


Portaudio mailing list
Portaudio <at>
Stefan Hajnoczi | 11 Nov 10:39 2014

Persistent device identifiers

Applications need to save sound settings across restart so the user
does not have to select their settings each time.

My application saves the host API and device names as strings.  The
reason for saving strings instead of PortAudio's index numbers is that
adding or removing sound devices could change the index numbers.  For
example, if a USB webcam is connected that might expose an sound
capture device and affect index numbering.

Here are two issues I've encountered with strings:

1. Character set encoding is (was?) not consistent.  PortAudio strings
are supposed to be UTF-8 but not all host APIs have implemented that
correctly.  I'm not sure what the current status is, but users with
non-English Windows installations have reported problems with
PortAudio built February 27th 2014 using WinMME and DirectSound.

2. Some systems have multiple sound devices with the same name.  This
makes it impossible to uniquely identify a device from its name!  A
Windows user recently reported this problem but was able to manually
rename the sound device.  I'm not sure whether the Windows sound
settings control panel has a way of doing that or if they used a
registry hack.

Any thoughts on these issues?

Is there a more reliable method than name strings for persistent
device identifiers?

Wang, Lin | 4 Nov 16:25 2014

Quesiton about Pa_IsFormatSupported on alsa API (ubuntu)



I am using the PortAudio to query the list of capture devices and also use Pa_IsFormatSupported to probe if the actual device is compliant with the requested audio format. I realized that the Pa_IsFormatSupported’s alsa implementation tends to open the actual PCM stream under the hood to physically test the device. It seems to take a while for a device to be ready again.


In the extreme case, calling Pa_IsFormatSupported on a device back-to-back, the 2nd call will end up getting the paDeviceUnavailable error in most cases. BTW, the recording device I am using is a Bluetooth remote control, based on your experience, the latency could be caused by the PA/alsa implementation or by the physical device?




Portaudio mailing list
Portaudio <at>
Dumitru Potop-Butucaru | 4 Nov 09:48 2014

Huge input latency on MacOS


I'm starting to use PortAudio on MacOSX (10.8.5).

I compiled the last stable version (taken from

I managed to build a simple pitch shifting application, 

using the approach from the example


However, I have a big problem: The output lags behind the

input by about half a second, which is huge. I traced the

execution and discovered that this is due to a 600 milliseconds

latency in acquiring the first samples. More precisely,

executing the first call to Pa_ReadStream takes more than

600 ms. Then, everything becomes "normal" and the duration

of the read-compute-write cycles is of about 90ms (normal,

given the read buffer size).

What is funny is that the 600ms latency was quite stable until

I started inserting delays of my own in the code (by means of

usleep). Then, it ranges randomly between 100ms to 700ms...

Any idea on what this is due to ?

BTW: The API reported by Pa_GetDeviceInfo for both the

input and output devices is paInDevelopment, not paCoreAudio.




Portaudio mailing list
Portaudio <at>
KNS | 28 Oct 15:20 2014

Setting default driver

I've just compiled a couple versions of portaudio, on Windows using MinGW.  The first was with just ASIO and the second ASIO and DirectX.  When compiling the included examples the former behaves as expected.  Specifically, the asio4all control window appears.  For the second, and this is the really naive part, how do I let the application know to use ASIO first, then default to DirectX?  

Incidentally, by default I should I expect substantially better input and output latency with asio4all relative to directx.  I do have an M-Audio Transit but for the sake of convenience I would like to trade on that latency.  I would be comfortable with on the order of 20 or so milliseconds.

Portaudio mailing list
Portaudio <at>
Evan Balster | 25 Oct 11:12 2014

Advice: inter-device synchronization / streaming

Hey, all --

For various reasons I'm approaching a situation where a general-purpose mechanism for monitoring activity in one audio callback from another will be useful -- for instance, monitoring input from one device and playing it back in another when no duplexing is available.

The basic methodology is simple enough:  use lockfree mechanisms like ringbuffers to copy samples in the producer process and render them in the consumer one.  I'm aware of several complications that rear their heads in these situations -- primarily clock source discrepancy, which I've seen leads to some very nasty behaviors in some software.

For my purposes, a little latency and even occasional samples dropped / duplicated are acceptable -- but I'm interested in how to solve this problem well, achieving a respectable latency with minimal distortion of the signal, and haven't been able to find good documentation on it.  Hoping some of the seasoned minds here might be able to shed some light.

Thanks in advance for any advice!

Portaudio mailing list
Portaudio <at>
Garth Hjelte | 24 Oct 00:47 2014

Handling multiple in/out audio devices

How does PortAudio support audio products that have multiple inputs and multiple outputs?

Typically, does it get each stereo pair as a single PaDeviceInfo; in other words, the single hardware
device acts like 4 separate stereo devices? (Then using the separate outputs is easy; just choose the
[Audio Device]-Channel 1+2 PaDeviceInfo.)

But do some multiple in/out devices just show as one PaDeviceInfo and there's another way to declare which
inputs get recorded from /or/ which outputs are listened to? If so, how does PortAudio handle that? Does it
just not support it?

Garth Hjelte
Sampler User
Éloi Rivard | 19 Oct 23:24 2014

"underrun occured" issue


I am a developper of GNU denemo ( ) and I met some troubles with Portmidi. In short, denemo produces a constant error message flow:

ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

I don't know the cause of this but I can only fix this with the environment var "PULSE_LATENCY_MSEC=30"

I though maybe it is due to a bad portaudio initialization from denemo ? Looking at this source code, do you see something wrong/chocking ?

You can also have a look at our bug report:

Thanks for your help
Portaudio mailing list
Portaudio <at>
Pradeep Kumar | 10 Oct 00:26 2014

Periodic noise in playback


I'm using portaudio in my application both for audio and video playback.
For long time it was working fine. But recently I'm facing a strange issue.
I'm hearing some periodic low click noise during playback which was not there earlier. However when I pause my playback and again resume the noise disappear for sometime (5-7 seconds) but comes back again. And this is consistence whenever I pause or start my playback. So the noise is coming after duration of playback.
I know something has changed which is causing this issue but I'm not able to figure it out. I tried many change like changing the buffer size,flags Pa_OpenStream and many other changes but the noise is still there.

Please suggest what could be doing wrong.

Thanks and Regards,
Portaudio mailing list
Portaudio <at>
John Clements | 1 Oct 00:37 2014

brute-force approach to paTerminate?

I have a set of bindings for portaudio for Racket, an environment where it’s inconvenient[*] to pass
state between threads in order to properly ensure that paInitialize happens once at the beginning of
execution, and paTerminate is called at the end of execution. Indeed, if multiple user programs are
running simultaneously, it’s not even clear definition is the best one to use for the “end of execution”.

In light of this, I came up with this gross hack:

;; initialize unless it's already been initialized.
(define (pa-maybe-initialize)
  (cond [(pa-initialized?) (void)]
        [else (pa-initialize)]))

;; has portaudio been initialized?
(define (pa-initialized?)
  (not (= (pa-get-host-api-count/raw) pa-not-initialized-error)))

;; terminate until pa-initialized returns false
(define (pa-terminate-completely)
  (let loop ([count terminate-absurd-threshold])
    (cond ([< count 0] (error 'pa-terminate-completely 
                              "terminated more than ~s times and initialized? still returns true."
          [(pa-initialized?) (pa-terminate)
                             (loop (- count 1))]
          [else #t])))

;; the number of times to try terminating before giving up:
(define terminate-absurd-threshold 1000000)

That is: call pa-maybe-initialize at the beginning of each user thread that uses portaudio, and attach
pa-terminate-completely to the end of a user thread.

Can anyone comment on the possible race conditions inherent in this approach? Yes, it makes you hold your
nose, but will it lead to core dumps?

Many thanks!

John Clements

[*] I should add that a new feature called ‘plumbers’ may help with this; before I invest time in
rewriting code (and potentially introducing more bugs), I want to evaluate the stability of the solution
that I currently have.