Vaughan Johnson | 18 Apr 04:23 2014

WDM-KS and WASAPI issues (was Re: [Audacity-quality] Windows alpha builds)

Hi, sorry I've been off-list on this audacity-quality thread.

Am cc-ing this to the PortAudio list, in hopes it's helpful. There are 
mixed posting styles here. The first is at the bottom.

I encourage Audacity Team folks to subscribe to the PortAudio list.

On 4/10/2014 5:41 PM, Steve the Fiddle wrote:
> On 10 April 2014 22:01, Gale Andrews <gale <at>> wrote:
>> On 9 April 2014 22:58, Vaughan Johnson <vaughan <at>> wrote:
>>> The thread is here:
>>> I think the summary is that we want to continue to find out what's
>>> broken, via alpha-testing, but that it's not ready for release.
>> Thanks, yes.
>> The reports I've had for WDM-KS or WASAPI non-loopback have been
>> mostly positive (latency was reduced or 24-bit or multi-channel
>> recording was enabled), but pointed out problems (mostly ones we
>> already know about, but no new BSoD reports).
>> It's good that Steve has a machine that WDM-KS will break. I'm not
>> getting a lot of interest from users that blue screened with WDM-KS in
>> 2.0.4 to test Leland's patch to log PortAudio interactions "extremely
>> slowly". The one user who tried it did not get the log saved.  <at> Steve -
>> is your machine crashing or just Audacity? Do you want to try Leland's
>> log patch?
> It's a full BSOD.
(Continue reading)

Benjamin Gorman | 15 Apr 17:17 2014

Play sine wave only on either left or right channel.


In order to only play a sine wave on either the left or right channel of a 2 channel device. 

But I can't work out exactly how to skip or blank out one of the channels, skipping over the data or filling it with 0's doesn't seem to work. Is port-audio able to play a sound to a 2 channel device, but only play it on one channel? And if so how can I accomplish this?

I can't seem to find an example which does this. I'm on OSx if that changes anything.



Portaudio mailing list
Portaudio <at>
Stefan Hajnoczi | 14 Apr 21:31 2014

Assert FALSE at pa_win_wdmks.c:1036 FindStartConnectionFrom()

A user is reporting an assertion failure at
src/hostapi/wdmks/pa_win_wdmks.c:1036 using pa_stable_v19_20140130 (my
application is linked against it).  See the bottom of this email for
the PortAudio code in question.

I guess this is a rare issue with their particular sound device and/or
WDM Kernel Streaming driver for the device.  I have never seen this
assertion failure before.

Please let me know if there is any information you need, I can ask the
user to provide it.

Any suggestions about what causes this, how to work around it, or how to fix it?


static const KSTOPOLOGY_CONNECTION* FindStartConnectionFrom(ULONG
startPin, PaWinWdmFilter* filter)
    unsigned i;
    const KSTOPOLOGY_CONNECTION* connections = (const
KSTOPOLOGY_CONNECTION*)(filter->connections + 1);
    PA_DEBUG(("FindStartConnectionFrom: Checking %u connections...",
    for (i = 0; i < filter->connections->Count; ++i)
        const KSTOPOLOGY_CONNECTION* pConn = connections + i;
        if (pConn->ToNode == KSFILTER_NODE && pConn->ToNodePin == startPin)
            return pConn;

    assert(FALSE); <-- this line is being hit
David Donovan | 14 Apr 07:23 2014

Duplex callback examples?

Hi All,

Does anyone have an example on how to do full duplex in a stream callback?

I'm having troubles wrapping my brain around how to deal with play on demand in a callback.

Essentially, my application is always recording data, but wants to play every now and again "on demand" when there is data. 

 Previously I was opening up two half-duplex streams, leaving the record stream open and then opening/closing the play stream as needed.  Unfortunately for other reasons I switched to ASIO which will only let me have one stream, hence full duplex is needed.

(Or is it?  can I use WriteStream() in combination with having a call back that only deals with the input?)

Any suggestions?


Best Regards,
David Donovan

Portaudio mailing list
Portaudio <at>
David Donovan | 13 Apr 11:43 2014

Linking Against PortAudio with ASIO vs non-ASIO On Windows

Hi All,

Recently because of the discussion with AGC on the default windows API, I've decided to recompile portaudio with ASIO support.

I'm noticing though that now there is no .dll.a being generated, and I'm not sure how to link against it now.   I'm thinking this is because ASIO has C++ code in it..

If I have a simple c program that uses portaudio, are there suggestions of what command line I need to link against it?  I'm using mingw, and previously -L/path/to/portaudio -llibportaudio worked, but now with ASIO support I'm getting a bunch of link errors.

Best Regards,
David Donovan

Portaudio mailing list
Portaudio <at>
klackalica | 12 Apr 18:19 2014

portaudio with ASIO support

I 've done the installation again. All I have changed is portaudio release version. And I've built and run pa_devs.c, and there was ASIO. But, there are no other drivers in the list; now I have inverse situation - ASIO is there, but all drivers from the former list are missing. If this continues to be the problem, I will post the complete installation output, I have saved it in a txt file. By now, I just want to inform you that ASIO finally has appeared in the list.

Portaudio mailing list
Portaudio <at>
Ross Bencina | 11 Apr 08:12 2014

Windows Unicode patches applied -- test, review, and discussion re Unicode requested

Hi Everyone,

The WMME and DirectSound unicode patches by Tobias Erichsen have now 
been applied to trunk (with minor cleanup).

This fixes a bug where PortAudio device name strings were not correctly 
encoded to UTF8.

I would appreciate it if people (especially people who this was 
affecting) could test the latest trunk. Either from SVN, or get 
tomorrow's nightly tarball.

I would also appreciate it if someone could take a look over the 
relevant commits:



Now for the discussion:

The applied patches use the ANSI code page when the "_UNICODE" symbol is 
not defined. The WMME patch just copies windows strings directly with 
strcpy(), and the DirectSound patch converts the string from unicode to 
the ANSI code page. This doesn't seem right.

My understanding is that we have specified the PortAudio string encoding 
to *always* use UTF8. That means that if PA gets an ANSI code page 
string from a non-unicode Windows API, it should convert it to UTF8.

If that is the case I need to make another patch that converts Windows 
8-bit strings from the ANSI code page to UTF8.

Does that seem right?

There is a public ticket here where anyone can comment:


klackalica | 10 Apr 14:37 2014

portaudio with ASIO support

Now, can you tell me about this: 

- There is a shim called IAsioThiscallresolver that needs to be compiled-in for ASIO to work correctly with gcc. It should be           being included and compiled in.

What exactly should I do ?

Portaudio mailing list
Portaudio <at>
klackalica | 9 Apr 16:50 2014

best drivers

One more question: Is there any other driver near ASIO (in terms of latency), that I can install and use, to achieve real-time performance with unnoticeable latency?

Portaudio mailing list
Portaudio <at>
klackalica | 9 Apr 16:16 2014

portaudio and ASIO support

ASIO doesn't seem to appear in Audacity's device info, what that means?

Portaudio mailing list
Portaudio <at>
klackalica | 8 Apr 23:44 2014

Interesting thread

Here is SO user with portaudio/ASIO behaviour similar to mine:

So if you read the solution of his problem (accepted answer), can you tell me is there something similar that  I can add in pa_devs.c  to make ASIO appear in the list?

Portaudio mailing list
Portaudio <at>