From dstuart at counterpath.com Thu Apr 1 10:31:54 2010 From: dstuart at counterpath.com (David Stuart) Date: Thu, 01 Apr 2010 10:31:54 -0400 Subject: [Portaudio] DirectSound backend question In-Reply-To: <4BB0ACC9.8080808@counterpath.com> References: <4BACCDC2.1000907@counterpath.com> <00e001cacd9c$39da98e0$0f73a8c0@rossmacbook> <4BB0ACC9.8080808@counterpath.com> Message-ID: <4BB4AE5A.4030300@counterpath.com> David Stuart wrote: > Ross Bencina wrote: >> values and see what happens (DSSCL_NORMAL or DSSCL_PRIORITY). Let us know if >> that makes a difference. If so we can expose this as some kind of >> DS-specific user setting. >> >> What OS/DirectX version is your co-worker running? >> > > Well he is actually using Win7-64bit. However, I have reproduced the > same problem on WinXP-32bit. > > I'm not yet 100% convinced this is the issue, but I'll let you know if > it makes any difference. Hi .. As it turns out, DSSCL_EXCLUSIVE does not seem to be the problem. I have a feeling the term "exclusive" in this context does not really mean the same thing as it does with, say, WASAPI. -- David Stuart, CounterPath Email: dstuart (at) counterpath (dot) com Phone: (613) 254-8886 x2234 Web: http://www.counterpath.com/ Address: 310 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/portaudio/attachments/20100401/d13410af/attachment.html From shawno at lavabit.com Thu Apr 1 11:51:55 2010 From: shawno at lavabit.com (Shawn O'Rourke) Date: Thu, 01 Apr 2010 08:51:55 -0700 Subject: [Portaudio] Link errors while building patest_sine.c Message-ID: <4BB4C11B.1080200@lavabit.com> I downloaded a recent snapshot of PortAudio 19, and built it with Cygwin on Windows XP. Then I tried to build the patest_sine.c example, and I got the following link errors: g++ -c -I/usr/local/include patest_sine.c g++ -o patest_sine -L/usr/local/lib -lportaudio patest_sine.o patest_sine.o:patest_sine.c:(.text+0x192): undefined reference to `_Pa_Initialize' patest_sine.o:patest_sine.c:(.text+0x1a4): undefined reference to `_Pa_GetDefaultOutputDevice' . There were also several other undefined references. I'm linking with libportaudio.a, so I'm guessing that I must be missing something else in my make file. When I built the library, everything under the test directory built successfully, including patest_sine.c. So I must have whatever I need to build it - I just can't figure out what's missing. If someone can help, I would appreciated it. Thanks, Shawn From wingfeathera at gmail.com Sat Apr 3 22:25:51 2010 From: wingfeathera at gmail.com (Matthew Robbetts) Date: Sun, 04 Apr 2010 03:25:51 +0100 Subject: [Portaudio] portaudio, LynxTWO-B and Linux/OSS Message-ID: <4BB7F8AF.20701@gmail.com> Hi all, I'm writing an application to use Portaudio with a Lynx TWO-B sound card. The only driver for this card under Linux is OSS. Now, I used this card with Portaudio under Windows back in the day, with ASIO, and had no problems. I'm looking to port that application to Linux. Now, the problem: under Linux/OSS, this multichannel card is presented as separate stereo inputs and stereo outputs. The internal hardware mixer of the card can deal with 16 channels each of input and output, so OSS presents it as 16 stereo pairs. My application (a loudspeaker crossover processor) requires streaming from 2 inputs to 8 outputs. Can you comment on the best way to achieve this with callback I/O in portaudio, given the behaviour of the driver? IIRC the windows driver for this card behaves similarly, but additionally presents a big multichannel ASIO device, so I just used that in the old version. I presume that blocking I/O might be applicable for this problem (I've not used that before), but the callback method seems much neater and more extensible, if I can somehow control this I/O with a single PA stream. However, at the moment it looks like all I can do is open 5 separate stereo streams and have separate callbacks for each, which I think would then need centralised buffering and manual synchronisation between all the callbacks - not so neat anymore. Any ideas? I imagine I've missed something silly. Thanks, Matthew Robbetts From alberts at mixxx.org Mon Apr 5 16:43:10 2010 From: alberts at mixxx.org (Albert Santoni) Date: Mon, 5 Apr 2010 13:43:10 -0700 Subject: [Portaudio] portaudio, LynxTWO-B and Linux/OSS In-Reply-To: <4BB7F8AF.20701@gmail.com> References: <4BB7F8AF.20701@gmail.com> Message-ID: Hi Matthew, On Sat, Apr 3, 2010 at 7:25 PM, Matthew Robbetts wrote: > Hi all, > > I'm writing an application to use Portaudio with a Lynx TWO-B sound > card. The only driver for this card under Linux is OSS. Now, I used this > card with Portaudio under Windows back in the day, with ASIO, and had no > problems. I'm looking to port that application to Linux. > > Now, the problem: under Linux/OSS, this multichannel card is presented > as separate stereo inputs and stereo outputs. The internal hardware > mixer of the card can deal with 16 channels each of input and output, so > OSS presents it as 16 stereo pairs. My application (a loudspeaker > crossover processor) requires streaming from 2 inputs to 8 outputs. Can > you comment on the best way to achieve this with callback I/O in > portaudio, given the behaviour of the driver? IIRC the windows driver > for this card behaves similarly, but additionally presents a big > multichannel ASIO device, so I just used that in the old version. > > I presume that blocking I/O might be applicable for this problem (I've > not used that before), but the callback method seems much neater and > more extensible, if I can somehow control this I/O with a single PA > stream. However, at the moment it looks like all I can do is open 5 > separate stereo streams and have separate callbacks for each, which I > think would then need centralised buffering and manual synchronisation > between all the callbacks - not so neat anymore. Any ideas? I imagine > I've missed something silly. The recommended way to approach this would be to open a single stream, which have your 5 stereo channel pairs interleaved, along with the two input channels. When you're setting up your stream parameters, you can specify how many output and input channels you want opened, so you shouldn't have any problems there. You'll only have one callback method too... I've written code using PortAudio that handles all of this, and it might be useful as an example for you: http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/trunk/annotate/head:/mixxx/src/sounddeviceportaudio.cpp Check out the SoundDevicePortAudio::open() function there, especially lines 164-185 to see how I set up the stream parameters. Good luck, and hope this helps, Albert From wingfeathera at gmail.com Tue Apr 6 06:57:23 2010 From: wingfeathera at gmail.com (Matthew Robbetts) Date: Tue, 6 Apr 2010 11:57:23 +0100 Subject: [Portaudio] portaudio, LynxTWO-B and Linux/OSS In-Reply-To: References: <4BB7F8AF.20701@gmail.com> Message-ID: Hi Albert, Thanks for your reply (and the link). I love neat code! Now, there's a very good chance that I am being obtuse, so please bear with me. However, I don't understand your answer. I know that you can specify the desired number of channels when opening a stream by setting PaStreamParameters.channelCount to the number of channels you need. Pa_OpenStream() accepts a PaStreamParameters struct to detail the stream inputs, and another one to detail the stream outputs. So, when using Portaudio under Windows/ASIO, it was possible just specify 2 in this field of the `input' struct, 8 in this field of the `output' struct, and open the one stream with a single call to Pa_OpenStream(). However, with Linux/OSS, my one multichannel sound card appears as 16 separate (stereo) devices to Portaudio. Trying to open more than 2 channels onto one of these devices doesn't work. If I understand it correctly, your code receives in a single PaDeviceInfo, which in my case would describe a single stereo device, so I can't see how this problem is avoided. Have I got it wrong? Thanks a lot, Matt On 5 April 2010 21:43, Albert Santoni wrote: > Hi Matthew, > > On Sat, Apr 3, 2010 at 7:25 PM, Matthew Robbetts wrote: >> Hi all, >> >> I'm writing an application to use Portaudio with a Lynx TWO-B sound >> card. The only driver for this card under Linux is OSS. Now, I used this >> card with Portaudio under Windows back in the day, with ASIO, and had no >> problems. I'm looking to port that application to Linux. >> >> Now, the problem: under Linux/OSS, this multichannel card is presented >> as separate stereo inputs and stereo outputs. The internal hardware >> mixer of the card can deal with 16 channels each of input and output, so >> OSS presents it as 16 stereo pairs. My application (a loudspeaker >> crossover processor) requires streaming from 2 inputs to 8 outputs. Can >> you comment on the best way to achieve this with callback I/O in >> portaudio, given the behaviour of the driver? IIRC the windows driver >> for this card behaves similarly, but additionally presents a big >> multichannel ASIO device, so I just used that in the old version. >> >> I presume that blocking I/O might be applicable for this problem (I've >> not used that before), but the callback method seems much neater and >> more extensible, if I can somehow control this I/O with a single PA >> stream. However, at the moment it looks like all I can do is open 5 >> separate stereo streams and have separate callbacks for each, which I >> think would then need centralised buffering and manual synchronisation >> between all the callbacks - not so neat anymore. Any ideas? I imagine >> I've missed something silly. > > The recommended way to approach this would be to open a single stream, > which have your 5 stereo channel pairs interleaved, along with the two > input channels. When you're setting up your stream parameters, you can > specify how many output and input channels you want opened, so you > shouldn't have any problems there. You'll only have one callback > method too... > > I've written code using PortAudio that handles all of this, and it > might be useful as an example for you: > http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/trunk/annotate/head:/mixxx/src/sounddeviceportaudio.cpp > Check out the SoundDevicePortAudio::open() function there, especially > lines 164-185 to see how I set up the stream parameters. > > Good luck, and hope this helps, > Albert > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > From Frank at Lichtner.de Tue Apr 6 10:13:45 2010 From: Frank at Lichtner.de (Frank Lichtner) Date: Tue, 06 Apr 2010 16:13:45 +0200 Subject: [Portaudio] ASIO MinGW4.xxx Message-ID: <4BBB4199.1070801@Lichtner.de> Hi to all, I just joined the list so I don't know if this problem has been discussed before. Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio (latest from SVN, using MSYS to compile the provided makefile) ASIO is not working anymore. Pa_IsFormatSupported gives me always a paInvalidSampleRate error. Any suggestions? Frank From rossb-lists at audiomulch.com Wed Apr 7 00:47:53 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 7 Apr 2010 14:47:53 +1000 Subject: [Portaudio] ASIO MinGW4.xxx References: <4BBB4199.1070801@Lichtner.de> Message-ID: <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> Hi Frank I guess it's this problem: http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html I'm not sure if Gary has resolved this in the mean time. As far as I know no one has posted a fix. Because ASIO uses the "thiscall" calling convention which is only supported by Microsoft compilers we use some assembley glue to invoke ASIO drivers when compiling with GCC. Apparrently the glue is not working for ASIOCanSampleRate() and ASIOSetSampleRate() The glue is in IASIOThiscallResolver.cpp which contains extensive comments and explanation. If I had gcc 3.x and 4.4 installed I'd dump the ASM for IASIOThiscallResolver::canSampleRate and IASIOThiscallResolver::setSampleRate calls in both compiler versions and see what's changed. Then work out how to fix CALL_THISCALL_1_DOUBLE to generate the same code in both compilers. Ross. =================================== Perform, Compose, Mangle AudioMulch 2.0 modular audio software for PC and Mac http://www.audiomulch.com ----- Original Message ----- From: "Frank Lichtner" To: "PortAudio" Sent: Wednesday, April 07, 2010 12:13 AM Subject: [Portaudio] ASIO MinGW4.xxx > Hi to all, > > I just joined the list so I don't know if this problem has been > discussed before. > > Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio (latest > from SVN, using MSYS to compile the provided makefile) ASIO is not > working anymore. Pa_IsFormatSupported gives me always a > paInvalidSampleRate error. > > Any suggestions? > > Frank > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio From gary.scavone at mcgill.ca Wed Apr 7 09:58:34 2010 From: gary.scavone at mcgill.ca (Gary Scavone) Date: Wed, 7 Apr 2010 09:58:34 -0400 Subject: [Portaudio] ASIO MinGW4.xxx In-Reply-To: <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> Message-ID: <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca> Nope ... I never had time to investigate further. --gary On 2010-04-07, at 12:47 AM, Ross Bencina wrote: > Hi Frank > > I guess it's this problem: > http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html > > I'm not sure if Gary has resolved this in the mean time. > > As far as I know no one has posted a fix. > > Because ASIO uses the "thiscall" calling convention which is only supported by Microsoft compilers we use some assembley glue to invoke ASIO drivers when compiling with GCC. Apparrently the glue is not working for ASIOCanSampleRate() and ASIOSetSampleRate() > > The glue is in IASIOThiscallResolver.cpp which contains extensive comments and explanation. > > If I had gcc 3.x and 4.4 installed I'd dump the ASM for IASIOThiscallResolver::canSampleRate and IASIOThiscallResolver::setSampleRate calls in both compiler versions and see what's changed. Then work out how to fix CALL_THISCALL_1_DOUBLE to generate the same code in both compilers. > > Ross. > > > > > > =================================== > Perform, Compose, Mangle > AudioMulch 2.0 modular audio software for PC and Mac > http://www.audiomulch.com > ----- Original Message ----- From: "Frank Lichtner" > To: "PortAudio" > Sent: Wednesday, April 07, 2010 12:13 AM > Subject: [Portaudio] ASIO MinGW4.xxx > > >> Hi to all, >> >> I just joined the list so I don't know if this problem has been >> discussed before. >> >> Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio (latest >> from SVN, using MSYS to compile the provided makefile) ASIO is not >> working anymore. Pa_IsFormatSupported gives me always a >> paInvalidSampleRate error. >> >> Any suggestions? >> >> Frank >> >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > From tjfoerster at web.de Wed Apr 7 10:35:29 2010 From: tjfoerster at web.de (TJF) Date: Wed, 07 Apr 2010 16:35:29 +0200 Subject: [Portaudio] Read entire file to memory Message-ID: <4BBC9831.6020700@web.de> Hi, would be nice, if anyone would have an idea for my problem - even when it is on RtAudio. The problem would be very similar in Portaudio. I want to read an entire raw-file to memory. But I cannot find a working output function to play the allocated buffer... Thanks a lot. Regards Thomas That's what I have (s.b. the normal working code): typedef signed short MY_TYPE; #define FORMAT RTAUDIO_SINT16 // 16 bit #define SCALE 32767.0 // OutputData struct: struct OutputData { FILE *fd; unsigned int channels; unsigned int size; size_t length; void *buffer; unsigned int position; }; //Callback: int output( void *outputBuffer, void *inputBuffer, unsigned int nBufferFrames, double streamTime, RtAudioStreamStatus status, void *data ) { unsigned int i; OutputData *oData = (OutputData*) data; MY_TYPE *out = (MY_TYPE *)outputBuffer; MY_TYPE *buf = &((MY_TYPE *)oData->buffer)[oData->position]; for (i=0; i < nBufferFrames; i++) { if (oData->position < oData->length) { *out++ = *buf++; ++oData->position; } else *out++ = 0; } return (oData->position >= oData->length); } // data struct... OutputData data; data.fd = fopen ( file , "rb" ); std::cout << "\ndata.fd " << data.fd << std::endl; if (data.fd == NULL) { std::cout << "Unable to find or open file!\n"; exit (1); } fseek (data.fd , 0 , SEEK_END); data.size = ftell (data.fd); std::cout << "\ndata.size: " << data.size << std::endl; data.buffer = calloc (data.size,1); if (data.buffer == NULL) { std::cout << "Memory error!\n"; exit (2); } fseek (data.fd , 0 , SEEK_SET); data.length = fread (data.buffer,1,data.size,data.fd); // :2 (channels) , :2(bytes/Sample), :2 (1 Frame= 2 Samples) //data.length = data.length/8; /* if (data.length != data.size) { std::cout << "Reading error!\n"; exit (3); } */ // This is the "normal" working code: ------------------------------------------------ // OutputData struct: struct OutputData { FILE *fd; unsigned int channels; }; //... callback: int output( void *outputBuffer, void *inputBuffer, unsigned int nBufferFrames, double streamTime, RtAudioStreamStatus status, void *data ) { unsigned int data.count = fread( outputBuffer, oData->channels * sizeof( MY_TYPE ), nBufferFrames, oData->fd); if ( count < nBufferFrames ) { unsigned int bytes = (nBufferFrames - data.count) * oData->channels * sizeof( MY_TYPE ); unsigned int startByte = data.count * oData->channels * sizeof( MY_TYPE ); memset( (char *)(outputBuffer)+startByte, 0, bytes ); return 1; } return 0; } // data struct... OutputData data; data.fd = fopen ( file , "rb" ); From dmitrykos at inbox.lv Wed Apr 7 13:59:12 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Wed, 07 Apr 2010 20:59:12 +0300 Subject: [Portaudio] ASIO MinGW4.xxx In-Reply-To: <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca> Message-ID: <1270663152.4bbcc7f08334b@mail.inbox.lv> Hi Guys! Well, I can confirm that MinGW (GCC 4.4.0, 32-bit) is working ok with ASIO. GCC ABI will not change for WIN32 model thus if ASM thiscall resolver was working with 3.x then it will be working with any other WIN32 compatible version of GCC. asiothiscallresolver.cpp is included in configure.in and was compiled I guess. To debug the problem you could install ASIO4ALL driver and try PA through it, if it works (in case you are sure that parameters you pass to Pa_IsFormatSupported are 100% correct) then it is a problem of your ASIO drivers may be. Dmitry. Quoting *Gary Scavone *: > Nope ... I never had time to investigate further. > > --gary > > On 2010-04-07, at 12:47 AM, Ross Bencina wrote: >> Hi Frank >> >> I guess it's this problem: >> http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html >> >> I'm not sure if Gary has resolved this in the mean time. >> >> As far as I know no one has posted a fix. >> >> Because ASIO uses the "thiscall" calling convention which is only >> supported by Microsoft compilers we use some assembley glue to >> invoke ASIO drivers when compiling with GCC. Apparrently the glue >> is not working for ASIOCanSampleRate() and ASIOSetSampleRate() >> >> The glue is in IASIOThiscallResolver.cpp which contains extensive >> comments and explanation. >> >> If I had gcc 3.x and 4.4 installed I'd dump the ASM for >> IASIOThiscallResolver::canSampleRate and >> IASIOThiscallResolver::setSampleRate calls in both compiler >> versions and see what's changed. Then work out how to fix >> CALL_THISCALL_1_DOUBLE to generate the same code in both compilers. >> >> Ross. >> >> >> >> >> >> =================================== >> Perform, Compose, Mangle >> AudioMulch 2.0 modular audio software for PC and Mac >> http://www.audiomulch.com >> ----- Original Message ----- From: "Frank Lichtner" >> To: "PortAudio" >> Sent: Wednesday, April 07, 2010 12:13 AM >> Subject: [Portaudio] ASIO MinGW4.xxx >>> Hi to all, >>> >>> I just joined the list so I don't know if this problem has been >>> discussed before. >>> >>> Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio >>> (latest >>> from SVN, using MSYS to compile the provided makefile) ASIO is not >>> working anymore. Pa_IsFormatSupported gives me always a >>> paInvalidSampleRate error. >>> >>> Any suggestions? >>> >>> Frank >>> >>> _______________________________________________ >>> Portaudio mailing list >>> Portaudio at music.columbia.edu >>> http://music.columbia.edu/mailman/listinfo/portaudio >> >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank at Lichtner.de Wed Apr 7 15:47:03 2010 From: Frank at Lichtner.de (Frank Lichtner) Date: Wed, 07 Apr 2010 21:47:03 +0200 Subject: [Portaudio] ASIO MinGW4.xxx In-Reply-To: <1270663152.4bbcc7f08334b@mail.inbox.lv> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca> <1270663152.4bbcc7f08334b@mail.inbox.lv> Message-ID: <4BBCE137.1070607@Lichtner.de> Hi Dmitry, I have 2 audio devices installed, a RME HDSP and a SoundblasterX-Fi. The problem is with both, so I don't think this is a driver problem. And the same divers worked fine when portaudio was compiled wit 3.4.5. Also the problem is only with ASIOCanSampleRate() and ASIOSetSampleRate(), other functions work. I guess Ross is right that there is an assembler problem in CALL_THISCALL_1_DOUBLE, but I don't know assembler so it's hard for me to figure out what's wrong. I've tried it now TDM 4.4.1 but without success. :-( Frank Am 07.04.2010 19:59, schrieb Dmitry Kostjuchenko: > Hi Guys! > > Well, I can confirm that MinGW (GCC 4.4.0, 32-bit) is working ok with > ASIO. GCC ABI will not change for WIN32 model thus if ASM thiscall > resolver was working with 3.x then it will be working with any other > WIN32 compatible version of GCC. asiothiscallresolver.cpp is included > in configure.in and was compiled I guess. > > To debug the problem you could install ASIO4ALL driver and try PA > through it, if it works (in case you are sure that parameters you pass > to Pa_IsFormatSupported are 100% correct) then it is a problem of your > ASIO drivers may be. > > Dmitry. > Quoting *Gary Scavone >*: > > Nope ... I never had time to investigate further. > > --gary > > On 2010-04-07, at 12:47 AM, Ross Bencina wrote: > > Hi Frank > > I guess it's this problem: > http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html > > I'm not sure if Gary has resolved this in the mean time. > > As far as I know no one has posted a fix. > > Because ASIO uses the "thiscall" calling convention which is > only supported by Microsoft compilers we use some assembley > glue to invoke ASIO drivers when compiling with GCC. > Apparrently the glue is not working for ASIOCanSampleRate() > and ASIOSetSampleRate() > > The glue is in IASIOThiscallResolver.cpp which contains > extensive comments and explanation. > > If I had gcc 3.x and 4.4 installed I'd dump the ASM for > IASIOThiscallResolver::canSampleRate and > IASIOThiscallResolver::setSampleRate calls in both compiler > versions and see what's changed. Then work out how to fix > CALL_THISCALL_1_DOUBLE to generate the same code in both > compilers. > > Ross. > > > > > > =================================== > Perform, Compose, Mangle > AudioMulch 2.0 modular audio software for PC and Mac > http://www.audiomulch.com > ----- Original Message ----- From: "Frank Lichtner" > To: "PortAudio" > Sent: Wednesday, April 07, 2010 12:13 AM > Subject: [Portaudio] ASIO MinGW4.xxx > > > Hi to all, > > I just joined the list so I don't know if this problem has > been > discussed before. > > Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build > portaudio (latest > from SVN, using MSYS to compile the provided makefile) > ASIO is not > working anymore. Pa_IsFormatSupported gives me always a > paInvalidSampleRate error. > > Any suggestions? > > Frank > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > > > > > iAuxSoft > ------------------ > [www.iauxsoft.com] > > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrykos at inbox.lv Wed Apr 7 17:30:36 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Thu, 08 Apr 2010 00:30:36 +0300 Subject: [Portaudio] ASIO MinGW4.xxx In-Reply-To: <4BBCE137.1070607@Lichtner.de> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca> <1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de> Message-ID: <1270675836.4bbcf97c2d198@mail.inbox.lv> Frank, What error id does ASIOCanSampleRate return? And what was the sample rate value provided for call? Dmitry. Quoting *Frank Lichtner *: > Hi Dmitry, > > I have 2 audio devices installed, a RME HDSP and a SoundblasterX-Fi. > The problem is with both, so I don't think this is a driver problem. > And the same divers worked fine when portaudio was compiled wit > 3.4.5. > Also the problem is only with ASIOCanSampleRate() and > ASIOSetSampleRate(), other functions work. > I guess Ross is right that there is an assembler problem in > CALL_THISCALL_1_DOUBLE, but I don't know assembler so it's hard for > me to figure out what's wrong. > > I've tried it now TDM 4.4.1 but without success. :-( > > Frank > > Am 07.04.2010 19:59, schrieb Dmitry Kostjuchenko: >> Hi Guys! >> >> Well, I can confirm that MinGW (GCC 4.4.0, 32-bit) is working ok >> with ASIO. GCC ABI will not change for WIN32 model thus if ASM >> thiscall resolver was working with 3.x then it will be working with >> any other WIN32 compatible version of GCC. asiothiscallresolver.cpp >> is included in configure.in and was compiled I guess. >> >> To debug the problem you could install ASIO4ALL driver and try >> PA through it, if it works (in case you are sure that parameters >> you pass to Pa_IsFormatSupported are 100% correct) then it is a >> problem of your ASIO drivers may be. >> >> Dmitry. >> Quoting *Gary Scavone *: >>> Nope ... I never had time to investigate further. >>> >>> --gary >>> >>> On 2010-04-07, at 12:47 AM, Ross Bencina wrote: >>>> Hi Frank >>>> >>>> I guess it's this problem: >>>> http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html >>>> [1] >>>> >>>> I'm not sure if Gary has resolved this in the mean time. >>>> >>>> As far as I know no one has posted a fix. >>>> >>>> Because ASIO uses the "thiscall" calling convention which is only >>>> supported by Microsoft compilers we use some assembley glue to >>>> invoke ASIO drivers when compiling with GCC. Apparrently the glue >>>> is not working for ASIOCanSampleRate() and ASIOSetSampleRate() >>>> >>>> The glue is in IASIOThiscallResolver.cpp which contains extensive >>>> comments and explanation. >>>> >>>> If I had gcc 3.x and 4.4 installed I'd dump the ASM for >>>> IASIOThiscallResolver::canSampleRate and >>>> IASIOThiscallResolver::setSampleRate calls in both compiler >>>> versions and see what's changed. Then work out how to fix >>>> CALL_THISCALL_1_DOUBLE to generate the same code in both >>>> compilers. >>>> >>>> Ross. >>>> >>>> >>>> >>>> >>>> >>>> =================================== >>>> Perform, Compose, Mangle >>>> AudioMulch 2.0 modular audio software for PC and Mac >>>> http://www.audiomulch.com [2] >>>> ----- Original Message ----- From: "Frank Lichtner" >>>> To: "PortAudio" >>>> Sent: Wednesday, April 07, 2010 12:13 AM >>>> Subject: [Portaudio] ASIO MinGW4.xxx >>>>> Hi to all, >>>>> >>>>> I just joined the list so I don't know if this problem has been >>>>> discussed before. >>>>> >>>>> Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio >>>>> (latest >>>>> from SVN, using MSYS to compile the provided makefile) ASIO is >>>>> not >>>>> working anymore. Pa_IsFormatSupported gives me always a >>>>> paInvalidSampleRate error. >>>>> >>>>> Any suggestions? >>>>> >>>>> Frank >>>>> >>>>> _______________________________________________ >>>>> Portaudio mailing list >>>>> Portaudio at music.columbia.edu >>>>> http://music.columbia.edu/mailman/listinfo/portaudio [3] >>>> >>>> _______________________________________________ >>>> Portaudio mailing list >>>> Portaudio at music.columbia.edu >>>> http://music.columbia.edu/mailman/listinfo/portaudio [4] >>> >>> _______________________________________________ >>> Portaudio mailing list >>> Portaudio at music.columbia.edu >>> http://music.columbia.edu/mailman/listinfo/portaudio [5] >> >> >> >> iAuxSoft >> ------------------ >> [www.iauxsoft.com [6]] >> >> >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio [7] > iAuxSoft ------------------ [www.iauxsoft.com] Links: ------ [1] http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html [2] http://www.audiomulch.com [3] http://music.columbia.edu/mailman/listinfo/portaudio [4] http://music.columbia.edu/mailman/listinfo/portaudio [5] http://music.columbia.edu/mailman/listinfo/portaudio [6] http://www.iauxsoft.com [7] http://music.columbia.edu/mailman/listinfo/portaudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Thu Apr 8 02:08:20 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu, 8 Apr 2010 16:08:20 +1000 Subject: [Portaudio] ASIO MinGW4.xxx References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca><1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de> Message-ID: <015c01cad6e1$e46aa360$0f73a8c0@rossmacbook> Frank wrote: >I guess Ross is right that there is an assembler problem in >CALL_THISCALL_1_DOUBLE, but I don't know assembler so it's hard for me to >figure out what's wrong. After a bit of googling I find that for gcc, the -save-temps flag will dump intermediate files (the assember file would be the one with the .s extension I think). If you do this with both gcc 3 and 4 and post the results I could have a look. You probably won't be able to send them to the list.. so if you can put them up on a server somewere or email them privately that would be great. Ross. From Frank at Lichtner.de Thu Apr 8 03:22:22 2010 From: Frank at Lichtner.de (Frank Lichtner) Date: Thu, 08 Apr 2010 09:22:22 +0200 Subject: [Portaudio] ASIO MinGW4.xxx In-Reply-To: <1270675836.4bbcf97c2d198@mail.inbox.lv> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca> <1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de> <1270675836.4bbcf97c2d198@mail.inbox.lv> Message-ID: <4BBD842E.10707@Lichtner.de> Hi Dmitry, return value is always paInvalidSampleRate (-9997) no matter what sample rate I try. Am 07.04.2010 23:30, schrieb Dmitry Kostjuchenko: > Frank, > > What error id does ASIOCanSampleRate return? And what was the sample > rate value provided for call? From Frank at Lichtner.de Thu Apr 8 03:23:55 2010 From: Frank at Lichtner.de (Frank Lichtner) Date: Thu, 08 Apr 2010 09:23:55 +0200 Subject: [Portaudio] ASIO MinGW4.xxx In-Reply-To: <015c01cad6e1$e46aa360$0f73a8c0@rossmacbook> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca><1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de> <015c01cad6e1$e46aa360$0f73a8c0@rossmacbook> Message-ID: <4BBD848B.1020306@Lichtner.de> Thanks Ross, I'll try to figure that out :-) Frank Am 08.04.2010 08:08, schrieb Ross Bencina: > After a bit of googling I find that for gcc, the -save-temps flag will > dump intermediate files (the assember file would be the one with the > .s extension I think). If you do this with both gcc 3 and 4 and post > the results I could have a look. You probably won't be able to send > them to the list.. so if you can put them up on a server somewere or > email them privately that would be great. From tibeaux at gmx.de Thu Apr 8 06:31:30 2010 From: tibeaux at gmx.de (Tibeaux Beret) Date: Thu, 8 Apr 2010 12:31:30 +0200 Subject: [Portaudio] confusion about "frames_per_buffer" and "samplerate" In-Reply-To: <4BBD848B.1020306@Lichtner.de> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca><1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de> <015c01cad6e1$e46aa360$0f73a8c0@rossmacbook> <4BBD848B.1020306@Lichtner.de> Message-ID: <000301cad706$a72cd7f0$f58687d0$@de> Hello All, I have following problem: I am using a Portaudio Callback to capture Audio -> send it to a DSP -> receive it back after the DSP has done a Frequency Modulation -> playback / write wav or anything... The Problem is that the DSP Software strictly waits for 48000 values and needs to be read out before sending some new data. So I defined Frames_per_callback as 48000 which is very high compared to all examples... Nevertheless it works somehow, but I recognized, that the latency changes when changing the samplerate. I don't get if, and in which way, those two values depend on each other. Is there a way to come near realtime with a frames_per_buffer of 48000? You see, I am quite confused and I am happy about any hint! Thanks a lot, Timo From theom3ga at gmail.com Thu Apr 8 13:33:16 2010 From: theom3ga at gmail.com (=?ISO-8859-1?Q?Jos=E9_Tom=E1s_Tocino_Garc=EDa?=) Date: Thu, 8 Apr 2010 19:33:16 +0200 Subject: [Portaudio] confusion about "frames_per_buffer" and "samplerate" In-Reply-To: <000301cad706$a72cd7f0$f58687d0$@de> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca> <1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de> <015c01cad6e1$e46aa360$0f73a8c0@rossmacbook> <4BBD848B.1020306@Lichtner.de> <000301cad706$a72cd7f0$f58687d0$@de> Message-ID: I'm just a basic user of PortAudio, but as far as I know, the sample rate is the ammount of samples that are read per second, and the frames per buffer are just that, the number of samples that portaudio's buffer can hold before the callback is called. I'm developing a project and my function works with chunks of 4096 samples, and I'm NOT using a frames_per_buffer of 4096, but a multiple of it, 256 in this case. In each iteration I copy the values of the buffer on a bigger buffer, created by me, and when the bigger buffer is full I call the function. I've found that doing it like that improves the performance versus using a frames_per_buffer value of 4096. Hope it helps. 2010/4/8 Tibeaux Beret > Hello All, > > I have following problem: > > I am using a Portaudio Callback to capture Audio -> send it to a DSP -> > receive it back after the DSP has done a Frequency Modulation -> playback / > write wav or anything... > > The Problem is that the DSP Software strictly waits for 48000 values and > needs to be read out before sending some new data. > > So I defined Frames_per_callback as 48000 which is very high compared to > all > examples... > > Nevertheless it works somehow, but I recognized, that the latency changes > when changing the samplerate. > > I don't get if, and in which way, those two values depend on each other. Is > there a way to come near realtime with a frames_per_buffer of 48000? > > You see, I am quite confused and I am happy about any hint! > > Thanks a lot, > > Timo > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > -- Jos? Tom?s Tocino Garc?a -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander_Carot at gmx.net Thu Apr 8 13:57:12 2010 From: Alexander_Carot at gmx.net (=?iso-8859-1?Q?Alexander_Car=F4t?=) Date: Thu, 8 Apr 2010 19:57:12 +0200 Subject: [Portaudio] confusion about "frames_per_buffer" and "samplerate" In-Reply-To: <000301cad706$a72cd7f0$f58687d0$@de> References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca><1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de> <015c01cad6e1$e46aa360$0f73a8c0@rossmacbook> <4BBD848B.1020306@Lichtner.de> <000301cad706$a72cd7f0$f58687d0$@de> Message-ID: Hi Timo, it appears to me that you are mixing up the sample rate with the frame rate: I believe your DSP expects a *sample rate* of 48 kHz and not a frame size of 48000. The sample rate determines the amount of samples your sound card generates per second but since it is not possible to transfer each sample immediately to the user space of your machine you have to define the number of samples, which are transferred blockwise (or framewise). The lower the frame size the lower the delay. What audio driver are you using ? If you are on Coreaudio, ALSA or ASIO you could be able to apply 64 as the typically lowest frame size or of course anything above such as 128, 256, 512, 1024 as generally applied values. However, with DSound (and some others I am not familiar with) you will experience a lot of dropouts when residing below a frame size of 2048. So, the choice depends on your machine, the sound driver and your actual delay requirements. BTW: The delay has to remain constant. What happens if you configure your card with 48 kHz and the frame size as recommended ? Hope that helps, best -- A l e x Dr.-Ing. Alexander Car?t Email : Alexander at Carot.de Tel.: +49 (0)177 5719797 Am 08.04.2010 um 12:31 schrieb Tibeaux Beret: > Hello All, > > I have following problem: > > I am using a Portaudio Callback to capture Audio -> send it to a DSP -> > receive it back after the DSP has done a Frequency Modulation -> playback / > write wav or anything... > > The Problem is that the DSP Software strictly waits for 48000 values and > needs to be read out before sending some new data. > > So I defined Frames_per_callback as 48000 which is very high compared to all > examples... > > Nevertheless it works somehow, but I recognized, that the latency changes > when changing the samplerate. > > I don't get if, and in which way, those two values depend on each other. Is > there a way to come near realtime with a frames_per_buffer of 48000? > > You see, I am quite confused and I am happy about any hint! > > Thanks a lot, > > Timo > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio From michael.gogins at gmail.com Thu Apr 8 14:32:36 2010 From: michael.gogins at gmail.com (Michael Gogins) Date: Thu, 8 Apr 2010 14:32:36 -0400 Subject: [Portaudio] confusion about "frames_per_buffer" and "samplerate" In-Reply-To: References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca> <1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de> <015c01cad6e1$e46aa360$0f73a8c0@rossmacbook> <4BBD848B.1020306@Lichtner.de> <000301cad706$a72cd7f0$f58687d0$@de> Message-ID: All this terminology is almost idiotically confusing and ambiguous. What follows is the technically correct technology. My audio driver expects a buffer of audio data on each callback. That buffer will contain N frames of audio data. This is the buffer frame size (sometimes loosely called "buffer size"). Each frame contains M channels of audio. Therefore there are N x M samples of audio in the buffer. Each sample is a single number of size K bytes. There are therefore N x M x K bytes of data in the audio buffer. This is the buffer size proper (also sometimes loosely called "buffer size"). The sampling rate is the number of frames per second. It is loosely called "sampling rate" but what it really is, is the frame rate. Suppose I have stereo audio at a "sampling rate" (really frame rate) of 48,000 frames per second. Suppose I have a driver with a buffer frame size of 128 (this is quite common). Suppose I have float samples. Then I have a buffer size in bytes of 128 x 2 x 4 = 1024 bytes. Hope this helps, Mike On Thu, Apr 8, 2010 at 1:57 PM, Alexander Car?t wrote: > Hi Timo, > > it appears to me that you are mixing up the sample rate with the frame rate: I believe your DSP expects a *sample rate* of 48 kHz and not a frame size of 48000. The sample rate determines the amount of samples your sound card generates per second but since it is not possible to transfer each sample immediately to the user space of your machine you have to define the number of samples, which are transferred blockwise (or framewise). The lower the frame size the lower the delay. What audio driver are you using ? If you are on Coreaudio, ALSA or ASIO you could be able to apply 64 as the typically lowest frame size or of course anything above such as 128, 256, 512, 1024 as generally applied values. However, with DSound (and some others I am not familiar with) you will experience a lot of dropouts when residing below a frame size of 2048. So, the choice depends on your machine, the sound driver and your actual delay requirements. BTW: The delay has to remain constant. What happens if you configure your card ?with 48 kHz and the frame size as recommended ? > > Hope that helps, > best > > -- A l e x > > Dr.-Ing. Alexander Car?t > Email : Alexander at Carot.de > Tel.: +49 (0)177 5719797 > > Am 08.04.2010 um 12:31 schrieb Tibeaux Beret: > >> Hello All, >> >> I have following problem: >> >> I am using a Portaudio Callback to capture Audio -> send it to a DSP -> >> receive it back after the DSP has done a Frequency Modulation -> playback / >> write wav or anything... >> >> The Problem is that the DSP Software strictly waits for 48000 values and >> needs to be read out before sending some new data. >> >> So I defined Frames_per_callback as 48000 which is very high compared to all >> examples... >> >> Nevertheless it works somehow, but I recognized, that the latency changes >> when changing the samplerate. >> >> I don't get if, and in which way, those two values depend on each other. Is >> there a way to come near realtime with a frames_per_buffer of 48000? >> >> You see, I am quite confused and I am happy about any hint! >> >> Thanks a lot, >> >> Timo >> >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com From pagreg at galexander.org Thu Apr 8 20:02:36 2010 From: pagreg at galexander.org (Greg Alexander) Date: Thu, 8 Apr 2010 20:02:36 -0400 Subject: [Portaudio] New user - questions/observation about documentation Message-ID: <20100409000236.GE7204@goonies.be> Hi all - I have recently adapted one of my favorite programs to work with portaudio, at the request of a user. I have some observations about the new developer experience which may be useful, and an offer to update the tutorial.. Since I've written interfaces for about half a dozen audio APIs, my most important criterion if I'm gonna bother to learn a new one is simplicity. PortAudio isn't the simplest, but it was simple enough that I was completely done adding it to my program in 40 minutes. That's awesome! I especially love that it provides a realtime callback like CoreAudio, without being as overdesigned and set-a-billion-options as CoreAudio is. So - thanks!! But there was a frustrating element...the tutorial in the wiki (http://www.portaudio.com/trac/wiki/TutorialDir/TutorialStart) is quite good (in that it answered the questions I asked in the order that I asked them). But it is somewhat out of date -- it doesn't quite match up with "libportaudio2 19+svn20071022", which is the current debian package. This is precisely the sort of thing that scares me off, as I'm afraid the API is in flux and is about to change under my feet and render my work useless. It gives a bad impression. But it looks like PortAudio really hasn't changed much since 2007, the wiki is just that old. So it is just that -- an irrelevant bad first impression -- and no more. So anyways my point is I tried to update the wiki but I don't have login credentials for it. How do I go about getting a login for the wiki? Also, I was disappointed to notice there are no man pages for it. It seems simple enough it should only take a couple hours to throw together enough man pages to form a usable reference for it. So I have a question -- is this abandonware at this point, or is there a place for me to submit man pages to be included in the distribution if I write them? One way or the other, thanks everybody for a totally respectable API and library! Cheers, - Greg From pburk at mobileer.com Thu Apr 8 20:17:46 2010 From: pburk at mobileer.com (Phil Burk) Date: Thu, 08 Apr 2010 17:17:46 -0700 Subject: [Portaudio] New user - questions/observation about documentation In-Reply-To: <20100409000236.GE7204@goonies.be> References: <20100409000236.GE7204@goonies.be> Message-ID: <4BBE722A.4030206@mobileer.com> Hi Greg, Thanks for the feedback on PortAudio. I think your observations are accurate. The PortAudio API is easy to use. But the docs are not at the same level as the code. > -- is this abandonware at this point, or is there a place for me to > submit man pages to be included in the distribution if I write them? The PortAudio code is definitely not abandoned. PortAudio is key element in many applications and is actively maintained. But the docs need some love. > So anyways my point is I tried to update the wiki but I don't have login > credentials for it. How do I go about getting a login for the wiki? I'm open to that. I'll check with the others. Thank you, Phil Burk ------------------------------------------------- Mobileer Inc, http://www.mobileer.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 ------------------------------------------------- On 4/8/10 5:02 PM, Greg Alexander wrote: > Hi all - > > I have recently adapted one of my favorite programs to work with > portaudio, at the request of a user. I have some observations about the > new developer experience which may be useful, and an offer to update the > tutorial.. > > Since I've written interfaces for about half a dozen audio APIs, my most > important criterion if I'm gonna bother to learn a new one is simplicity. > PortAudio isn't the simplest, but it was simple enough that I was > completely done adding it to my program in 40 minutes. That's awesome! > I especially love that it provides a realtime callback like CoreAudio, > without being as overdesigned and set-a-billion-options as CoreAudio is. > So - thanks!! > > But there was a frustrating element...the tutorial in the wiki > (http://www.portaudio.com/trac/wiki/TutorialDir/TutorialStart) is quite > good (in that it answered the questions I asked in the order that I asked > them). But it is somewhat out of date -- it doesn't quite match up with > "libportaudio2 19+svn20071022", which is the current debian package. > This is precisely the sort of thing that scares me off, as I'm afraid the > API is in flux and is about to change under my feet and render my work > useless. It gives a bad impression. > > But it looks like PortAudio really hasn't changed much since 2007, the > wiki is just that old. So it is just that -- an irrelevant bad first > impression -- and no more. > > So anyways my point is I tried to update the wiki but I don't have login > credentials for it. How do I go about getting a login for the wiki? > > Also, I was disappointed to notice there are no man pages for it. It > seems simple enough it should only take a couple hours to throw together > enough man pages to form a usable reference for it. So I have a question > -- is this abandonware at this point, or is there a place for me to > submit man pages to be included in the distribution if I write them? > > One way or the other, thanks everybody for a totally respectable API and > library! > > Cheers, > - Greg > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > > From c319chris at aol.com Thu Apr 8 22:41:02 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Thu, 08 Apr 2010 22:41:02 -0400 Subject: [Portaudio] confusion about "frames_per_buffer" and "samplerate" In-Reply-To: References: <4BBB4199.1070801@Lichtner.de><011801cad60d$7d0ddd60$0f73a8c0@rossmacbook><55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca><1270663152.4bbcc7f08334b@mail.inbox.lv><4BBCE137.1070607@Lichtner.de><015c01cad6e1$e46aa360$0f73a8c0@rossmacbook><4BBD848B.1020306@Lichtner.de> <000301cad706$a72cd7f0$f58687d0$@de> Message-ID: <8CCA5A53AA3A5A9-1350-2120@webmail-m038.sysops.aol.com> A sample is typically 1, 2 or 3 bytes of PCM data for one channel, depending on the bit depth (8, 16 or 24 bits). It is essentially the output of the A to D converter for one channel. A frame is one sample times the number of channels. You need to know these numbers to calculate storage requirements (i.e. buffer size). The sample rate is the number of samples per second. Assuming all channels have the same sample rate (which is practically always the case), frame rate will equal sample rate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Thu Apr 8 13:15:24 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Fri, 9 Apr 2010 03:15:24 +1000 Subject: [Portaudio] ASIO MinGW4.xxx References: <4BBB4199.1070801@Lichtner.de> <011801cad60d$7d0ddd60$0f73a8c0@rossmacbook> <55C7BF6D-61FE-4B43-B3BD-D0E5B70ECD3C@mcgill.ca><1270663152.4bbcc7f08334b@mail.inbox.lv> <4BBCE137.1070607@Lichtner.de><015c01cad6e1$e46aa360$0f73a8c0@rossmacbook> <4BBD848B.1020306@Lichtner.de> Message-ID: <004801cad799$95cf9d60$0242000a@rossmacbook> Thanks for sending through the asm files Frank. I've included the relevant sections below for others to inspect. I'm not a GCC ASM expert so I could be wrong, but it looks like GCC4.4 is not generating the correct glue code to put the the address of the sample rate parameter into the EAX register for us (that's what :"a"(¶m1) is supposed to do in CALL_THISCALL_1_DOUBLE). As a result, our asm code is pushing a completely bogus/corrupt sample rate onto the stack to pas to the ASIO driver which would explain the results you're getting. I don't know enough about GCC assembler to know if this is a GCC bug or a bug in our inline assembler syntax but here's a replacement version of CALL_THISCALL_1_DOUBLE which might work ----------------- Replace macro at line 302: #define CALL_THISCALL_1_DOUBLE( resultName, thisPtr, funcOffset, param1 ) \ void *param1Ptr = ¶m1; \ __asm__ __volatile__ ("pushl 4(%1)\n\t" \ "pushl (%1)\n\t" \ "movl (%2), %%edx\n\t" \ "call *"#funcOffset"(%%edx);\n\t" \ :"=a"(resultName) /* Output Operands */ \ :"r"(param1Ptr), /* Input Operands */ \ "c"(thisPtr) \ ); \ Or you could try this if the above doesn't work. #define CALL_THISCALL_1_DOUBLE( resultName, thisPtr, funcOffset, param1 ) \ void *param1Ptr = ¶m1; \ __asm__ __volatile__ ("pushl 4(%1)\n\t" \ "pushl (%1)\n\t" \ "movl (%2), %%edx\n\t" \ "call *"#funcOffset"(%%edx);\n\t" \ :"=a"(resultName) /* Output Operands */ \ :"a"(param1Ptr), /* Input Operands */ \ "c"(thisPtr) \ ); \ ----------------- Let me know how you go... Analysis.... Anyone interested needs to look at the comments in IASIOThiscallResolver to get the full picture -- I won't duplicate that here. on entry to these asm functions esp is the stack ptr [esp] contains the return address [esp+4] contains the IASIOThiscallResolver this ptr [esp+8] contains the double sampleRate the actual asio driver expects its this ptr to be in ecx (the "thiscall" calling convention.) return value goes in eax gcc 3.4.5 generated code: --------------------- movl 4(%esp), %eax // move this into eax movl 4(%eax), %ecx // move this->that_ into ecx (asio driver ptr into ecx where thiscall expects it) leal 8(%esp), %eax // move address of the sample rate stack parameter into eax // gcc generated code above this line, our asm code is the next 4 lines pushl 4(%eax) // push sample rate onto stack, 4 bytes at a time pushl (%eax) // push sample rate onto stack, 4 bytes at a time movl (%ecx), %edx // put that_.vtbl into edx call *48(%edx); // call vtbl+48 (it clears the stack params and returns in eax) ret --------------------- gcc 4.4.0 generated code: --------------------- subl $12, %esp // redundant but harmless offset of stack ptr to make room for (unused) local variables? movl %esp, %eax // ???? this is supposed to be moving a pointer to our sample rate param into eax movl 16(%esp), %edx // move this into edx movl 4(%edx), %ecx // move this->that_ into ecx (asio driver ptr into ecx where thiscall expects it) // gcc generated code above this line, our asm code is the next 4 lines pushl 4(%eax) // push sample rate onto stack, 4 bytes at a time pushl (%eax) // push sample rate onto stack, 4 bytes at a time movl (%ecx), %edx // put that_.vtbl into edx call *48(%edx); // call vtbl+48 (it clears the stack params and returns in eax) addl $12, %esp // compensate for stack ptr offset above ret --------------------- My reading is that gcc 4.4 is not computing the address of the sample rate parameter correctly on this line: movl %esp, %eax That's just setting eax to point into the newly reserved (and uninitialized) local variables area. Seems like a GCC bug. GCC 4.4 is correctly putting this->that_ into ecx for us -- aside from offsetting the stack pointer by 12 bytes there's no difference there. I have no idea why its doing this. Here's the relevant raw output from gcc -save-temps: gcc 3.4.5 raw output: --------------------- .align 2 .p2align 4,,15 .stabs "_ZN21IASIOThiscallResolver13canSampleRateEd:F(49,22)",36,0,454,__ZN21IASIOThiscallResolver13canSampleRateEd .stabs "this:p(0,90)",160,0,454,4 .stabs "sampleRate:p(49,19)",160,0,454,8 .globl __ZN21IASIOThiscallResolver13canSampleRateEd .def __ZN21IASIOThiscallResolver13canSampleRateEd; .scl 2; .type 32; .endef __ZN21IASIOThiscallResolver13canSampleRateEd: .stabn 68,0,454,LM59-__ZN21IASIOThiscallResolver13canSampleRateEd LM59: LBB35: LBB36: .stabn 68,0,456,LM60-__ZN21IASIOThiscallResolver13canSampleRateEd LM60: movl 4(%esp), %eax movl 4(%eax), %ecx leal 8(%esp), %eax /APP pushl 4(%eax) pushl (%eax) movl (%ecx), %edx call *48(%edx); /NO_APP LBE36: LBE35: .stabn 68,0,458,LM61-__ZN21IASIOThiscallResolver13canSampleRateEd LM61: ret .stabs "this:r(0,90)",64,0,454,0 .stabs "result:r(49,20)",64,0,455,0 .stabn 192,0,0,LBB36-__ZN21IASIOThiscallResolver13canSampleRateEd .stabn 224,0,0,LBE36-__ZN21IASIOThiscallResolver13canSampleRateEd Lscope16: .stabs "",36,0,0,Lscope16-__ZN21IASIOThiscallResolver13canSampleRateEd --------------------- gcc 4.4.0 raw output: --------------------- .align 2 .p2align 2,,3 .globl __ZN21IASIOThiscallResolver13canSampleRateEd .def __ZN21IASIOThiscallResolver13canSampleRateEd; .scl 2; .type 32; .endef __ZN21IASIOThiscallResolver13canSampleRateEd: LFB66: .loc 1 454 0 LVL27: subl $12, %esp LCFI2: LBB65: .loc 1 456 0 movl %esp, %eax movl 16(%esp), %edx movl 4(%edx), %ecx /APP # 456 "src/hostapi/asio/iasiothiscallresolver.cpp" 1 pushl 4(%eax) pushl (%eax) movl (%ecx), %edx call *48(%edx); # 0 "" 2 LVL28: LVL29: /NO_APP LBE65: .loc 1 458 0 addl $12, %esp ret --------------------- Ross. From ddrtist at gmail.com Fri Apr 9 03:18:28 2010 From: ddrtist at gmail.com (Tatsh) Date: Fri, 9 Apr 2010 03:18:28 -0400 Subject: [Portaudio] New user - questions/observation about documentation In-Reply-To: <4BBE722A.4030206@mobileer.com> References: <20100409000236.GE7204@goonies.be> <4BBE722A.4030206@mobileer.com> Message-ID: <201004090318.29073.ddrtist@gmail.com> I would also appreciate this and would contribute any of my findings. Phil Burk wrote: > Hi Greg, > > Thanks for the feedback on PortAudio. I think your observations are > accurate. The PortAudio API is easy to use. But the docs are not at the > same level as the code. > > > -- is this abandonware at this point, or is there a place for me to > > submit man pages to be included in the distribution if I write them? > > The PortAudio code is definitely not abandoned. PortAudio is key element > in many applications and is actively maintained. But the docs need some > love. > > > So anyways my point is I tried to update the wiki but I don't have login > > credentials for it. How do I go about getting a login for the wiki? > > I'm open to that. I'll check with the others. > > Thank you, > Phil Burk > ------------------------------------------------- > Mobileer Inc, http://www.mobileer.com/ > 75 Pleasant Lane, San Rafael, CA, 94901 USA > Office: +1-415-453-4320 > Mobile: +1-415-846-4370 > FAX: +1-415-373-4428 > ------------------------------------------------- > > On 4/8/10 5:02 PM, Greg Alexander wrote: > > Hi all - > > > > I have recently adapted one of my favorite programs to work with > > portaudio, at the request of a user. I have some observations about the > > new developer experience which may be useful, and an offer to update the > > tutorial.. > > > > Since I've written interfaces for about half a dozen audio APIs, my most > > important criterion if I'm gonna bother to learn a new one is simplicity. > > PortAudio isn't the simplest, but it was simple enough that I was > > completely done adding it to my program in 40 minutes. That's awesome! > > I especially love that it provides a realtime callback like CoreAudio, > > without being as overdesigned and set-a-billion-options as CoreAudio is. > > So - thanks!! > > > > But there was a frustrating element...the tutorial in the wiki > > (http://www.portaudio.com/trac/wiki/TutorialDir/TutorialStart) is quite > > good (in that it answered the questions I asked in the order that I asked > > them). But it is somewhat out of date -- it doesn't quite match up with > > "libportaudio2 19+svn20071022", which is the current debian package. > > This is precisely the sort of thing that scares me off, as I'm afraid the > > API is in flux and is about to change under my feet and render my work > > useless. It gives a bad impression. > > > > But it looks like PortAudio really hasn't changed much since 2007, the > > wiki is just that old. So it is just that -- an irrelevant bad first > > impression -- and no more. > > > > So anyways my point is I tried to update the wiki but I don't have login > > credentials for it. How do I go about getting a login for the wiki? > > > > Also, I was disappointed to notice there are no man pages for it. It > > seems simple enough it should only take a couple hours to throw together > > enough man pages to form a usable reference for it. So I have a question > > -- is this abandonware at this point, or is there a place for me to > > submit man pages to be included in the distribution if I write them? > > > > One way or the other, thanks everybody for a totally respectable API and > > library! > > > > Cheers, > > - Greg > > _______________________________________________ > > Portaudio mailing list > > Portaudio at music.columbia.edu > > http://music.columbia.edu/mailman/listinfo/portaudio > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > From wingfeathera at gmail.com Fri Apr 9 20:43:35 2010 From: wingfeathera at gmail.com (Matthew Robbetts) Date: Sat, 10 Apr 2010 01:43:35 +0100 Subject: [Portaudio] Thread scheduling in Portaudio Message-ID: <4BBFC9B7.1030504@gmail.com> Hi all, Further to my previous post about my multichannel sound card being presented by the OSS driver as many individual stereo devices, it looks like I will have to use multiple callbacks in my realtime application, one per stereo device. What I need then is a single stereo input stream and 4 stereo output streams. These will be guaranteed to be synchronised in hardware as they will be on the same sound card. What I've tried so far is to have the input stream read in data from the sound card input and copy it into a central buffer. The output steams then all read from this buffer and process it in the ways they need to. The mechanism I've tried is just to pass in a pointer to the buffer as part of the userData struct given to each callback. Now, to test the idea I wrote a simple 'loopback'- type thing, with 1 input stream, 1 output stream, and just copying the audio data from input to buffer, and buffer to output. However, I get garbled sound from this. The music /is/ recognisable, but it's very very distorted. So I'm thinking that the input and output streams might be running at the same time so that the output thread reads potentially incomplete data, when of course what I need is for the output thread to wait until the input thread is finished. I also tried to very quickly implement a double-buffer scheme, but got similar results (garbled sound). Should this work without further thread synchronisation? There's a good chance I've made a mistake in coding it, as it was very quick. In any case, I'd like to avoid adding the extra latency of double-buffering if possible. So, can anyone provide me with information on how multiple streams are scheduled/synchronised in Portaudio? I imagine that they must be locked to the sound card's buffer update cycle, but are any constraints placed on them with respect to each other? If not, one way I've thought of which might achieve the synchronisation I'm looking for is to use a named pipe (or something similar?) which allows the standard read(), write() and select() functions and will let the output threads perform blocking reads. Is this sane? It doesn't seem like a good idea to do a blocking operation inside the callback, but the input thread only has to write data into the pipes and so should run very quickly. It is the most elegant solution I can think of, but there might be practical problems with it I've not seen. Any thoughts? Thanks a lot! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Sat Apr 10 02:06:17 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Sat, 10 Apr 2010 16:06:17 +1000 Subject: [Portaudio] Thread scheduling in Portaudio References: <4BBFC9B7.1030504@gmail.com> Message-ID: <014301cad873$efee9730$0f73a8c0@rossmacbook> Hi Matthew > So, can anyone provide me with information on how multiple streams are scheduled/synchronised in Portaudio? This is something which depends on which host API is used. PortAudio will use whatever is considered the most efficient way of using the host API. For example, in some cases the host API will call PortAudio with a callback, other times PA has to create its own thread. etc. Someone else might be able to fill you in on the details of the OSS implementation -- that's not my area. Or, just take a look at the source code. How about using a semaphore? Increment it for the number of input callbacks which you're expecting. Have the output callbacks block until the input callbacks have all arrived. PortAudio's WMME implementation can fuse multiple stereo streams. I used an array of event objects which I wait on until all inputs are ready -- I'm not sure what the most efficient pthreads equivalent is (something that waits on a set of condition variables perhaps?) Ross. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Sat Apr 10 02:49:37 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Sat, 10 Apr 2010 16:49:37 +1000 Subject: [Portaudio] New user - questions/observation about documentation References: <20100409000236.GE7204@goonies.be> Message-ID: <01b501cad879$fd5f8ae0$0f73a8c0@rossmacbook> Hi Greg > But there was a frustrating element...the tutorial in the wiki > (http://www.portaudio.com/trac/wiki/TutorialDir/TutorialStart) is quite > good (in that it answered the questions I asked in the order that I asked > them). But it is somewhat out of date -- it doesn't quite match up with > "libportaudio2 19+svn20071022", which is the current debian package. If you're going to bother to match things up better to work with the latest snapshot, that one is a somewhat out of date. > This is precisely the sort of thing that scares me off, as I'm afraid the > API is in flux and is about to change under my feet and render my work > useless. It gives a bad impression. Well there's not much that's changed in terms of the v19 API definition over the last few years (probably a lot longer than that) you could review the svn logs for portaudio.h if you want to see how stable the API is. > But it looks like PortAudio really hasn't changed much since 2007, the > wiki is just that old. So it is just that -- an irrelevant bad first > impression -- and no more. There's been a fair bit of work on some of the implementations, not so much on the Linux side though, afaik. > Also, I was disappointed to notice there are no man pages for it. It > seems simple enough it should only take a couple hours to throw together > enough man pages to form a usable reference for it. The definitive reference is the doxygen documentation, especially for portaudio.h. I'm not sure what you have in mind for the man page -- but I'd be wary of creating multiple points of truth which need to be synchronised. If the man page said "read the doxydocs" that would make sense. For reference documentation I think it would be better to improve the doxygen documentation than to split documentation accross multiple formats. There's already been a lot of work put into the doxygen documentation. Also, keep in mind that not all PortAudio supported platforms even use "man". I encourage you to think carefully about whether a man page is appropriate and what it would contain. In the past people have submitted platform specific content (eg build files for various systems) -- if they don't get maintained they become out of date, and eventually they get deleted from the tree. I could see something similar happening with a man page -- personally I see a man page being a maintenance burden unless it's just a link to the other documentation which we are comitted to maintaining (eg doxydocs). Unless you're signing up to maintain it for the next 10 years I can pretty much guarantee it will become out of date and become a liability for the project. > So I have a question > -- is this abandonware at this point, or is there a place for me to > submit man pages to be included in the distribution if I write them? It's definitely not abandonware, although at times I feel like the Linux implementations are in danger of heading in that direction - my impression is that there's a lot more development going on on Windows and OSX. I hope all this doesn't come accross as too disuasive.. I'm very keen for you to contribute :-) Thanks! Ross From dmitrykos at inbox.lv Sat Apr 10 12:19:12 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Sat, 10 Apr 2010 19:19:12 +0300 Subject: [Portaudio] Fwd: Re: ASIO MinGW4.xxx Message-ID: <1270916352.4bc0a5008bdb6@mail.inbox.lv> Hello Ross! I revised new ASM version for MinGW x86 which was supposed to work with newer 4.4.x GCC and found out what is the problem.  The root of problem and explanation why in my case I had my 4.4.0 GCC working well with ASIO - optimisation. GCC 4.4.0 is more advanced than 3.4.x in terms of optimisation and as a result it succesfully optimises out ASIO thiscall glue :) So your version will still no work unless it is modified to the following: #define CALL_THISCALL_1_DOUBLE( resultName, thisPtr, funcOffset, param1 )       do {                                                                        double param1f64 = param1; /* Cast explicitly to double */                  double *param1f64Ptr = ¶m1f64; /* Make pointer to address */             __asm__ __volatile__ ("pushl 4(%1)nt"                                                           "pushl (%1)nt"                                                            "movl (%2), %%edxnt"                                                      "call *"#funcOffset"(%%edx);nt"                                           : "=a"(resultName) /* Output Operands */                                    : "r"(param1f64Ptr),  /* Input Operands */                                  "c"(thisPtr),                                                               "m"(*param1f64Ptr) /* Using address */                                      : "%edx" /* Clobbered Registers */                                          );                                                   } while (0);                                                            1) as we definitely expect double type then let's cast to double first then take pointer to address of this temp variable. It will anyway be optimised by GCC but provides robust implementation for ages; 2) to avoid GCC of optimising out of our parameter we have to add "m"(*param1f64Ptr) directive; 3) we use EDX register explicitly and thus must inform GCC to leave it for us, so we put it in Clobbered register list (this must be done for all other ASM blocks for GCC. I included small ZIP with modified source for testing before we commit it to SVN. I tested on GCC 4.4.0 x86 with -O2 optimisation level and ASIO works ok in my application. As personally I am also split between many platforms I use ASM rarely and also familiar with GCC Inline Assembler to acompilsh some minimal tasks only. Thus, solutions 2) and 3) were advised to me by a very good specialist in low-level programming - Peter Kankowski (http://www.strchr.com/ [1]). Those who are interested in some tips and tricks for C/C++/ASM/Algorithms or would like to share with own findings do not mind visiting StrChr :) It would be great if Frank could test attached file as well. Best regards, Dmitry. Links: ------ [1] http://www.strchr.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iasiothiscallresolver.zip Type: application/x-zip-compressed Size: 5265 bytes Desc: not available URL: From bernt.ronningsbakk at lyse.net Sat Apr 10 12:22:03 2010 From: bernt.ronningsbakk at lyse.net (=?iso-8859-1?Q?Bernt_R=F8nningsbakk?=) Date: Sat, 10 Apr 2010 11:22:03 -0500 Subject: [Portaudio] Real time processing time - callback question Message-ID: <007d01cad8c9$f634c500$e29e4f00$@ronningsbakk@lyse.net> In the callback function I assume that there is a relationship between buffer size and how much time the callback can spend without creating buffer underrun / overrun problems. Is it possible to say something about how much time is available? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Sat Apr 10 13:21:11 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Sun, 11 Apr 2010 03:21:11 +1000 Subject: [Portaudio] Real time processing time - callback question References: <007d01cad8c9$f634c500$e29e4f00$@ronningsbakk@lyse.net> Message-ID: <075c01cad8d2$38271e60$0f73a8c0@rossmacbook> Bernt R?nningsbakk wrote: > In the callback function I assume that there is a relationship > between buffer size and how much time the callback can > spend without creating buffer underrun / overrun problems. > > Is it possible to say something about how much time is available? Hi Bernt Unfortunately there are a few answers: *Best Case* If the callback buffer size matches the internal host buffer size, then the total time available will be close to the buffer duration. i.e: maximumAvailableComputeTimeSeconds = (1. / sampleRate) * bufferSize; PortAudio will use a little bit of this if it has to convert sample formats. The OS or driver may use some too if it has to convert sample rates. *Usual Case* In practice, the operating system needs time to do other things, so if you use all the available time your computer would freeze. It used to be possible to do this on MacOS9 and perhaps some earlier versions of Windows. However these days more likely the OS will demote the audio thread rather than freeze the machine. So the question becomes "how much time can I get away with?." In my experience, about 85% of the maximum available should be possible. More than that and you're going to be pushing the limits of desktop OSes in some cases (on a multicore system you can get closer to 100%, perhaps). There are other reasons why you may not be able to reach this limit. For example, the OS may need CPU time to convert sample formats or apply CPU-based DSP filtering before output (Macs do this when outputting to speakers, but not when headphones are plugged in, for example). I logged a bug with Apple a while back where on Leopard there are certain configurations where the driver won't let you use over 75-80% CPU without breaking up. *PortAudio Buffer Adaption Case* If your callback buffer size is not compatible with the buffer sizes supported by the driver then PortAudio may need to "adapt" the buffer sizes. In some cases what this means is that PortAudio maps one host API callback to one-or-more PortAudio callbacks. Usually this doesn't impact the above discussion. -- PortAudio just calls your callback multiple times to fill one host buffer. However, if your callback buffer size is bigger than a host buffer, or (more commonly) your callback buffer size is not a factor of the host buffer size, PA will sometimes have to invoke the PA callback twice to output (bufferSize+1) samples -- which means you can divide all of the available compute time numbers above in half. Way to avoid this are: - use PA's variable callback buffer size flag - make sure your callback buffer size is compatible with the host API using host-api-specific functions to probe for supported buffer sizes - use relatively small PA buffer sizes (say 16 or 32 samples) compared to the smallest practical host buffer size (assuming your host buffer sizes are bigger than this). There's a pdf in src/hostapis/asio which explains the buffer adaption algorithm. HTH Ross. From Frank at Lichtner.de Sat Apr 10 16:50:32 2010 From: Frank at Lichtner.de (Frank Lichtner) Date: Sat, 10 Apr 2010 22:50:32 +0200 Subject: [Portaudio] Fwd: Re: ASIO MinGW4.xxx In-Reply-To: <1270916352.4bc0a5008bdb6@mail.inbox.lv> References: <1270916352.4bc0a5008bdb6@mail.inbox.lv> Message-ID: <4BC0E498.6040906@Lichtner.de> Hi Dmitry, I did and it works now :-D Thanks for fast fix, I think one should commit that to SVN Am 10.04.2010 18:19, schrieb Dmitry Kostjuchenko: > It would be great if Frank could test attached file as well. From c319chris at aol.com Sun Apr 11 07:45:28 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Sun, 11 Apr 2010 07:45:28 -0400 Subject: [Portaudio] Real time processing time - callback question In-Reply-To: <075c01cad8d2$38271e60$0f73a8c0@rossmacbook> References: <007d01cad8c9$f634c500$e29e4f00$@ronningsbakk@lyse.net> <075c01cad8d2$38271e60$0f73a8c0@rossmacbook> Message-ID: <8CCA7839DA86496-11F0-2047@webmail-m052.sysops.aol.com> - use PA's variable callback buffer size flag This is "paFramesPerBufferUnspecified" found in the Pa_OpenStream function. -------------- next part -------------- An HTML attachment was scrubbed... URL: From c319chris at aol.com Sun Apr 11 23:09:17 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Sun, 11 Apr 2010 23:09:17 -0400 Subject: [Portaudio] Input Latency Message-ID: <8CCA804AC3AB4B8-12CC-1F957@webmail-m005.sysops.aol.com> What effect does PaStreamInfo::inputLatency have when capturing audio? If all I am doing is capturing, can I set it to 0 and forget about it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph.irving at gmail.com Mon Apr 12 10:44:34 2010 From: ralph.irving at gmail.com (ralph.irving at gmail.com) Date: Mon, 12 Apr 2010 10:44:34 -0400 (EDT) Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error Message-ID: I'm having a problem opening any WASAPI device on Vista 32-bit and Win7Pro 64-bit using svn r1485 of portaudio. I'm using the 32-bit mingw gcc compiler from cygwin 2.693. $ gcc -mno-cygwin --version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. I configured portaudio using these options. $ CFLAGS="-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -O2 \ -mno-cygwin -march=i686 -mtune=pentium4" CPPFLAGS="$(CFLAGS)" \ ./configure --with-host_os=mingw --with-winapi=wasapi \ --without-jack --enable-shared=no --enable-debug-output=yes Here is the debug output from libportaudio, and my Win32 console application. I'm thinking that this might be a similar issue to Frank Lichtner's ASIO MinGW4 compiler code generation between gcc 3 and 4. I hoping to not have to move my project to the MSys/MinGW compiler tools just to use WASAPI in my application. Win7Pro 64-bit: before paHostApiInitializers[0]. WASAPI: device i: 0 WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] form-factor: 8 WASAPI: device i: 1 WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] form-factor: 8 WASAPI: device i: 2 WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 WASAPI: initialized okafter paHostApiInitializers[0]. slimaudio_output_init: PortAudio initialized Using audio device index: 2 paDeviceInfo->deviceid 2 paDeviceInfo->maxOutputChannels 2 paDeviceInfo->defaultHighOutputLatency 0 paDeviceInfo->defaultLowhOutputLatency 0 paDeviceInfo->defaultSampleRate 44100.000000 WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1867}] WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2098}] WASAPI ERROR PAERROR: -9996 : Invalid device [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2102}] output_thread: PortAudio error1: Invalid device Vista 32-bit: before paHostApiInitializers[0]. WASAPI: device i: 0 WASAPI: device[Digital Output Device (SPDIF) (High Definition Audio Device)] form-factor: 8 WASAPI: initialized ok after paHostApiInitializers[0]. WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1950}] WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2181}] WASAPI ERROR PAERROR: -9996 : Invalid device [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2185}] output_thread: PortAudio error1: Invalid device Here's the code snippet; PaStreamParameters outputParameters; PaWasapiStreamInfo streamInfo; const PaDeviceInfo * paDeviceInfo; PaDeviceIndex output_device_id = 2; DeviceInfo = Pa_GetDeviceInfo(output_device_id); /* Device is not stereo or better, abort */ if (paDeviceInfo->maxOutputChannels < 2) { printf("output_thread: PortAudio device does not support stereo audio.\n"); exit(-2); } outputParameters.device = output_device_id; outputParameters.channelCount = 2; outputParameters.sampleFormat = paInt16; streamInfo.size = sizeof(PaWasapiStreamInfo); streamInfo.hostApiType = paWASAPI; streamInfo.version = 1; streamInfo.flags = paWinWasapiExclusive; outputParameters.hostApiSpecificStreamInfo = &streamInfo; outputParameters.suggestedLatency = paDeviceInfo->defaultLowOutputLatency; DEBUGF("paDeviceInfo->deviceid %d\n", outputParameters.device); DEBUGF("paDeviceInfo->maxOutputChannels %i\n", paDeviceInfo->maxOutputChannels); DEBUGF("paDeviceInfo->defaultHighOutputLatency %i\n", (int) paDeviceInfo->defaultHighOutputLatency); DEBUGF("paDeviceInfo->defaultLowhOutputLatency %i\n", (int) paDeviceInfo->defaultLowOutputLatency); DEBUGF("paDeviceInfo->defaultSampleRate %f\n", paDeviceInfo->defaultSampleRate); err = Pa_OpenStream (&audio->pa_stream, NULL, &outputParameters, 44100.0, 0, paPrimeOutputBuffersUsingStreamCallback, pa_callback, audio); if (err != paNoError) { printf("output_thread: PortAudio error1: %s\n", Pa_GetErrorText(err) ); exit(-1); } Thanks, Ralphy From c319chris at aol.com Mon Apr 12 13:41:25 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Mon, 12 Apr 2010 13:41:25 -0400 Subject: [Portaudio] Buffers and Latency In-Reply-To: <075c01cad8d2$38271e60$0f73a8c0@rossmacbook> References: <007d01cad8c9$f634c500$e29e4f00$@ronningsbakk@lyse.net> <075c01cad8d2$38271e60$0f73a8c0@rossmacbook> Message-ID: <8CCA87E819539AB-1BC4-3629@webmail-d038.sysops.aol.com> Using DirectSound, if I pass paFramesPerBufferUnspecified (0) and 0 as suggested latency when opening a stream, DS/PA sets its own callback buffer size and latency. and I get good playback. Using MME, if I pass paFramesPerBufferUnspecified and 0 suggested latency, the callback buffer equals bytes per frame and there is no audio output. Using WASAPI, if I pass paFramesPerBufferUnspecified and 0 suggested latency, the callback buffer defaults to 441 (1/10th of sample rate) and the audio is distorted to the point of unusability. If I specify a buffer of 2048 playback is acceptable under MME but not WASAPI. If I pass paFramesPerBufferUnspecified to WASAPI with a higher latency (0.01) I get acceptable playback. What bothers me is that these parameters interact in such a non-uniform way across APIs, and that with the exception of DirectSound the user must discover the optimal values basically by trial and error. Why is DirectSound so much more robust than the others in terms of the parameters passed to it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrykos at inbox.lv Mon Apr 12 15:54:41 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Mon, 12 Apr 2010 22:54:41 +0300 Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: References: Message-ID: <1271102081.4bc37a81b32ed@mail.inbox.lv> Hi Ralphy! The compiler is not a problem for WASAPI, it does not have dependencies similar to ASIO. >From the log you showed I see no output devices. WASAPI shows just SPDIF HDA which is actually an Input device (capturing). see: Digital Audio (S/PDIF) (High Definition Audio Device)] (form-factor: 8) For both OSes. Thus you can't open them for Output. Regards, Dmitry. Quoting ralph.irving at gmail.com: > I'm having a problem opening any WASAPI device on Vista 32-bit and Win7Pro > 64-bit using svn r1485 of portaudio. I'm using the 32-bit mingw gcc > compiler from cygwin 2.693. > $ gcc -mno-cygwin --version > gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > Copyright (C) 2004 Free Software Foundation, Inc. > I configured portaudio using these options. > $ CFLAGS="-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -O2 \ > -mno-cygwin -march=i686 -mtune=pentium4" CPPFLAGS="$(CFLAGS)" \ > ./configure --with-host_os=mingw --with-winapi=wasapi \ > --without-jack --enable-shared=no --enable-debug-output=yes > Here is the debug output from libportaudio, and my Win32 console > application. I'm thinking that this might be a similar issue to Frank > Lichtner's ASIO MinGW4 compiler code generation between gcc 3 and 4. I > hoping to not have to move my project to the MSys/MinGW compiler tools > just to use WASAPI in my application. > Win7Pro 64-bit: > before paHostApiInitializers[0]. > WASAPI: device i: 0 > WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] > > WASAPI: device i: 1 > WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] > form-factor: 8 > WASAPI: device i: 2 > WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 > WASAPI: initialized okafter paHostApiInitializers[0]. > slimaudio_output_init: PortAudio initialized > Using audio device index: 2 > paDeviceInfo->deviceid 2 > paDeviceInfo->maxOutputChannels 2 > paDeviceInfo->defaultHighOutputLatency 0 > paDeviceInfo->defaultLowhOutputLatency 0 > paDeviceInfo->defaultSampleRate 44100.000000 > WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD > [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1867}] > WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2098}] > WASAPI ERROR PAERROR: -9996 : Invalid device > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2102}] > output_thread: PortAudio error1: Invalid device > Vista 32-bit: > before paHostApiInitializers[0]. > WASAPI: device i: 0 > WASAPI: device[Digital Output Device (SPDIF) (High Definition Audio > Device)] > form-factor: 8 > WASAPI: initialized ok > after paHostApiInitializers[0]. > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1950}] > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2181}] > WASAPI ERROR PAERROR: -9996 : Invalid device > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2185}] > output_thread: PortAudio error1: Invalid device > Here's the code snippet; > PaStreamParameters outputParameters; > PaWasapiStreamInfo streamInfo; > const PaDeviceInfo * paDeviceInfo; > PaDeviceIndex output_device_id = 2; > DeviceInfo = Pa_GetDeviceInfo(output_device_id); > /* Device is not stereo or better, abort */ > if (paDeviceInfo->maxOutputChannels < 2) > { > printf("output_thread: PortAudio device does not support stereo audio.\n"); > exit(-2); > } > outputParameters.device = output_device_id; > outputParameters.channelCount = 2; > outputParameters.sampleFormat = paInt16; > streamInfo.size = sizeof(PaWasapiStreamInfo); > streamInfo.hostApiType = paWASAPI; > streamInfo.version = 1; > streamInfo.flags = paWinWasapiExclusive; > outputParameters.hostApiSpecificStreamInfo = &streamInfo; > outputParameters.suggestedLatency = paDeviceInfo->defaultLowOutputLatency; > DEBUGF("paDeviceInfo->deviceid %d\n", > outputParameters.device); > DEBUGF("paDeviceInfo->maxOutputChannels %i\n", > paDeviceInfo->maxOutputChannels); > DEBUGF("paDeviceInfo->defaultHighOutputLatency %i\n", > (int) paDeviceInfo->defaultHighOutputLatency); > DEBUGF("paDeviceInfo->defaultLowhOutputLatency %i\n", > (int) paDeviceInfo->defaultLowOutputLatency); > DEBUGF("paDeviceInfo->defaultSampleRate %f\n", > paDeviceInfo->defaultSampleRate); > err = Pa_OpenStream (&audio->pa_stream, NULL, &outputParameters, 44100.0, > 0, paPrimeOutputBuffersUsingStreamCallback, pa_callback, audio); > if (err != paNoError) { > printf("output_thread: PortAudio error1: %s\n", > Pa_GetErrorText(err) ); > exit(-1); > } > Thanks, > Ralphy > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] From dmitrykos at inbox.lv Mon Apr 12 16:08:32 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Mon, 12 Apr 2010 23:08:32 +0300 Subject: [Portaudio] WASAPI In-Reply-To: <8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com> References: <1270494111.4bba339f11908@mail.inbox.lv> <8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com> <1271001305.4bc1f0d9d24e4@mail.inbox.lv> <8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com> <1271009097.4bc20f4974931@mail.inbox.lv> <8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com> <1271020139.4bc23a6bea8dc@mail.inbox.lv> <8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com> <1271053089.4bc2bb217de14@mail.inbox.lv> <8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com> <1271064106.4bc2e62a12963@mail.inbox.lv> <8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com> <1271069220.4bc2fa242c18d@mail.inbox.lv> <8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com> Message-ID: <1271102912.4bc37dc05f1f0@mail.inbox.lv> Hi Chris! About your post: Using WASAPI, if I pass paFramesPerBufferUnspecified and 0 suggested latency, the callback buffer defaults to 441 (1/10th of sample rate) and the audio is distorted to the point of unusability. ----- Which windows, and mode? Please tell me: Your Windows 7 32-bit? Shared or Exclusive mode? Also what is sample size (bits)? I tested on C example on Sine, and have no-problem quality for Exclusive/Shared modes, for 24-bit mono. My system Windows Vista x64. Using paFramesPerBufferUnspecified and suggested latency 0. Here is the log: wFormatTag=WAVE_FORMAT_EXTENSIBLE SubFormat=KSDATAFORMAT_SUBTYPE_PCM Samples.wValidBitsPerSample=24 dwChannelMask =0x3 nChannels =2 nSamplesPerSec =48000 nAvgBytesPerSec=384000 nBlockAlign =8 wBitsPerSample =32 cbSize =22 PaWASAPIOpenStream(output): framesPerHostCallback[ 128 ] latency[ 2.67ms ] exclusive[ YES ] wow64_fix[ NO ] Play for 55 seconds. WASAPI: thread[ priority-0xFFFFFFF9 class-0x20 ] Dmitry. Quoting c319chris at aol.com: > Dmitry - > > > The attached PureBasic program records 10 seconds of audio from the > default device. There is no callback, it just records to one large buffer > and then saves that buffer when recording is finished. > > > > Chris iAuxSoft ------------------ [www.iauxsoft.com] From dmitrykos at inbox.lv Mon Apr 12 16:59:21 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Mon, 12 Apr 2010 23:59:21 +0300 Subject: [Portaudio] WASAPI In-Reply-To: <1271102912.4bc37dc05f1f0@mail.inbox.lv> References: <1270494111.4bba339f11908@mail.inbox.lv> <8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com> <1271001305.4bc1f0d9d24e4@mail.inbox.lv> <8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com> <1271009097.4bc20f4974931@mail.inbox.lv> <8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com> <1271020139.4bc23a6bea8dc@mail.inbox.lv> <8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com> <1271053089.4bc2bb217de14@mail.inbox.lv> <8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com> <1271064106.4bc2e62a12963@mail.inbox.lv> <8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com> <1271069220.4bc2fa242c18d@mail.inbox.lv> <8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com> <1271102912.4bc37dc05f1f0@mail.inbox.lv> Message-ID: <1271105961.4bc389a93c86b@mail.inbox.lv> Well, WASAPI set me up :) I ended up with AUDCLNT_E_BUFFER_SIZE_ERROR if suggestedLatency is set to 0. I've commited patch that fixes such behavior, also patch is critical for everyone who is already using WASAPI for applications as it fixes possible crash in Pa_OpenStream in regards to WASAPI layer. SVN has details in log. Quoting "Dmitry Kostjuchenko" : > Hi Chris! > > About your post: > Using WASAPI, if I pass paFramesPerBufferUnspecified and 0 suggested > latency, the callback buffer defaults to > 441 (1/10th of sample rate) and the audio is distorted to the point of > unusability. > ----- > Which windows, and mode? > > Please tell me: > Your Windows 7 32-bit? Shared or Exclusive mode? Also what is sample size > (bits)? > > I tested on C example on Sine, and have no-problem quality for > Exclusive/Shared modes, for 24-bit mono. My > system Windows Vista x64. > > Using paFramesPerBufferUnspecified and suggested latency 0. > > Here is the log: > > wFormatTag=WAVE_FORMAT_EXTENSIBLE > SubFormat=KSDATAFORMAT_SUBTYPE_PCM > Samples.wValidBitsPerSample=24 > dwChannelMask =0x3 > nChannels =2 > nSamplesPerSec =48000 > nAvgBytesPerSec=384000 > nBlockAlign =8 > wBitsPerSample =32 > cbSize =22 > PaWASAPIOpenStream(output): framesPerHostCallback[ 128 ] latency[ 2.67ms > ] exclusive[ YES ] wow64_fix[ > NO ] > Play for 55 seconds. > WASAPI: thread[ priority-0xFFFFFFF9 class-0x20 ] > > Dmitry. > > Quoting c319chris at aol.com: > > Dmitry - > > > > > > The attached PureBasic program records 10 seconds of audio from the > > default device. There is no callback, it just records to one large > buffer > > and then saves that buffer when recording is finished. > > > > > > > > Chris > > > iAuxSoft > ------------------ > [www.iauxsoft.com] > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] From bernt.ronningsbakk at lyse.net Mon Apr 12 20:50:18 2010 From: bernt.ronningsbakk at lyse.net (=?iso-8859-1?Q?Bernt_R=F8nningsbakk?=) Date: Mon, 12 Apr 2010 19:50:18 -0500 Subject: [Portaudio] Real time processing time - callback question In-Reply-To: References: Message-ID: <015c01cadaa3$4b0ce0a0$e126a1e0$@ronningsbakk@lyse.net> Thanks Ross, for a great clarification I take it then, that I can use buffer size and sample rate as an indicator of available time - as long as I operate with a generous margin. One more question though: Are there scenarious where the buffer size will change mid-stream? With Asio? With the MS api's? And if so - are there strategies to lock the buffer size? I'm into sort of block processing here, and knowing the buffer size in advance can make a huge difference, especially under minimum latency conditions. Kind regards, Bernt > Date: Sun, 11 Apr 2010 03:21:11 +1000 > From: "Ross Bencina" > Hi Bernt > > Unfortunately there are a few answers: > > *Best Case* > If the callback buffer size matches the internal host buffer size, then > the > total time available will be close to the buffer duration. i.e: > > maximumAvailableComputeTimeSeconds = (1. / sampleRate) * bufferSize; > > PortAudio will use a little bit of this if it has to convert sample > formats. > The OS or driver may use some too if it has to convert sample rates. > > > *Usual Case* > In practice, the operating system needs time to do other things, so if > you > use all the available time your computer would freeze. It used to be > possible to do this on MacOS9 and perhaps some earlier versions of > Windows. > However these days more likely the OS will demote the audio thread > rather > than freeze the machine. So the question becomes "how much time can I > get > away with?." In my experience, about 85% of the maximum available > should be > possible. More than that and you're going to be pushing the limits of > desktop OSes in some cases (on a multicore system you can get closer to > 100%, perhaps). > > There are other reasons why you may not be able to reach this limit. > For > example, the OS may need CPU time to convert sample formats or apply > CPU-based DSP filtering before output (Macs do this when outputting to > speakers, but not when headphones are plugged in, for example). I > logged a > bug with Apple a while back where on Leopard there are certain > configurations where the driver won't let you use over 75-80% CPU > without > breaking up. > > > *PortAudio Buffer Adaption Case* > If your callback buffer size is not compatible with the buffer sizes > supported by the driver then PortAudio may need to "adapt" the buffer > sizes. > In some cases what this means is that PortAudio maps one host API > callback > to one-or-more PortAudio callbacks. Usually this doesn't impact the > above > discussion. -- PortAudio just calls your callback multiple times to > fill one > host buffer. However, if your callback buffer size is bigger than a > host > buffer, or (more commonly) your callback buffer size is not a factor of > the > host buffer size, PA will sometimes have to invoke the PA callback > twice to > output (bufferSize+1) samples -- which means you can divide all of the > available compute time numbers above in half. Way to avoid this are: > - use PA's variable callback buffer size flag > - make sure your callback buffer size is compatible with the host API > using > host-api-specific functions to probe for supported buffer sizes > - use relatively small PA buffer sizes (say 16 or 32 samples) compared > to > the smallest practical host buffer size (assuming your host buffer > sizes are > bigger than this). > There's a pdf in src/hostapis/asio which explains the buffer adaption > algorithm. From bhadauria.rohit at gmail.com Tue Apr 13 03:00:40 2010 From: bhadauria.rohit at gmail.com (rohit bhadauria) Date: Tue, 13 Apr 2010 12:30:40 +0530 Subject: [Portaudio] Regarding latency in playback with continuous recording going on Message-ID: Hello everybody...... I am surprised to see the delay in playback while continuously recording through portaudio. When I am running smple portaudio for multichannel input one by one I am not getting that much latency but when I am continuously recording also along with the playback the latency is quite a lot. Is there any way to reduce that. -- Rohit Bhadauria SENSE, VIT University, Tamil Nadu, 632014, Mobile: 09994614298(not active now) 09538965291(Bangalore number) E-mail: bhadauria.rohit at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph.irving at gmail.com Tue Apr 13 07:17:44 2010 From: ralph.irving at gmail.com (ralph.irving at gmail.com) Date: Tue, 13 Apr 2010 07:17:44 -0400 (EDT) Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: <1271102081.4bc37a81b32ed@mail.inbox.lv> References: <1271102081.4bc37a81b32ed@mail.inbox.lv> Message-ID: Thanks Dmitry. Am I not actually trying to opening id 2 the headphones in the Win7 example? > WASAPI: device i: 2 > WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 > WASAPI: initialized okafter paHostApiInitializers[0]. > slimaudio_output_init: PortAudio initialized > Using audio device index: 2 > paDeviceInfo->deviceid 2 > paDeviceInfo->maxOutputChannels 2 My bad for the Vista example, I'll retest it later today. Ralphy On Mon, 12 Apr 2010, Dmitry Kostjuchenko wrote: > Hi Ralphy! > > The compiler is not a problem for WASAPI, it does not have dependencies similar to ASIO. > > From the log you showed I see no output devices. WASAPI shows just SPDIF HDA which is actually an Input > device (capturing). > > see: Digital Audio (S/PDIF) (High Definition Audio Device)] (form-factor: 8) > > For both OSes. > > Thus you can't open them for Output. > > Regards, > Dmitry. > > Quoting ralph.irving at gmail.com: >> I'm having a problem opening any WASAPI device on Vista 32-bit and Win7Pro >> 64-bit using svn r1485 of portaudio. I'm using the 32-bit mingw gcc >> compiler from cygwin 2.693. > >> $ gcc -mno-cygwin --version >> gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) >> Copyright (C) 2004 Free Software Foundation, Inc. > >> I configured portaudio using these options. >> $ CFLAGS="-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -O2 \ >> -mno-cygwin -march=i686 -mtune=pentium4" CPPFLAGS="$(CFLAGS)" \ >> ./configure --with-host_os=mingw --with-winapi=wasapi \ >> --without-jack --enable-shared=no --enable-debug-output=yes > >> Here is the debug output from libportaudio, and my Win32 console >> application. I'm thinking that this might be a similar issue to Frank >> Lichtner's ASIO MinGW4 compiler code generation between gcc 3 and 4. I >> hoping to not have to move my project to the MSys/MinGW compiler tools >> just to use WASAPI in my application. > >> Win7Pro 64-bit: > >> before paHostApiInitializers[0]. >> WASAPI: device i: 0 >> WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] >> >> WASAPI: device i: 1 >> WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] >> form-factor: 8 >> WASAPI: device i: 2 >> WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 >> WASAPI: initialized okafter paHostApiInitializers[0]. >> slimaudio_output_init: PortAudio initialized >> Using audio device index: 2 >> paDeviceInfo->deviceid 2 >> paDeviceInfo->maxOutputChannels 2 >> paDeviceInfo->defaultHighOutputLatency 0 >> paDeviceInfo->defaultLowhOutputLatency 0 >> paDeviceInfo->defaultSampleRate 44100.000000 >> WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD >> [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1867}] >> WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD >> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2098}] >> WASAPI ERROR PAERROR: -9996 : Invalid device >> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2102}] >> output_thread: PortAudio error1: Invalid device > >> Vista 32-bit: > >> before paHostApiInitializers[0]. >> WASAPI: device i: 0 >> WASAPI: device[Digital Output Device (SPDIF) (High Definition Audio >> Device)] >> form-factor: 8 >> WASAPI: initialized ok >> after paHostApiInitializers[0]. >> WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR >> [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1950}] >> WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR >> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2181}] >> WASAPI ERROR PAERROR: -9996 : Invalid device >> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2185}] >> output_thread: PortAudio error1: Invalid device > >> Here's the code snippet; > >> PaStreamParameters outputParameters; >> PaWasapiStreamInfo streamInfo; >> const PaDeviceInfo * paDeviceInfo; >> PaDeviceIndex output_device_id = 2; > >> DeviceInfo = Pa_GetDeviceInfo(output_device_id); >> /* Device is not stereo or better, abort */ >> if (paDeviceInfo->maxOutputChannels < 2) >> { >> printf("output_thread: PortAudio device does not support stereo audio.\n"); >> exit(-2); >> } > >> outputParameters.device = output_device_id; >> outputParameters.channelCount = 2; >> outputParameters.sampleFormat = paInt16; > >> streamInfo.size = sizeof(PaWasapiStreamInfo); >> streamInfo.hostApiType = paWASAPI; >> streamInfo.version = 1; >> streamInfo.flags = paWinWasapiExclusive; >> outputParameters.hostApiSpecificStreamInfo = &streamInfo; >> outputParameters.suggestedLatency = paDeviceInfo->defaultLowOutputLatency; > >> DEBUGF("paDeviceInfo->deviceid %d\n", >> outputParameters.device); >> DEBUGF("paDeviceInfo->maxOutputChannels %i\n", >> paDeviceInfo->maxOutputChannels); >> DEBUGF("paDeviceInfo->defaultHighOutputLatency %i\n", >> (int) paDeviceInfo->defaultHighOutputLatency); >> DEBUGF("paDeviceInfo->defaultLowhOutputLatency %i\n", >> (int) paDeviceInfo->defaultLowOutputLatency); >> DEBUGF("paDeviceInfo->defaultSampleRate %f\n", >> paDeviceInfo->defaultSampleRate); > >> err = Pa_OpenStream (&audio->pa_stream, NULL, &outputParameters, 44100.0, >> 0, paPrimeOutputBuffersUsingStreamCallback, pa_callback, audio); > >> if (err != paNoError) { >> printf("output_thread: PortAudio error1: %s\n", >> Pa_GetErrorText(err) ); >> exit(-1); >> } > >> Thanks, > >> Ralphy >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > > > > iAuxSoft > ------------------ > [www.iauxsoft.com] > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > From dmitrykos at inbox.lv Tue Apr 13 08:21:12 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Tue, 13 Apr 2010 15:21:12 +0300 Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: References: <1271102081.4bc37a81b32ed@mail.inbox.lv> Message-ID: <1271161272.4bc461b8eed07@mail.inbox.lv> Hi Ralphy, Do not use 'WASAPI: device i: 2' id as device id for your parameters for Pa_OpenStream call, 2 here is internal for WASAPI only, use PA methods to get correct device id. For that you shall have a kind of for loop and check there for API type, then if it is Input or Output device (using channels != 0 parameter for example). Regards, Dmitry. Quoting ralph.irving at gmail.com: > Thanks Dmitry. > Am I not actually trying to opening id 2 the headphones in the Win7 > example? > > WASAPI: device i: 2 > > WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 > > WASAPI: initialized okafter paHostApiInitializers[0]. > > slimaudio_output_init: PortAudio initialized > > Using audio device index: 2 > > paDeviceInfo->deviceid 2 > > paDeviceInfo->maxOutputChannels 2 > My bad for the Vista example, I'll retest it later today. > Ralphy > On Mon, 12 Apr 2010, Dmitry Kostjuchenko wrote: > > Hi Ralphy! > > The compiler is not a problem for WASAPI, it does not have dependencies similar to ASIO. > > From the log you showed I see no output devices. WASAPI shows just SPDIF HDA which is actually an Input > > device (capturing). > > see: Digital Audio (S/PDIF) (High Definition Audio Device)] (form-factor: 8) > > For both OSes. > > Thus you can't open them for Output. > > Regards, > > Dmitry. > > Quoting ralph.irving at gmail.com: > > > I'm having a problem opening any WASAPI device on Vista 32-bit and Win7Pro > > > 64-bit using svn r1485 of portaudio. I'm using the 32-bit mingw gcc > > > compiler from cygwin 2.693. > > > $ gcc -mno-cygwin --version > > > gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > > Copyright (C) 2004 Free Software Foundation, Inc. > > > I configured portaudio using these options. > > > $ CFLAGS="-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -O2 \ > > > -mno-cygwin -march=i686 -mtune=pentium4" CPPFLAGS="$(CFLAGS)" \ > > > ./configure --with-host_os=mingw --with-winapi=wasapi \ > > > --without-jack --enable-shared=no --enable-debug-output=yes > > > Here is the debug output from libportaudio, and my Win32 console > > > application. I'm thinking that this might be a similar issue to Frank > > > Lichtner's ASIO MinGW4 compiler code generation between gcc 3 and 4. I > > > hoping to not have to move my project to the MSys/MinGW compiler tools > > > just to use WASAPI in my application. > > > Win7Pro 64-bit: > > > before paHostApiInitializers[0]. > > > WASAPI: device i: 0 > > > WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] > > > WASAPI: device i: 1 > > > WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] > > > form-factor: 8 > > > WASAPI: device i: 2 > > > WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 > > > WASAPI: initialized okafter paHostApiInitializers[0]. > > > slimaudio_output_init: PortAudio initialized > > > Using audio device index: 2 > > > paDeviceInfo->deviceid 2 > > > paDeviceInfo->maxOutputChannels 2 > > > paDeviceInfo->defaultHighOutputLatency 0 > > > paDeviceInfo->defaultLowhOutputLatency 0 > > > paDeviceInfo->defaultSampleRate 44100.000000 > > > WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD > > > [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1867}] > > > WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2098}] > > > WASAPI ERROR PAERROR: -9996 : Invalid device > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2102}] > > > output_thread: PortAudio error1: Invalid device > > > Vista 32-bit: > > > before paHostApiInitializers[0]. > > > WASAPI: device i: 0 > > > WASAPI: device[Digital Output Device (SPDIF) (High Definition Audio > > > Device)] > > > form-factor: 8 > > > WASAPI: initialized ok > > > after paHostApiInitializers[0]. > > > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > > > [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1950}] > > > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2181}] > > > WASAPI ERROR PAERROR: -9996 : Invalid device > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2185}] > > > output_thread: PortAudio error1: Invalid device > > > Here's the code snippet; > > > PaStreamParameters outputParameters; > > > PaWasapiStreamInfo streamInfo; > > > const PaDeviceInfo * paDeviceInfo; > > > PaDeviceIndex output_device_id = 2; > > > DeviceInfo = Pa_GetDeviceInfo(output_device_id); > > > /* Device is not stereo or better, abort */ > > > if (paDeviceInfo->maxOutputChannels < 2) > > > { > > > printf("output_thread: PortAudio device does not support stereo audio.\n"); > > > exit(-2); > > > } > > > outputParameters.device = output_device_id; > > > outputParameters.channelCount = 2; > > > outputParameters.sampleFormat = paInt16; > > > streamInfo.size = sizeof(PaWasapiStreamInfo); > > > streamInfo.hostApiType = paWASAPI; > > > streamInfo.version = 1; > > > streamInfo.flags = paWinWasapiExclusive; > > > outputParameters.hostApiSpecificStreamInfo = &streamInfo; > > > outputParameters.suggestedLatency = paDeviceInfo->defaultLowOutputLatency; > > > DEBUGF("paDeviceInfo->deviceid %d\n", > > > outputParameters.device); > > > DEBUGF("paDeviceInfo->maxOutputChannels %i\n", > > > paDeviceInfo->maxOutputChannels); > > > DEBUGF("paDeviceInfo->defaultHighOutputLatency %i\n", > > > (int) paDeviceInfo->defaultHighOutputLatency); > > > DEBUGF("paDeviceInfo->defaultLowhOutputLatency %i\n", > > > (int) paDeviceInfo->defaultLowOutputLatency); > > > DEBUGF("paDeviceInfo->defaultSampleRate %f\n", > > > paDeviceInfo->defaultSampleRate); > > > err = Pa_OpenStream (&audio->pa_stream, NULL, &outputParameters, 44100.0, > > > 0, paPrimeOutputBuffersUsingStreamCallback, pa_callback, audio); > > > if (err != paNoError) { > > > printf("output_thread: PortAudio error1: %s\n", > > > Pa_GetErrorText(err) ); > > > exit(-1); > > > } > > > Thanks, > > > Ralphy > > > _______________________________________________ > > > Portaudio mailing list > > > Portaudio at music.columbia.edu > > > http://music.columbia.edu/mailman/listinfo/portaudio > > iAuxSoft > > ------------------ > > [www.iauxsoft.com] > > _______________________________________________ > > Portaudio mailing list > > Portaudio at music.columbia.edu > > http://music.columbia.edu/mailman/listinfo/portaudio > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] From c319chris at aol.com Tue Apr 13 12:59:09 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Tue, 13 Apr 2010 12:59:09 -0400 Subject: [Portaudio] WASAPI In-Reply-To: <1271102912.4bc37dc05f1f0@mail.inbox.lv> References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com> <1271102912.4bc37dc05f1f0@mail.inbox.lv> Message-ID: <8CCA941C4FF386E-1BC4-11998@webmail-d038.sysops.aol.com> Dmitry - I am using Windows 7, 32-bits. All testing is in exclusive mode. Samples are 16-bit mono. The fact that you are using 64-bit Windows may make a difference. 64 bits may not be representative of the experience of a user with a 32-bit system, of which there is still a very large installed user base. -----Original Message----- From: Dmitry Kostjuchenko To: Portaudio Mailing List Sent: Mon, Apr 12, 2010 1:08 pm Subject: Re: [Portaudio] WASAPI Hi Chris! About your post: Using WASAPI, if I pass paFramesPerBufferUnspecified and 0 suggested latency, the callback buffer defaults to 441 (1/10th of sample rate) and the audio is distorted to the point of unusability. ----- Which windows, and mode? Please tell me: Your Windows 7 32-bit? Shared or Exclusive mode? Also what is sample size (bits)? I tested on C example on Sine, and have no-problem quality for Exclusive/Shared modes, for 24-bit mono. My system Windows Vista x64. Using paFramesPerBufferUnspecified and suggested latency 0. Here is the log: wFormatTag=WAVE_FORMAT_EXTENSIBLE SubFormat=KSDATAFORMAT_SUBTYPE_PCM Samples.wValidBitsPerSample=24 dwChannelMask =0x3 nChannels =2 nSamplesPerSec =48000 nAvgBytesPerSec=384000 nBlockAlign =8 wBitsPerSample =32 cbSize =22 PaWASAPIOpenStream(output): framesPerHostCallback[ 128 ] latency[ 2.67ms ] exclusive[ YES ] wow64_fix[ NO ] Play for 55 seconds. WASAPI: thread[ priority-0xFFFFFFF9 class-0x20 ] Dmitry. = -------------- next part -------------- An HTML attachment was scrubbed... URL: From c319chris at aol.com Tue Apr 13 13:13:09 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Tue, 13 Apr 2010 13:13:09 -0400 Subject: [Portaudio] WASAPI In-Reply-To: <1271105961.4bc389a93c86b@mail.inbox.lv> References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv> <1271105961.4bc389a93c86b@mail.inbox.lv> Message-ID: <8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> I don't know where to find this "log". It seems everything on the web having to do with PortAudio is in a state of disarray. On the page where I download the latest snapshots I find a link to this page which is described as "changes that have been made to the API" but which brings up a page about "proposed enhancements" with the most recent entry being from 2004. -----Original Message----- From: Dmitry Kostjuchenko To: Portaudio Mailing List Sent: Mon, Apr 12, 2010 1:59 pm Subject: Re: [Portaudio] WASAPI SVN has details in log. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrykos at inbox.lv Tue Apr 13 13:31:01 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Tue, 13 Apr 2010 20:31:01 +0300 Subject: [Portaudio] WASAPI In-Reply-To: <8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv> <1271105961.4bc389a93c86b@mail.inbox.lv> <8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> Message-ID: <1271179861.4bc4aa55aec80@mail.inbox.lv> Hi Chris, If you do not update from SVN repository then SVN log along with repository can be seen from the Web browser at: http://portaudio.com/trac/browser/portaudio/trunk?which is accessible through http://www.portaudio.com/usingsvn.html. Dmitry. Quoting c319chris at aol.com: > I don't know where to find this "log". It seems everything on the web having to do with PortAudio is in a state of disarray. On the page where I download the latest snapshots I find a link to this page which is described as "changes that have been made to the API" but which brings up a page about "proposed enhancements" with the most recent entry being from 2004. > -----Original Message----- > From: Dmitry Kostjuchenko > To: Portaudio Mailing List > Sent: Mon, Apr 12, 2010 1:59 pm > Subject: Re: [Portaudio] WASAPI > SVN has details in log. > > > iAuxSoft ------------------ [www.iauxsoft.com] From c319chris at aol.com Tue Apr 13 13:50:34 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Tue, 13 Apr 2010 13:50:34 -0400 Subject: [Portaudio] WASAPI In-Reply-To: <1271179861.4bc4aa55aec80@mail.inbox.lv> References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv><1271105961.4bc389a93c86b@mail.inbox.lv><8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> <1271179861.4bc4aa55aec80@mail.inbox.lv> Message-ID: <8CCA948F397E195-1BC4-1262C@webmail-d038.sysops.aol.com> Sorry to contradict you, but there is no link to this page: http://portaudio.com/trac/browser/portaudio/trunk on this page: http://www.portaudio.com/usingsvn.html If there is I sure can't find it. -----Original Message----- From: Dmitry Kostjuchenko To: Portaudio Mailing List Sent: Tue, Apr 13, 2010 10:31 am Subject: Re: [Portaudio] WASAPI Hi Chris, If you do not update from SVN repository then SVN log along with repository can be seen from the Web browser at: http://portaudio.com/trac/browser/portaudio/trunk which is accessible through http://www.portaudio.com/usingsvn.html. Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrykos at inbox.lv Wed Apr 14 03:34:18 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Wed, 14 Apr 2010 10:34:18 +0300 Subject: [Portaudio] WASAPI In-Reply-To: <8CCA948F397E195-1BC4-1262C@webmail-d038.sysops.aol.com> References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv><1271105961.4bc389a93c86b@mail.inbox.lv><8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> <1271179861.4bc4aa55aec80@mail.inbox.lv> <8CCA948F397E195-1BC4-1262C@webmail-d038.sysops.aol.com> Message-ID: <1271230458.4bc56ffa67a55@mail.inbox.lv> Chris, There is something wrong with your internet connection may be. If you open page http://www.portaudio.com/usingsvn.html [1] then there is a line 'Or you can browse the SVN repository online at: http://portaudio.com/trac/ [2] ' if you follow it a Trac CMS will be opened were you will see 'Browse Source' menu item. If you go to 'Browse Source' you will have SVN tree opened and you need to go to 'portaudio' item. Then the whole way to WASAPI implementation would be: portaudio >> trunk >> src >> hostapi >> wasapi  There you will see link to 'pa_win_wasapi.c' file and if you click it it will be shown a full list of Revisions and if Revision is clicked then source modifications (diff) will be shown. Regards, Dmitry. Quoting *c319chris at aol.com*: > Sorry to contradict you, but there is no link to this page: >   > http://portaudio.com/trac/browser/portaudio/trunk [3] >   > on this page: >   > http://www.portaudio.com/usingsvn.html [4] >   > If there is I sure can't find it. > > > -----Original Message----- > From: Dmitry Kostjuchenko > To: Portaudio Mailing List > Sent: Tue, Apr 13, 2010 10:31 am > Subject: Re: [Portaudio] WASAPI > > > > Hi Chris, > > If you do not update from SVN repository then SVN log along with > repository can > be seen from the Web browser at: > http://portaudio.com/trac/browser/portaudio/trunk [5] which is > accessible through > http://www.portaudio.com/usingsvn.html [6]. > > Dmitry. iAuxSoft ------------------ [www.iauxsoft.com] Links: ------ [1] http://www.portaudio.com/usingsvn.html [2] http://portaudio.com/trac/ [3] http://portaudio.com/trac/browser/portaudio/trunk [4] http://www.portaudio.com/usingsvn.html [5] http://portaudio.com/trac/browser/portaudio/trunk [6] http://www.portaudio.com/usingsvn.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjfoerster at web.de Wed Apr 14 03:58:35 2010 From: tjfoerster at web.de (Thomas Foerster) Date: Wed, 14 Apr 2010 09:58:35 +0200 Subject: [Portaudio] WASAPI In-Reply-To: <1271230458.4bc56ffa67a55@mail.inbox.lv> References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv><1271105961.4bc389a93c86b@mail.inbox.lv><8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> <1271179861.4bc4aa55aec80@mail.inbox.lv> <8CCA948F397E195-1BC4-1262C@webmail-d038.sysops.aol.com> <1271230458.4bc56ffa67a55@mail.inbox.lv> Message-ID: <4BC575AB.1030103@web.de> Hi Dmitry, perhaps is this "command" confusing: http://portaudio.com/trac/wiki/UsingThePortAudioSvnRepository >svn co https://www.portaudio.com/repos/portaudio/trunk . Should be in svn-program: https://www.portaudio.com/repos/portaudio/trunk Regards Thomas Dmitry Kostjuchenko schrieb: > Chris, > > There is something wrong with your internet connection may be. If you > open page > http://www.portaudio.com/usingsvn.html then there is a line 'Or you > can browse the SVN repository online at: http://portaudio.com/trac/ ' > if you follow it a Trac CMS will be opened were you will see 'Browse > Source' menu item. If you go to 'Browse Source' you will have SVN tree > opened and you need to go to 'portaudio' item. Then the whole way to > WASAPI implementation would be: > portaudio >> trunk >> src >> hostapi >> wasapi > There you will see link to 'pa_win_wasapi.c' file and if you click it > it will be shown a full list of Revisions and if Revision is clicked > then source modifications (diff) will be shown. > > Regards, > Dmitry. > Quoting *c319chris at aol.com *: > > Sorry to contradict you, but there is no link to this page: > > http://portaudio.com/trac/browser/portaudio/trunk > > on this page: > > http://www.portaudio.com/usingsvn.html > > If there is I sure can't find it. > > > -----Original Message----- > From: Dmitry Kostjuchenko > To: Portaudio Mailing List > Sent: Tue, Apr 13, 2010 10:31 am > Subject: Re: [Portaudio] WASAPI > > Hi Chris, > > If you do not update from SVN repository then SVN log along with repository can > be seen from the Web browser at: > http://portaudio.com/trac/browser/portaudio/trunk which is accessible through > http://www.portaudio.com/usingsvn.html. > > Dmitry. > > > > > > > iAuxSoft > ------------------ > [www.iauxsoft.com] > ------------------------------------------------------------------------ > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio From rossb-lists at audiomulch.com Wed Apr 14 04:40:20 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 14 Apr 2010 18:40:20 +1000 Subject: [Portaudio] WASAPI References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv><1271105961.4bc389a93c86b@mail.inbox.lv><8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> <1271179861.4bc4aa55aec80@mail.inbox.lv> <8CCA948F397E195-1BC4-1262C@webmail-d038.sysops.aol.com><1271230458.4bc56ffa67a55@mail.inbox.lv> <4BC575AB.1030103@web.de> Message-ID: <037c01cadbae$1eb98e70$0f73a8c0@rossmacbook> Thomas Foerster wrote: > perhaps is this "command" confusing: > http://portaudio.com/trac/wiki/UsingThePortAudioSvnRepository > >>svn co https://www.portaudio.com/repos/portaudio/trunk . > > Should be in svn-program: https://www.portaudio.com/repos/portaudio/trunk Thomas, perhaps you are confused. When you see text which starts with ">" that usually meants "type this in to a command prompt". If you have svn installed, go to a command prompt and type: svn co https://www.portaudio.com/repos/portaudio/trunk . It will check out the svn trunk. As the wiki says, it may prompt you to confirm the certificate, like that URL does in a browser. Ross. From rossb-lists at audiomulch.com Wed Apr 14 04:46:42 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 14 Apr 2010 18:46:42 +1000 Subject: [Portaudio] Input Latency References: <8CCA804AC3AB4B8-12CC-1F957@webmail-m005.sysops.aol.com> Message-ID: <039c01cadbaf$024d98c0$0f73a8c0@rossmacbook> Hi Chris When capturing audio, buffering works similarly to when outputting audio. In the capture case, you need to make sure the driver has enough empty space to write newly captured data -- ie you're queuing empty buffers to the driver to fill. You will always need to queue enough buffer space so that the driver doesn't starve. PaStreamInfo::inputLatency will control the amount of buffering -- if you don't use "enough" the driver will starve. But if I understand your question, I agree it is perhaps a little bit strange to call it "inputLatency"... Ross. ----- Original Message ----- From: c319chris at aol.com To: portaudio at music.columbia.edu Sent: Monday, April 12, 2010 1:09 PM Subject: [Portaudio] Input Latency What effect does PaStreamInfo::inputLatency have when capturing audio? If all I am doing is capturing, can I set it to 0 and forget about it? ------------------------------------------------------------------------------ _______________________________________________ Portaudio mailing list Portaudio at music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Wed Apr 14 05:05:02 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 14 Apr 2010 19:05:02 +1000 Subject: [Portaudio] Buffers and Latency References: <007d01cad8c9$f634c500$e29e4f00$@ronningsbakk@lyse.net><075c01cad8d2$38271e60$0f73a8c0@rossmacbook> <8CCA87E819539AB-1BC4-3629@webmail-d038.sysops.aol.com> Message-ID: <03ae01cadbb1$91fe58e0$0f73a8c0@rossmacbook> Chris wrote: > Using DirectSound, if I pass paFramesPerBufferUnspecified (0) and 0 as suggested latency when opening a stream, DS/PA sets its own callback buffer size and latency. and I get good playback. That's actually outside spec. > Using MME, if I pass paFramesPerBufferUnspecified and 0 suggested latency, the callback buffer equals bytes per frame and there is no audio output. Passing 0 as suggested latency is a corner case. PA/WMME is doing what you ask (use the lowest possible latency) it just doesn't happen to work well with your hardware/OS configuration. Really you should be using the "default" latency values reported by PA in PaHostApiInfo rather than (0) as suggestedLatency. http://www.portaudio.com/docs/v19-doxydocs/structPaHostApiInfo.html Now, they *might* not be implemented properly, but that's a separate issue, and would be a bug. > Using WASAPI, if I pass paFramesPerBufferUnspecified and 0 suggested latency, the callback buffer defaults to 441 (1/10th of sample rate) and the audio is distorted to the point of unusability. If I specify a buffer of 2048 playback is acceptable under MME but not WASAPI. If I pass paFramesPerBufferUnspecified to WASAPI with a higher latency (0.01) I get acceptable playback. Read the documentation for the suggested latency parameter: http://www.portaudio.com/docs/v19-doxydocs/structPaStreamParameters.html All of those behaviors seem within bounds of what is specified for suggestedLatency. If you specify a too-big buffer for the API it simply won't work (it wouldn't work on the hardware either). But perhaps this is a WASAPI bug. 2048 sounds like a reasonable buffer size to me. > What bothers me is that these parameters interact in such a non-uniform way across APIs, and that with the exception of DirectSound the user must discover the optimal values basically by trial and error. As I said above, passing suggestedLatency (0) is undocumented. It just so happens that Pa/DS supports it in a way you want it to. There is an API for requesting correct lower bounds for suggestedLatency. > Why is DirectSound so much more robust than the others in terms of the parameters passed to it? - There is nothing in the spec which suggests the behavior you request is correct. - Each host API was written by a different person (I mostly re-wrote the WMME one for V19 and ported the DS one to v19 but I mostly reproduced V18 behavior for handling 0 suggestedLatency). - You can probably thank Phil or Robert M. for deciding to defaut 0 suggested latency to the platform-default. I would argue that the WMME one is more true to the spec in that it creates the buffer size you requested. The real "problem" is that the host APIs themselves all work differently, and there is rarely a way to determing the "lowest working latency" without trial and error. This is not a problem PortAudio can fix asside from making suggestions about practical latency values. PortAudio lets you set buffer sizes below what works -- otherwise it wouldn't allow users to tune latencies as low as their system permits (which is as system/os/driver/audio hardware dependent factor). HTH Ross =================================== Perform, Compose, Mangle AudioMulch 2.0 modular audio software for PC and Mac http://www.audiomulch.com ----- Original Message ----- From: c319chris at aol.com To: portaudio at music.columbia.edu Sent: Tuesday, April 13, 2010 3:41 AM Subject: [Portaudio] Buffers and Latency Using DirectSound, if I pass paFramesPerBufferUnspecified (0) and 0 as suggested latency when opening a stream, DS/PA sets its own callback buffer size and latency. and I get good playback. Using MME, if I pass paFramesPerBufferUnspecified and 0 suggested latency, the callback buffer equals bytes per frame and there is no audio output. Using WASAPI, if I pass paFramesPerBufferUnspecified and 0 suggested latency, the callback buffer defaults to 441 (1/10th of sample rate) and the audio is distorted to the point of unusability. If I specify a buffer of 2048 playback is acceptable under MME but not WASAPI. If I pass paFramesPerBufferUnspecified to WASAPI with a higher latency (0.01) I get acceptable playback. What bothers me is that these parameters interact in such a non-uniform way across APIs, and that with the exception of DirectSound the user must discover the optimal values basically by trial and error. Why is DirectSound so much more robust than the others in terms of the parameters passed to it? ------------------------------------------------------------------------------ _______________________________________________ Portaudio mailing list Portaudio at music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Wed Apr 14 05:21:38 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 14 Apr 2010 19:21:38 +1000 Subject: [Portaudio] Real time processing time - callback question References: <015c01cadaa3$4b0ce0a0$e126a1e0$@ronningsbakk@lyse.net> Message-ID: <03b901cadbb3$e3ef7330$0f73a8c0@rossmacbook> Bernt R?nningsbakk: > I take it then, that I can use buffer size and sample rate as an indicator > of available time - as long as I operate with a generous margin. In general yes, aside from caveats about ASIO buffer adaption. > One more question though: > > Are there scenarious where the buffer size will change mid-stream? With > Asio? With the MS api's? If you specify a specific PA callback buffer size: no. If you use paFramesPerBufferUnspecified: yes, with direct sound I think you'll be asked to fill/take all available DS-ring-buffer space, which will vary, with other APIs I think no. > And if so - are there strategies to lock the buffer size? I'm into sort of > block processing here, and knowing the buffer size in advance can make a > huge difference, especially under minimum latency conditions. There are two approaches: 1. Use a fixed PA callback buffer size. That will lock the buffer size. You can still avoid buffer-adaption overhead if you match the callback buffer size to the host buffer size using low-level api specific functions. 2. Use paFramesPerBufferUnspecified and deal with it yourself (slice the callback buffer into smaller sub-blocks). In most (all?) cases, if you really want to do strict block processing then using a fixed PA buffer size is probably as good as what you might implement yourself to work around using paFramesPerBufferUnspecified. What I have concluded (although not implemented) is that it's really not practical any more to use fixed block size for low latency processing as all soundcards have different/weird buffer size constraints (unless you make your block size the same as the soundcard block size). Currently I use a fixed PA callback block size in my App, but I'm planning to: - Split once-per-app-block ("control-rate") updates into a separate function. - Allow block computation to be performed in multiple stages. ie "computeNextNSamplesOfBlock(n)" -- perhaps with 4 sample alignment for SSE. So, if one of my app blocks overlaps a PA block (or, incidentally, a VST host block) I can just compute a partial block and compute the other half at the next PA callback. This is more flexible, and I don't expect it to hurt performance given that soundcaard buffer sizes are now falling below my control-rate block size. HTH Ross. From tjfoerster at web.de Wed Apr 14 05:26:40 2010 From: tjfoerster at web.de (Thomas Foerster) Date: Wed, 14 Apr 2010 11:26:40 +0200 Subject: [Portaudio] WASAPI In-Reply-To: <037c01cadbae$1eb98e70$0f73a8c0@rossmacbook> References: <1270494111.4bba339f11908@mail.inbox.lv><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv><1271105961.4bc389a93c86b@mail.inbox.lv><8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> <1271179861.4bc4aa55aec80@mail.inbox.lv> <8CCA948F397E195-1BC4-1262C@webmail-d038.sysops.aol.com><1271230458.4bc56ffa67a55@mail.inbox.lv> <4BC575AB.1030103@web.de> <037c01cadbae$1eb98e70$0f73a8c0@rossmacbook> Message-ID: <4BC58A50.90506@web.de> No Ross, I am not confused. SVN works for me with everything I am using. I thought this was the reason for Chris, not to get the repository. Thomas Ross Bencina schrieb: > Thomas Foerster wrote: >> perhaps is this "command" confusing: >> http://portaudio.com/trac/wiki/UsingThePortAudioSvnRepository >> >>> svn co https://www.portaudio.com/repos/portaudio/trunk . >> >> Should be in svn-program: >> https://www.portaudio.com/repos/portaudio/trunk > > Thomas, perhaps you are confused. When you see text which starts with > ">" that usually meants "type this in to a command prompt". If you > have svn installed, go to a command prompt and type: > svn co https://www.portaudio.com/repos/portaudio/trunk . > > It will check out the svn trunk. > > As the wiki says, it may prompt you to confirm the certificate, like > that URL does in a browser. > > Ross. > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > From rossb-lists at audiomulch.com Wed Apr 14 05:36:45 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 14 Apr 2010 19:36:45 +1000 Subject: [Portaudio] WASAPI References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv><1271105961.4bc389a93c86b@mail.inbox.lv> <8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> Message-ID: <03eb01cadbb6$0055bc30$0f73a8c0@rossmacbook> Chris wrote: >I don't know where to find this "log". Use SVN, check out PortAudio, then type: svn log If you want to track the most recent changes I strongly recommend pulling from SVN rather than using the web snapshots. You can also browse recent changesets on the web at: http://portaudio.com/trac/timeline Note that Dimitry is a relatively new PortAudio developer. You can't expect him to have all the answers about the system as a whole. >>>> It seems everything on the web having to do with PortAudio is in a state of disarray. On the page where I download the latest snapshots I find a link to this page which is described as "changes that have been made to the API" but which brings up a page about "proposed enhancements" with the most recent entry being from 2004. <<<< There have been no changes to the set of proposed enhancements to PortAudio since 2004 when V19 API design was completed. That means the API is relatively stable. I fail to see how this constitutes "a state of disarray" -- it's actually a good thing imho. But yes, in general, I agree the website could be improved. But this is an open source project run by volunteers. Personally I prefer to be spend my time answering support requests on the mailing list or fixing PA bugs than refactoring a website. If you have some specific constructive suggestions about how the organisation of the website can be improved that would be great. Thanks Ross. ----- Original Message ----- From: c319chris at aol.com To: portaudio at music.columbia.edu Sent: Wednesday, April 14, 2010 3:13 AM Subject: Re: [Portaudio] WASAPI I don't know where to find this "log". It seems everything on the web having to do with PortAudio is in a state of disarray. On the page where I download the latest snapshots I find a link to this page which is described as "changes that have been made to the API" but which brings up a page about "proposed enhancements" with the most recent entry being from 2004. -----Original Message----- From: Dmitry Kostjuchenko To: Portaudio Mailing List Sent: Mon, Apr 12, 2010 1:59 pm Subject: Re: [Portaudio] WASAPI SVN has details in log. ------------------------------------------------------------------------------ _______________________________________________ Portaudio mailing list Portaudio at music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Wed Apr 14 05:38:38 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 14 Apr 2010 19:38:38 +1000 Subject: [Portaudio] WASAPI References: <1270494111.4bba339f11908@mail.inbox.lv><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv><1271105961.4bc389a93c86b@mail.inbox.lv><8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> <1271179861.4bc4aa55aec80@mail.inbox.lv> <8CCA948F397E195-1BC4-1262C@webmail-d038.sysops.aol.com><1271230458.4bc56ffa67a55@mail.inbox.lv> <4BC575AB.1030103@web.de><037c01cadbae$1eb98e70$0f73a8c0@rossmacbook> <4BC58A50.90506@! web.de> Message-ID: <040001cadbb6$43961300$0f73a8c0@rossmacbook> Thomas Foerster wrote: > No Ross, I am not confused. SVN works for me with everything I am using. I > thought this was the reason for Chris, not to get the repository. Hi Thomas Sorry.. my sincere apologies. An error due to reading my email in reverse chronological order. Ross. > Thomas > > > Ross Bencina schrieb: >> Thomas Foerster wrote: >>> perhaps is this "command" confusing: >>> http://portaudio.com/trac/wiki/UsingThePortAudioSvnRepository >>> >>>> svn co https://www.portaudio.com/repos/portaudio/trunk . >>> >>> Should be in svn-program: >>> https://www.portaudio.com/repos/portaudio/trunk >> >> Thomas, perhaps you are confused. When you see text which starts with ">" >> that usually meants "type this in to a command prompt". If you have svn >> installed, go to a command prompt and type: >> svn co https://www.portaudio.com/repos/portaudio/trunk . >> >> It will check out the svn trunk. >> >> As the wiki says, it may prompt you to confirm the certificate, like that >> URL does in a browser. >> >> Ross. >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio >> > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio From dmitrykos at inbox.lv Wed Apr 14 06:02:21 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Wed, 14 Apr 2010 13:02:21 +0300 Subject: [Portaudio] Buffers and Latency In-Reply-To: <03ae01cadbb1$91fe58e0$0f73a8c0@rossmacbook> References: <007d01cad8c9$f634c500$e29e4f00$@ronningsbakk@lyse.net><075c01cad8d2$38271e60$0f73a8c0@rossmacbook> <8CCA87E819539AB-1BC4-3629@webmail-d038.sysops.aol.com> <03ae01cadbb1$91fe58e0$0f73a8c0@rossmacbook> Message-ID: <1271239341.4bc592adb7564@mail.inbox.lv> Hi Ross, 2048 buffer size for WASAPI is not a problem, as this buffer is related to PA internal processing, not WASAPI host API. I guess the problem here was 0 latency and for Vista I had no limitation for latency of device, it is my design intent, as WASAPI under Vista allows to set latency to a very low, sometimes unworkable value. With some fast systems and good drivers you can get non corrupted audio even at 1.3ms, that is nice. But, for Windows 7 Microsoft decided to fix lowest device latency at safe 3ms to avoid users complaining to tech. support I guess :) Moreover WASAPI specifics requires device period (buffer) aligned to HDA packet size - 128bytes and in my latest commit I improved alignment logics that earlier could make latency a little lower than user specified that was confusing and that could provide artefacts due to hardware limits. I also played around 0 latency set by PA user, now it will default to device default period. Currently WASAPI PA's implementation seems to be production stable. Best regards, Dmitry. Quoting *Ross Bencina *: > Chris wrote: > > Using DirectSound, if I pass paFramesPerBufferUnspecified (0) > and 0 as suggested latency when opening a stream, DS/PA sets its own > callback buffer size and latency. and I get good playback. >   > That's actually outside spec. >   >   > > Using MME, if I pass paFramesPerBufferUnspecified and 0 > suggested latency, the callback buffer equals bytes per frame and > there is no audio output. >   > Passing 0 as suggested latency is a corner case. PA/WMME is doing > what you ask (use the lowest possible latency) it just doesn't > happen to work well with your hardware/OS configuration. >   > Really you should be using the "default" latency values reported by > PA in PaHostApiInfo rather than (0) as suggestedLatency. > http://www.portaudio.com/docs/v19-doxydocs/structPaHostApiInfo.html > [1] >   > Now, they *might* not be implemented properly, but that's a separate > issue, and would be a bug. >   >   > > Using WASAPI, if I pass paFramesPerBufferUnspecified and 0 > suggested latency, the callback buffer defaults to 441 (1/10th of > sample rate) and the audio is distorted to the point of unusability. > If I specify a buffer of 2048 playback is acceptable under MME but > not WASAPI. If I pass paFramesPerBufferUnspecified to WASAPI with a > higher latency (0.01) I get acceptable playback. >   > Read the documentation for the suggested latency parameter: > http://www.portaudio.com/docs/v19-doxydocs/structPaStreamParameters.html > [2] >   > All of those behaviors seem within bounds of what is specified for > suggestedLatency. If you specify a too-big buffer for the API it > simply won't work (it wouldn't work on the hardware either). But > perhaps this is a WASAPI bug. 2048 sounds like a reasonable buffer > size to me. >   >   > > What bothers me is that these parameters interact in such a > non-uniform way across APIs, and that with the exception of > DirectSound the user must discover the optimal values basically by > trial and error. >   > As I said above, passing suggestedLatency (0) is undocumented. It > just so happens that Pa/DS supports it in a way you want it to. > There is an API for requesting correct lower bounds for > suggestedLatency. >   >   > > Why is DirectSound so much more robust than the others in terms > of the parameters passed to it? > >   > - There is nothing in the spec which suggests the behavior you > request is correct. >   > - Each host API was written by a different person (I mostly re-wrote > the WMME one for V19 and ported the DS one to v19 but I mostly > reproduced V18 behavior for handling 0 suggestedLatency). >   > - You can probably thank Phil or Robert M. for deciding to defaut 0 > suggested latency to the platform-default. I would argue that the > WMME one is more true to the spec in that it creates the buffer size > you requested. >   >   > The real "problem" is that the host APIs themselves all work > differently, and there is rarely a way to determing the "lowest > working latency" without trial and error. This is not a problem > PortAudio can fix asside from making suggestions about practical > latency values.  PortAudio lets you set buffer sizes below what > works -- otherwise it wouldn't allow users to tune latencies as low > as their system permits (which is as system/os/driver/audio hardware > dependent factor). >   >   > HTH >   > Ross >   >   >   >   >   >   >   >   > =================================== > Perform, Compose, Mangle > AudioMulch 2.0 modular audio software for PC and Mac > http://www.audiomulch.com [3] >> ----- Original Message ----- >> *From:* c319chris at aol.com >> *To:* portaudio at music.columbia.edu >> *Sent:* Tuesday, April 13, 2010 3:41 AM >> *Subject:* [Portaudio] Buffers and Latency >>   >> Using DirectSound, if I pass paFramesPerBufferUnspecified (0) and 0 >> as suggested latency when opening a stream, DS/PA sets its own >> callback buffer size and latency. and I get good playback. Using >> MME, if I pass paFramesPerBufferUnspecified and 0 suggested >> latency, the callback buffer equals bytes per frame and there is no >> audio output. Using WASAPI, if I pass paFramesPerBufferUnspecified >> and 0 suggested latency, the callback buffer defaults to 441 >> (1/10th of sample rate) and the audio is distorted to the point of >> unusability. If I specify a buffer of 2048 playback is acceptable >> under MME but not WASAPI. If I pass paFramesPerBufferUnspecified to >> WASAPI with a higher latency (0.01) I get acceptable playback. >>   >> What bothers me is that these parameters interact in such a >> non-uniform way across APIs, and that with the exception of >> DirectSound the user must discover the optimal values basically by >> trial and error. Why is DirectSound so much more robust than the >> others in terms of the parameters passed to it? >>   >> >> ------------------------- >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > iAuxSoft ------------------ [www.iauxsoft.com] Links: ------ [1] http://www.portaudio.com/docs/v19-doxydocs/structPaHostApiInfo.html [2] http://www.portaudio.com/docs/v19-doxydocs/structPaStreamParameters.html [3] http://www.audiomulch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.reiss at elec.qmul.ac.uk Wed Apr 14 06:31:39 2010 From: josh.reiss at elec.qmul.ac.uk (Josh Reiss) Date: Wed, 14 Apr 2010 11:31:39 +0100 Subject: [Portaudio] Audio Engineering Society Convention May 22-25 London, Registration and Technical Programme available Message-ID: <7BA16F8108C17240A4D965D3FC0411860140508DF5@staff-mail2.vpn.elec.qmul.ac.uk> Apologies if you receive multiple copies of this message. Technical programme and registration now online for the 128th Audio Engineering Society Convention, May 22-25 London --------------------- For the first time in over 20 years, the AES European Convention will take place in London, May 22-25. The AES announces that the technical programme and registration are now available online at http://www.aes.org/events/128/. The Novotel London West Convention Centre is conveniently located just off the A4 between Heathrow Airport and Central London, and with easy access via the Piccadilly tube (Hammersmith). The Novotel is also the official convention hotel. TECHNICAL PROGRAM A strong and extensive technical programme of sessions are planned, including nearly 200 papers in 16 lecture sessions, and an additional 10 poster sessions- a record number. These in-depth topics to be explored will range from audio for broadcast, Topics to be covered include: high-performance audio processing; sound reinforcement; spatial signal processing; games audio; recording and post-production;loudspeakers and headphones; music analysis and processing; audio information retrieval; room and architectural acoustics; network, Internet, and broadcast audio; noise reduction and speech intelligibility; spatial audio perception; multichannel and spatial audio; audio coding and compression; microphones, converters, and amplifiers; innovative applications; listening tests and evaluation psychoacoustics. The Technical Programme also includes over 20 tutorials, workshops and broadcast and special events. They will be devoted to topics such as Blu-ray as a high-resolution audio format, semantic audio, hearing conservation, and digital microphones. Technical tours may include visits to BBC studios, the British Library Sound Archive, EMI Archives, the National Theatre, and Royal Festival Hall, and others. In conjunction with APRS, there will also be panel sessions featuring high profile record producers and studio owners. The convention will be also arranged so that the exhibits and technical program sessions are close together and complement each other. Go to www.aes.org/events/128/program for an up-to-date schedule of all events. EXHIBITS The London Exhibit Hall is enthusiastically filling fast, and there are only a few exhibitor spaces left. Exhibitors from countries around the globe - over 70 exhibitors from large to boutique firms - will have new products and technologies to introduce at the show. Many companies will also present in-depth product information in exhibitor seminars, which are held off the exhibition floor in classroom-like settings. SPECIAL EVENTS, STUDENT ACTIVITIES, AND MEETINGS Student and educational events-student recording competitions, the Education Fair, the Careers Fair, and mentoring sessions-have in recent years become major components of AES conventions. This fast-growing segment of AES membership brings youthful enthusiasm to everyone they come into contact with during the convention, and they will form the foundation of the Society in the coming years. For more details go to www.aes.org/events/128/students. The Standards Committee will oversee important work on AES Standards during a busy schedule of meetings before and during the convention. Go to www.aes.org/standards for the schedule of meetings. The AES Technical Council has a full schedule of AES Technical Committee meetings planned; for more information go to www.aes.org/technical. The Technical Council will sponsor the 22nd Heyser Memorial Lecture to be given at the 128th by Brian Moore of Cambridge University. He will discuss hearing loss and hearing aids. Additional details on the exhibits, technical programme, and registration are available now on the AES website. Advance registration for the full program and exhibition is offered at a reduced fee. You can reserve your hotel room using the PDF form on the website. Make sure to mention AES in any communication with the hotel. Book your room today at www.aes.org/events/128/hotels/ For more details, see: http://www.aes.org/events/128/ From c319chris at aol.com Wed Apr 14 08:11:54 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Wed, 14 Apr 2010 08:11:54 -0400 Subject: [Portaudio] WASAPI In-Reply-To: <03eb01cadbb6$0055bc30$0f73a8c0@rossmacbook> References: <1270494111.4bba339f11908@mail.inbox.lv><8CCA78A2A852006-1190-22D0F@webmail-m060.sysops.aol.com><1271001305.4bc1f0d9d24e4@mail.inbox.lv><8CCA7AAAC8E984C-1184-20621@webmail-d089.sysops.aol.com><1271009097.4bc20f4974931@mail.inbox.lv><8CCA7CBE06811E9-1184-22543@webmail-d089.sysops.aol.com><1271020139.4bc23a6bea8dc@mail.inbox.lv><8CCA7FA5086819D-12CC-1EECA@webmail-m005.sysops.aol.com><1271053089.4bc2bb217de14@mail.inbox.lv><8CCA82BEA516A86-12CC-21079@webmail-m005.sysops.aol.com><1271064106.4bc2e62a12963@mail.inbox.lv><8CCA83D945D1AE4-12CC-219C7@webmail-m005.sysops.aol.com><1271069220.4bc2fa242c18d@mail.inbox.lv><8CCA85577E90BC8-12CC-22DDD@webmail-m005.sysops.aol.com><1271102912.4bc37dc05f1f0@mail.inbox.lv><1271105961.4bc389a93c86b@mail.inbox.lv><8CCA943B999B935-1BC4-11D25@webmail-d038.sysops.aol.com> <03eb01cadbb6$0055bc30$0f73a8c0@rossmacbook> Message-ID: <8CCA9E2CEB8EDC5-34D8-ABAD@webmail-d092.sysops.aol.com> -----Original Message----- From: Ross Bencina To: Portaudio Mailing List Sent: Wed, Apr 14, 2010 2:36 am Subject: Re: [Portaudio] WASAPI << Note that Dimitry is a relatively new PortAudio developer. You can't expect him to have all the answers about the system as a whole. >> Unless I pose a question to him via private email, my questions are for the board at large. -------------- next part -------------- An HTML attachment was scrubbed... URL: From c319chris at aol.com Wed Apr 14 08:24:55 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Wed, 14 Apr 2010 08:24:55 -0400 Subject: [Portaudio] Input Latency In-Reply-To: <039c01cadbaf$024d98c0$0f73a8c0@rossmacbook> References: <8CCA804AC3AB4B8-12CC-1F957@webmail-m005.sysops.aol.com> <039c01cadbaf$024d98c0$0f73a8c0@rossmacbook> Message-ID: <8CCA9E49FC1AA48-34D8-ADB0@webmail-d092.sysops.aol.com> Ross - My confusion arises from the fact that you have one parameter called "input latency" and another called framesperbuffer which is the fifth argument in pa_openstream. You're saying "input latency" controls the amount of buffering, so what does the "framesperbuffer" argument do? A capture buffer has the opposite problem from a playback buffer -- it doesn't "starve", it overflows, i.e. the data is coming in faster than the system can handle it. -----Original Message----- From: Ross Bencina To: Portaudio Mailing List Sent: Wed, Apr 14, 2010 1:46 am Subject: Re: [Portaudio] Input Latency Hi Chris When capturing audio, buffering works similarly to when outputting audio. In the capture case, you need to make sure the driver has enough empty space to write newly captured data -- ie you're queuing empty buffers to the driver to fill. You will always need to queue enough buffer space so that the driver doesn't starve. PaStreamInfo::inputLatency will control the amount of buffering -- if you don't use "enough" the driver will starve. But if I understand your question, I agree it is perhaps a little bit strange to call it "inputLatency"... Ross. -------------- next part -------------- An HTML attachment was scrubbed... URL: From I.Tholley at lboro.ac.uk Wed Apr 14 09:05:09 2010 From: I.Tholley at lboro.ac.uk (I.Tholley at lboro.ac.uk) Date: Wed, 14 Apr 2010 14:05:09 +0100 Subject: [Portaudio] extracting melodies or choruses Message-ID: Hi, I was wondering if anyone knows how to extract melodies or the chorus of a song from an .mp3 file using c++. Please help if you can. Thanks Ibs From c319chris at aol.com Wed Apr 14 19:52:28 2010 From: c319chris at aol.com (c319chris at aol.com) Date: Wed, 14 Apr 2010 19:52:28 -0400 Subject: [Portaudio] extracting melodies or choruses In-Reply-To: References: Message-ID: <8CCAA44AC8FAA1C-49C-13CAC@webmail-d070.sysops.aol.com> That's a very tall order. There are programs which claim to be able to do this. I have tried them and found the results were not very satisfactory. -----Original Message----- From: I.Tholley at lboro.ac.uk To: portaudio at music.columbia.edu Sent: Wed, Apr 14, 2010 6:05 am Subject: [Portaudio] extracting melodies or choruses Hi, I was wondering if anyone knows how to extract melodies or the chorus of a song from an .mp3 file using c++. Please help if you can. Thanks Ibs _______________________________________________ Portaudio mailing list Portaudio at music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From I.Tholley at lboro.ac.uk Wed Apr 14 20:02:17 2010 From: I.Tholley at lboro.ac.uk (I.Tholley at lboro.ac.uk) Date: Thu, 15 Apr 2010 01:02:17 +0100 Subject: [Portaudio] extracting melodies or choruses In-Reply-To: <8CCAA44AC8FAA1C-49C-13CAC@webmail-d070.sysops.aol.com> References: <8CCAA44AC8FAA1C-49C-13CAC@webmail-d070.sysops.aol.com> Message-ID: Is it possible for you to tell me which programs you used or where to find them? Thanks On Wed, 14 Apr 2010 19:52:28 -0400 ?c319chris at aol.com wrote: > > That's a very tall order. There are programs which claim >to be able to do this. I have tried them and found the >results were not very satisfactory. > > > > > > > > > -----Original Message----- >From: I.Tholley at lboro.ac.uk > To: portaudio at music.columbia.edu > Sent: Wed, Apr 14, 2010 6:05 am > Subject: [Portaudio] extracting melodies or choruses > > > Hi, > > I was wondering if anyone knows how to extract melodies >or the chorus of a song from an .mp3 file using c++. > > Please help if you can. > > Thanks > Ibs > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > > From rossb-lists at audiomulch.com Thu Apr 15 00:49:17 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu, 15 Apr 2010 14:49:17 +1000 Subject: [Portaudio] Input Latency References: <8CCA804AC3AB4B8-12CC-1F957@webmail-m005.sysops.aol.com><039c01cadbaf$024d98c0$0f73a8c0@rossmacbook> <8CCA9E49FC1AA48-34D8-ADB0@webmail-d092.sysops.aol.com> Message-ID: <012001cadc57$0220f420$0f73a8c0@rossmacbook> >>>> My confusion arises from the fact that you have one parameter called "input latency" and another called framesperbuffer which is the fifth argument in pa_openstream. You're saying "input latency" controls the amount of buffering, so what does the "framesperbuffer" argument do? <<<< Assuming you're not using paFramesPerBufferUnspecified, frames per buffer is the size of the buffer passed to the callback -- that is the main purpose of the frames per buffer parameter -- it could be called callbackFramesPerBuffer -- it is intended as a user parameter which in a perfect world has very little to do with host-side buffer sizes -- in practice there are interactions, especially if you are trying to get lowest possible latency. If you are using paFramesPerBufferUnspecified then frames per buffer has little meaning but may be used as a hint to PA about internal buffer granularity in some implementations. I'm pretty sure this is discussed on the proposed changes page for paFramesPerBufferUnspecified. > A capture buffer has the opposite problem from a playback buffer -- it > doesn't "starve", it overflows, i.e. the data is coming in faster than the > system can handle it. In some cases yes. Actually, it can be either depending on the host API. For example in MME (which I was thinking of when I wrote the above), internally PA supplies scatter gather buffers to Windows... so it's quite possible to starve the OS of buffers to write into (which may result in an internal overflow). Ross. -----Original Message----- From: Ross Bencina To: Portaudio Mailing List Sent: Wed, Apr 14, 2010 1:46 am Subject: Re: [Portaudio] Input Latency Hi Chris When capturing audio, buffering works similarly to when outputting audio. In the capture case, you need to make sure the driver has enough empty space to write newly captured data -- ie you're queuing empty buffers to the driver to fill. You will always need to queue enough buffer space so that the driver doesn't starve. PaStreamInfo::inputLatency will control the amount of buffering -- if you don't use "enough" the driver will starve. But if I understand your question, I agree it is perhaps a little bit strange to call it "inputLatency"... Ross. _______________________________________________ Portaudio mailing list Portaudio at music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio From rossb-lists at audiomulch.com Thu Apr 15 00:55:33 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu, 15 Apr 2010 14:55:33 +1000 Subject: [Portaudio] extracting melodies or choruses References: <8CCAA44AC8FAA1C-49C-13CAC@webmail-d070.sysops.aol.com> Message-ID: <014201cadc57$e2859070$0f73a8c0@rossmacbook> > Is it possible for you to tell me which programs you used or where to find > them? This is a mailing list for audio software development using a specific software library for real-time audio i/o. I recommend you go to the Music-IR list and/or the music-dsp list for this kind of question. You could also try googling for "blind source separation" Ross. From ralph.irving at gmail.com Thu Apr 15 07:29:36 2010 From: ralph.irving at gmail.com (Ralph Irving) Date: Thu, 15 Apr 2010 07:29:36 -0400 (EDT) Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: <1271161272.4bc461b8eed07@mail.inbox.lv> References: <1271102081.4bc37a81b32ed@mail.inbox.lv> <1271161272.4bc461b8eed07@mail.inbox.lv> Message-ID: Thanks. I actually removed all that code to reduce my post. 2 is the value returned from Pa_GetDefaultOutputDevice() for the headphones. After updating to svn r1490 the next issue I've encountered is that the Win7 and greater if check at line 1907 of pa_win_wasapi.c fails with gcc 3.4.4 1907:if (GetWindowsVersion() & WINDOWS_7_SERVER2008R2_AND_UP) GetWindowsVersion() returns 2 but WINDOWS_7_SERVER2008R2_AND_UP evaluates to zero. 800:WINDOWS_7_SERVER2008R2_AND_UP = (1 << 2) If I remove the if statement from line 1907 I get the same 0x800401F0 error which is CO_E_NOTINITIALIZED according to MSN as my Vista test from from a few days ago. I added a couple additional debugging statements to the library and g_bCOMInitialized appears to be set. Here's the debug output on Win7pro 64-bit with the if at line 1907 removed. Any ideas? before paHostApiInitializers[0]. g_bCOMInitialized: 1 WASAPI: device idx: 00 WASAPI: --------------- WASAPI:0| name[Digital Audio (S/PDIF) (High Definition Audio Device)] WASAPI:0| form-factor[8] WASAPI:0| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} WASAPI: device idx: 01 WASAPI: --------------- WASAPI:1| name[Digital Audio (S/PDIF) (High Definition Audio Device)] WASAPI:1| form-factor[8] WASAPI:1| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} WASAPI: device idx: 02 WASAPI: --------------- WASAPI:2| name[Speakers (High Definition Audio Device)] WASAPI:2| form-factor[1] WASAPI:2| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} dwMajorVersion:6 dwMinorVersion:1 WASAPI: initialized ok after paHostApiInitializers[0]. GetWindowsVersion: 2 beg pSubStream->period:29025.000000 end pSubStream->period:30000.000000 WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2063}] WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2294}] WASAPI ERROR PAERROR: -9996 : Invalid device [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2298}] output_thread: PortAudio error1: Invalid device Regards, Ralphy. On Tue, 13 Apr 2010, Dmitry Kostjuchenko wrote: > Hi Ralphy, > > Do not use 'WASAPI: device i: 2' id as device id for your parameters for Pa_OpenStream call, 2 here is internal for > WASAPI only, use PA methods to get correct device id. > > For that you shall have a kind of for loop and check there for API type, then if it is Input or Output device (using > channels != 0 parameter for example). > > Regards, > Dmitry. > > Quoting ralph.irving at gmail.com: >> Thanks Dmitry. > >> Am I not actually trying to opening id 2 the headphones in the Win7 >> example? > >>> WASAPI: device i: 2 >>> WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 >>> WASAPI: initialized okafter paHostApiInitializers[0]. >>> slimaudio_output_init: PortAudio initialized >>> Using audio device index: 2 >>> paDeviceInfo->deviceid 2 >>> paDeviceInfo->maxOutputChannels 2 > >> My bad for the Vista example, I'll retest it later today. > >> Ralphy > > >> On Mon, 12 Apr 2010, Dmitry Kostjuchenko wrote: > >>> Hi Ralphy! > >>> The compiler is not a problem for WASAPI, it does not have dependencies similar to ASIO. > >>> From the log you showed I see no output devices. WASAPI shows just SPDIF HDA which is actually an Input >>> device (capturing). > >>> see: Digital Audio (S/PDIF) (High Definition Audio Device)] (form-factor: 8) > >>> For both OSes. > >>> Thus you can't open them for Output. > >>> Regards, >>> Dmitry. > >>> Quoting ralph.irving at gmail.com: >>>> I'm having a problem opening any WASAPI device on Vista 32-bit and Win7Pro >>>> 64-bit using svn r1485 of portaudio. I'm using the 32-bit mingw gcc >>>> compiler from cygwin 2.693. > >>>> $ gcc -mno-cygwin --version >>>> gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) >>>> Copyright (C) 2004 Free Software Foundation, Inc. > >>>> I configured portaudio using these options. >>>> $ CFLAGS="-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -O2 \ >>>> -mno-cygwin -march=i686 -mtune=pentium4" CPPFLAGS="$(CFLAGS)" \ >>>> ./configure --with-host_os=mingw --with-winapi=wasapi \ >>>> --without-jack --enable-shared=no --enable-debug-output=yes > >>>> Here is the debug output from libportaudio, and my Win32 console >>>> application. I'm thinking that this might be a similar issue to Frank >>>> Lichtner's ASIO MinGW4 compiler code generation between gcc 3 and 4. I >>>> hoping to not have to move my project to the MSys/MinGW compiler tools >>>> just to use WASAPI in my application. > >>>> Win7Pro 64-bit: > >>>> before paHostApiInitializers[0]. >>>> WASAPI: device i: 0 >>>> WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] > >>>> WASAPI: device i: 1 >>>> WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] >>>> form-factor: 8 >>>> WASAPI: device i: 2 >>>> WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 >>>> WASAPI: initialized okafter paHostApiInitializers[0]. >>>> slimaudio_output_init: PortAudio initialized >>>> Using audio device index: 2 >>>> paDeviceInfo->deviceid 2 >>>> paDeviceInfo->maxOutputChannels 2 >>>> paDeviceInfo->defaultHighOutputLatency 0 >>>> paDeviceInfo->defaultLowhOutputLatency 0 >>>> paDeviceInfo->defaultSampleRate 44100.000000 >>>> WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD >>>> [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1867}] >>>> WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD >>>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2098}] >>>> WASAPI ERROR PAERROR: -9996 : Invalid device >>>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2102}] >>>> output_thread: PortAudio error1: Invalid device > >>>> Vista 32-bit: > >>>> before paHostApiInitializers[0]. >>>> WASAPI: device i: 0 >>>> WASAPI: device[Digital Output Device (SPDIF) (High Definition Audio >>>> Device)] >>>> form-factor: 8 >>>> WASAPI: initialized ok >>>> after paHostApiInitializers[0]. >>>> WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR >>>> [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1950}] >>>> WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR >>>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2181}] >>>> WASAPI ERROR PAERROR: -9996 : Invalid device >>>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2185}] >>>> output_thread: PortAudio error1: Invalid device > >>>> Here's the code snippet; > >>>> PaStreamParameters outputParameters; >>>> PaWasapiStreamInfo streamInfo; >>>> const PaDeviceInfo * paDeviceInfo; >>>> PaDeviceIndex output_device_id = 2; > >>>> DeviceInfo = Pa_GetDeviceInfo(output_device_id); >>>> /* Device is not stereo or better, abort */ >>>> if (paDeviceInfo->maxOutputChannels < 2) >>>> { >>>> printf("output_thread: PortAudio device does not support stereo audio.\n"); >>>> exit(-2); >>>> } > >>>> outputParameters.device = output_device_id; >>>> outputParameters.channelCount = 2; >>>> outputParameters.sampleFormat = paInt16; > >>>> streamInfo.size = sizeof(PaWasapiStreamInfo); >>>> streamInfo.hostApiType = paWASAPI; >>>> streamInfo.version = 1; >>>> streamInfo.flags = paWinWasapiExclusive; >>>> outputParameters.hostApiSpecificStreamInfo = &streamInfo; >>>> outputParameters.suggestedLatency = paDeviceInfo->defaultLowOutputLatency; > >>>> DEBUGF("paDeviceInfo->deviceid %d\n", >>>> outputParameters.device); >>>> DEBUGF("paDeviceInfo->maxOutputChannels %i\n", >>>> paDeviceInfo->maxOutputChannels); >>>> DEBUGF("paDeviceInfo->defaultHighOutputLatency %i\n", >>>> (int) paDeviceInfo->defaultHighOutputLatency); >>>> DEBUGF("paDeviceInfo->defaultLowhOutputLatency %i\n", >>>> (int) paDeviceInfo->defaultLowOutputLatency); >>>> DEBUGF("paDeviceInfo->defaultSampleRate %f\n", >>>> paDeviceInfo->defaultSampleRate); > >>>> err = Pa_OpenStream (&audio->pa_stream, NULL, &outputParameters, 44100.0, >>>> 0, paPrimeOutputBuffersUsingStreamCallback, pa_callback, audio); > >>>> if (err != paNoError) { >>>> printf("output_thread: PortAudio error1: %s\n", >>>> Pa_GetErrorText(err) ); >>>> exit(-1); >>>> } > >>>> Thanks, > >>>> Ralphy >>>> _______________________________________________ >>>> Portaudio mailing list >>>> Portaudio at music.columbia.edu >>>> http://music.columbia.edu/mailman/listinfo/portaudio > > > >>> iAuxSoft >>> ------------------ >>> [www.iauxsoft.com] > >>> _______________________________________________ >>> Portaudio mailing list >>> Portaudio at music.columbia.edu >>> http://music.columbia.edu/mailman/listinfo/portaudio > >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > > > > iAuxSoft > ------------------ > [www.iauxsoft.com] > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > From ebyers at fuse.net Thu Apr 15 09:31:15 2010 From: ebyers at fuse.net (Errol Byers) Date: Thu, 15 Apr 2010 09:31:15 -0400 Subject: [Portaudio] extracting melodies or choruses In-Reply-To: References: <8CCAA44AC8FAA1C-49C-13CAC@webmail-d070.sysops.aol.com> Message-ID: <2D1ABA79-9FC5-4D40-BBB7-1F7EAD5500BE@fuse.net> The subject of music composition and decomposition has always been a pet project of mine that I have never had enough time to pursue. I do remember attending a graphics conference a few years ago and seeing a demonstration of software that would continue a tune. You could play a few bars and it would continue the same rhythm and perform variations on the melody. It was very impressive. I do agree with c319chris that most software is not very satisfactory. This is probably not the forum for this discussion, so if you want to contact me directly, I would be glad to share any info that I have. Errol Byers On Apr 14, 2010, at 8:02 PM, I.Tholley at lboro.ac.uk wrote: > Is it possible for you to tell me which programs you used or where > to find them? > > Thanks > > > On Wed, 14 Apr 2010 19:52:28 -0400 > c319chris at aol.com wrote: >> That's a very tall order. There are programs which claim to be >> able to do this. I have tried them and found the results were not >> very satisfactory. >> -----Original Message----- >> From: I.Tholley at lboro.ac.uk >> To: portaudio at music.columbia.edu >> Sent: Wed, Apr 14, 2010 6:05 am >> Subject: [Portaudio] extracting melodies or choruses >> Hi, I was wondering if anyone knows how to extract melodies or the >> chorus of a song from an .mp3 file using c++. Please help if you >> can. Thanks Ibs _______________________________________________ >> Portaudio mailing list Portaudio at music.columbia.edu http:// >> music.columbia.edu/mailman/listinfo/portaudio > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio From I.Tholley at lboro.ac.uk Thu Apr 15 11:55:11 2010 From: I.Tholley at lboro.ac.uk (I.Tholley at lboro.ac.uk) Date: Thu, 15 Apr 2010 16:55:11 +0100 Subject: [Portaudio] extracting melodies or choruses In-Reply-To: <2D1ABA79-9FC5-4D40-BBB7-1F7EAD5500BE@fuse.net> References: <8CCAA44AC8FAA1C-49C-13CAC@webmail-d070.sysops.aol.com> <2D1ABA79-9FC5-4D40-BBB7-1F7EAD5500BE@fuse.net> Message-ID: Thank Errol and c319chris for your help. ibs On Thu, 15 Apr 2010 09:31:15 -0400 ?Errol Byers wrote: > The subject of music composition and decomposition has >always been a??pet project of mine that I have never had >enough time to pursue. I do??remember attending a >graphics conference a few years ago and seeing a > demonstration of software that would continue a tune. >You could play??a few bars and it would continue the same >rhythm and perform??variations on the melody. It was very >impressive. > I do agree with c319chris that most software is not very >satisfactory. > > This is probably not the forum for this discussion, so >if you want to??contact me directly, I would be glad to >share any info that I have. > > Errol Byers > > On Apr 14, 2010, at 8:02 PM, I.Tholley at lboro.ac.uk >wrote: > >> Is it possible for you to tell me which programs you >>used or where?? >> to find them? >> >> Thanks >> >> >> On Wed, 14 Apr 2010 19:52:28 -0400 >>??c319chris at aol.com wrote: >>> That's a very tall order. There are programs which claim >>>to be?? >>> able to do this. I have tried them and found the results >>>were not?? >>> very satisfactory. >>> -----Original Message----- >>> From: I.Tholley at lboro.ac.uk >>> To: portaudio at music.columbia.edu >>> Sent: Wed, Apr 14, 2010 6:05 am >>> Subject: [Portaudio] extracting melodies or choruses >>> Hi, I was wondering if anyone knows how to extract >>>melodies or the?? >>> chorus of a song from an .mp3 file using c++. Please >>>help if you?? >>> can. Thanks Ibs >>>_______________________________________________?? >>> Portaudio mailing list Portaudio at music.columbia.edu >>>http:// >>> music.columbia.edu/mailman/listinfo/portaudio >> >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio From bjorn at xowave.com Thu Apr 15 12:17:34 2010 From: bjorn at xowave.com (Bjorn Roche) Date: Thu, 15 Apr 2010 12:17:34 -0400 Subject: [Portaudio] extracting melodies or choruses In-Reply-To: References: <8CCAA44AC8FAA1C-49C-13CAC@webmail-d070.sysops.aol.com> <2D1ABA79-9FC5-4D40-BBB7-1F7EAD5500BE@fuse.net> Message-ID: <6DE8130E-140C-4E02-A807-5EDA864F2102@xowave.com> This is not really my area, but I recently had a conversation about these resources: http://www.music-ir.org/ http://www.music-ir.org/mirex/2009/index.php/Main_Page IIRC, their project is designed around the challenge of identifying cover songs. They do music Information retrieval, though you may be more interested in feature extraction, which is closely related, if not the same thing depending on who you ask. A good forum might be either there (hosted by IRCAM) or the music-dsp list. bjorn On Apr 15, 2010, at 11:55 AM, I.Tholley at lboro.ac.uk wrote: > Thank Errol and c319chris for your help. > > ibs > > > On Thu, 15 Apr 2010 09:31:15 -0400 > Errol Byers wrote: >> The subject of music composition and decomposition has always been >> a pet project of mine that I have never had enough time to pursue. >> I do remember attending a graphics conference a few years ago and >> seeing a demonstration of software that would continue a tune. You >> could play a few bars and it would continue the same rhythm and >> perform variations on the melody. It was very impressive. >> I do agree with c319chris that most software is not very >> satisfactory. >> This is probably not the forum for this discussion, so if you want >> to contact me directly, I would be glad to share any info that I >> have. >> Errol Byers >> On Apr 14, 2010, at 8:02 PM, I.Tholley at lboro.ac.uk wrote: >>> Is it possible for you to tell me which programs you used or where >>> to find them? >>> >>> Thanks >>> >>> >>> On Wed, 14 Apr 2010 19:52:28 -0400 >>> c319chris at aol.com wrote: >>>> That's a very tall order. There are programs which claim to be >>>> able to do this. I have tried them and found the results were not >>>> very satisfactory. >>>> -----Original Message----- >>>> From: I.Tholley at lboro.ac.uk >>>> To: portaudio at music.columbia.edu >>>> Sent: Wed, Apr 14, 2010 6:05 am >>>> Subject: [Portaudio] extracting melodies or choruses >>>> Hi, I was wondering if anyone knows how to extract melodies or the >>>> chorus of a song from an .mp3 file using c++. Please help if you >>>> can. Thanks Ibs _______________________________________________ >>>> Portaudio mailing list Portaudio at music.columbia.edu http:// >>>> music.columbia.edu/mailman/listinfo/portaudio >>> >>> _______________________________________________ >>> Portaudio mailing list >>> Portaudio at music.columbia.edu >>> http://music.columbia.edu/mailman/listinfo/portaudio >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio ----------------------------- Bjorn Roche XO Wave Digital Audio Production and Post-Production Software http://www.xowave.com http://blog.bjornroche.com http://myspace.com/xowave From dmitrykos at inbox.lv Thu Apr 15 13:28:50 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Thu, 15 Apr 2010 20:28:50 +0300 Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: References: <1271102081.4bc37a81b32ed@mail.inbox.lv> <1271161272.4bc461b8eed07@mail.inbox.lv> Message-ID: <1271352530.4bc74cd27c492@mail.inbox.lv> Hi Ralphy, 1) Thank you very much for reporting that Windows 7+ version detection was broken, I fixed it (check latest SVN commit); 2) I finally recalled the root of CO_E_NOTINITIALIZED as we recently were messing around it: reason: * CO_E_NOTINITIALIZED: you probably have multithreaded application, PA was initialized in one/or main thread, and Pa_OpenStream you call from another. what happens: * during Pa_Initialize call CoCreate() is called but to create WASAPI audio client you must operate from the same thread were CoCreate() was called, or you get CO_E_NOTINITIALIZED. how to resolve: * try calling all PA functions from the same thread were Pa_Initialize was called, PA is not protected from race- conditions which may happen if you call varios PA functions from multiple threads. Organize thread event queue and do everything from it, it is the best solution for MT apps. If such solution is difficult to achieve: 1) you must protect calls to PA with external global mutex; 2) call CoCreate() before Pa_OpenStream (in WASAPI case) and this call must be matched with CoUninitialize in the same thread when you close stream with Pa_CloseStream, or you leak system resources; 3) Please remember to call Pa_Terminate from the same thread where Pa_Initialize was called!!! (I probably have to put assertion in debug mode and console warning in release if it is not so...). I could put CoCreate in WASAPI's OpenStream but then I do not know if user closes stream from the same thread, so we better fail to improve application design rather than produce leaks and misbehavior. Could you please update from SVN, check how it goes in your app, and notify me. I would appreciate that. Best regards, Dmitry. Quoting Ralph Irving : > Thanks. I actually removed all that code to reduce my post. 2 is the > value returned from Pa_GetDefaultOutputDevice() for the headphones. > After updating to svn r1490 the next issue I've encountered is that the > Win7 and greater if check at line 1907 of pa_win_wasapi.c fails with gcc > 3.4.4 > 1907:if (GetWindowsVersion() & WINDOWS_7_SERVER2008R2_AND_UP) > GetWindowsVersion() returns 2 but WINDOWS_7_SERVER2008R2_AND_UP > evaluates to zero. > 800:WINDOWS_7_SERVER2008R2_AND_UP = (1 << 2) > If I remove the if statement from line 1907 I get the same 0x800401F0 > error which is CO_E_NOTINITIALIZED according to MSN as my Vista test from > from a few days ago. > I added a couple additional debugging statements to the library and > g_bCOMInitialized appears to be set. Here's the debug output on Win7pro > 64-bit with the if at line 1907 removed. Any ideas? > before paHostApiInitializers[0]. > g_bCOMInitialized: 1 > WASAPI: device idx: 00 > WASAPI: --------------- > WASAPI:0| name[Digital Audio (S/PDIF) (High Definition Audio Device)] > WASAPI:0| form-factor[8] > WASAPI:0| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} > WASAPI: device idx: 01 > WASAPI: --------------- > WASAPI:1| name[Digital Audio (S/PDIF) (High Definition Audio Device)] > WASAPI:1| form-factor[8] > WASAPI:1| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} > WASAPI: device idx: 02 > WASAPI: --------------- > WASAPI:2| name[Speakers (High Definition Audio Device)] > WASAPI:2| form-factor[1] > WASAPI:2| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} > dwMajorVersion:6 dwMinorVersion:1 > WASAPI: initialized ok > after paHostApiInitializers[0]. > GetWindowsVersion: 2 > beg pSubStream->period:29025.000000 > end pSubStream->period:30000.000000 > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2063}] > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2294}] > WASAPI ERROR PAERROR: -9996 : Invalid device > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2298}] > output_thread: PortAudio error1: Invalid device > Regards, > Ralphy. > On Tue, 13 Apr 2010, Dmitry Kostjuchenko wrote: > > Hi Ralphy, > > Do not use 'WASAPI: device i: 2' id as device id for your parameters for Pa_OpenStream call, 2 here is internal for > > WASAPI only, use PA methods to get correct device id. > > For that you shall have a kind of for loop and check there for API type, then if it is Input or Output device (using > > channels != 0 parameter for example). > > Regards, > > Dmitry. > > Quoting ralph.irving at gmail.com: > > > Thanks Dmitry. > > > Am I not actually trying to opening id 2 the headphones in the Win7 > > > example? > > > > WASAPI: device i: 2 > > > > WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 > > > > WASAPI: initialized okafter paHostApiInitializers[0]. > > > > slimaudio_output_init: PortAudio initialized > > > > Using audio device index: 2 > > > > paDeviceInfo->deviceid 2 > > > > paDeviceInfo->maxOutputChannels 2 > > > My bad for the Vista example, I'll retest it later today. > > > Ralphy > > > On Mon, 12 Apr 2010, Dmitry Kostjuchenko wrote: > > > > Hi Ralphy! > > > > The compiler is not a problem for WASAPI, it does not have dependencies similar to ASIO. > > > > From the log you showed I see no output devices. WASAPI shows just SPDIF HDA which is actually an Input > > > > device (capturing). > > > > see: Digital Audio (S/PDIF) (High Definition Audio Device)] (form-factor: 8) > > > > For both OSes. > > > > Thus you can't open them for Output. > > > > Regards, > > > > Dmitry. > > > > Quoting ralph.irving at gmail.com: > > > > > I'm having a problem opening any WASAPI device on Vista 32-bit and Win7Pro > > > > > 64-bit using svn r1485 of portaudio. I'm using the 32-bit mingw gcc > > > > > compiler from cygwin 2.693. > > > > > $ gcc -mno-cygwin --version > > > > > gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > > > > Copyright (C) 2004 Free Software Foundation, Inc. > > > > > I configured portaudio using these options. > > > > > $ CFLAGS="-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -O2 \ > > > > > -mno-cygwin -march=i686 -mtune=pentium4" CPPFLAGS="$(CFLAGS)" \ > > > > > ./configure --with-host_os=mingw --with-winapi=wasapi \ > > > > > --without-jack --enable-shared=no --enable-debug-output=yes > > > > > Here is the debug output from libportaudio, and my Win32 console > > > > > application. I'm thinking that this might be a similar issue to Frank > > > > > Lichtner's ASIO MinGW4 compiler code generation between gcc 3 and 4. I > > > > > hoping to not have to move my project to the MSys/MinGW compiler tools > > > > > just to use WASAPI in my application. > > > > > Win7Pro 64-bit: > > > > > before paHostApiInitializers[0]. > > > > > WASAPI: device i: 0 > > > > > WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] > > > > > WASAPI: device i: 1 > > > > > WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio Device)] > > > > > form-factor: 8 > > > > > WASAPI: device i: 2 > > > > > WASAPI: device[Speakers (High Definition Audio Device)] form-factor: 1 > > > > > WASAPI: initialized okafter paHostApiInitializers[0]. > > > > > slimaudio_output_init: PortAudio initialized > > > > > Using audio device index: 2 > > > > > paDeviceInfo->deviceid 2 > > > > > paDeviceInfo->maxOutputChannels 2 > > > > > paDeviceInfo->defaultHighOutputLatency 0 > > > > > paDeviceInfo->defaultLowhOutputLatency 0 > > > > > paDeviceInfo->defaultSampleRate 44100.000000 > > > > > WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD > > > > > [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1867}] > > > > > WASAPI ERROR HRESULT: 0x88890020 : AUDCLNT_E_INVALID_DEVICE_PERIOD > > > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2098}] > > > > > WASAPI ERROR PAERROR: -9996 : Invalid device > > > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2102}] > > > > > output_thread: PortAudio error1: Invalid device > > > > > Vista 32-bit: > > > > > before paHostApiInitializers[0]. > > > > > WASAPI: device i: 0 > > > > > WASAPI: device[Digital Output Device (SPDIF) (High Definition Audio > > > > > Device)] > > > > > form-factor: 8 > > > > > WASAPI: initialized ok > > > > > after paHostApiInitializers[0]. > > > > > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > > > > > [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1950}] > > > > > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > > > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2181}] > > > > > WASAPI ERROR PAERROR: -9996 : Invalid device > > > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: 2185}] > > > > > output_thread: PortAudio error1: Invalid device > > > > > Here's the code snippet; > > > > > PaStreamParameters outputParameters; > > > > > PaWasapiStreamInfo streamInfo; > > > > > const PaDeviceInfo * paDeviceInfo; > > > > > PaDeviceIndex output_device_id = 2; > > > > > DeviceInfo = Pa_GetDeviceInfo(output_device_id); > > > > > /* Device is not stereo or better, abort */ > > > > > if (paDeviceInfo->maxOutputChannels < 2) > > > > > { > > > > > printf("output_thread: PortAudio device does not support stereo audio.\n"); > > > > > exit(-2); > > > > > } > > > > > outputParameters.device = output_device_id; > > > > > outputParameters.channelCount = 2; > > > > > outputParameters.sampleFormat = paInt16; > > > > > streamInfo.size = sizeof(PaWasapiStreamInfo); > > > > > streamInfo.hostApiType = paWASAPI; > > > > > streamInfo.version = 1; > > > > > streamInfo.flags = paWinWasapiExclusive; > > > > > outputParameters.hostApiSpecificStreamInfo = &streamInfo; > > > > > outputParameters.suggestedLatency = paDeviceInfo->defaultLowOutputLatency; > > > > > DEBUGF("paDeviceInfo->deviceid %d\n", > > > > > outputParameters.device); > > > > > DEBUGF("paDeviceInfo->maxOutputChannels %i\n", > > > > > paDeviceInfo->maxOutputChannels); > > > > > DEBUGF("paDeviceInfo->defaultHighOutputLatency %i\n", > > > > > (int) paDeviceInfo->defaultHighOutputLatency); > > > > > DEBUGF("paDeviceInfo->defaultLowhOutputLatency %i\n", > > > > > (int) paDeviceInfo->defaultLowOutputLatency); > > > > > DEBUGF("paDeviceInfo->defaultSampleRate %f\n", > > > > > paDeviceInfo->defaultSampleRate); > > > > > err = Pa_OpenStream (&audio->pa_stream, NULL, &outputParameters, 44100.0, > > > > > 0, paPrimeOutputBuffersUsingStreamCallback, pa_callback, audio); > > > > > if (err != paNoError) { > > > > > printf("output_thread: PortAudio error1: %s\n", > > > > > Pa_GetErrorText(err) ); > > > > > exit(-1); > > > > > } > > > > > Thanks, > > > > > Ralphy > > > > > _______________________________________________ > > > > > Portaudio mailing list > > > > > Portaudio at music.columbia.edu > > > > > http://music.columbia.edu/mailman/listinfo/portaudio > > > > iAuxSoft > > > > ------------------ > > > > [www.iauxsoft.com] > > > > _______________________________________________ > > > > Portaudio mailing list > > > > Portaudio at music.columbia.edu > > > > http://music.columbia.edu/mailman/listinfo/portaudio > > > _______________________________________________ > > > Portaudio mailing list > > > Portaudio at music.columbia.edu > > > http://music.columbia.edu/mailman/listinfo/portaudio > > iAuxSoft > > ------------------ > > [www.iauxsoft.com] > > _______________________________________________ > > Portaudio mailing list > > Portaudio at music.columbia.edu > > http://music.columbia.edu/mailman/listinfo/portaudio > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] From dmitrykos at inbox.lv Thu Apr 15 13:45:48 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Thu, 15 Apr 2010 20:45:48 +0300 Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: <1271352530.4bc74cd27c492@mail.inbox.lv> References: <1271102081.4bc37a81b32ed@mail.inbox.lv> <1271161272.4bc461b8eed07@mail.inbox.lv> <1271352530.4bc74cd27c492@mail.inbox.lv> Message-ID: <1271353548.4bc750ccb0ef6@mail.inbox.lv> Sorry, I mistyped: assume CoCreate mentioning in my message as CoInitialize. Quoting "Dmitry Kostjuchenko" : > Hi Ralphy, > > 1) Thank you very much for reporting that Windows 7+ version detection > was broken, I fixed it (check latest SVN > commit); > 2) I finally recalled the root of CO_E_NOTINITIALIZED as we recently were > messing around it: > > reason: > * CO_E_NOTINITIALIZED: you probably have multithreaded application, PA > was initialized in one/or main thread, > and Pa_OpenStream you call from another. > > what happens: > * during Pa_Initialize call CoCreate() is called but to create WASAPI > audio client you must operate from the same > thread were CoCreate() was called, or you get CO_E_NOTINITIALIZED. > > how to resolve: > * try calling all PA functions from the same thread were Pa_Initialize > was called, PA is not protected from race- > conditions which may happen if you call varios PA functions from multiple > threads. Organize thread event queue > and do everything from it, it is the best solution for MT apps. > If such solution is difficult to achieve: > 1) you must protect calls to PA with external global mutex; > 2) call CoCreate() before Pa_OpenStream (in WASAPI case) and this call > must be matched with CoUninitialize in > the same thread when you close stream with Pa_CloseStream, or you leak > system resources; > 3) Please remember to call Pa_Terminate from the same thread where > Pa_Initialize was called!!! (I probably have to > put assertion in debug mode and console warning in release if it is not > so...). > > I could put CoCreate in WASAPI's OpenStream but then I do not know if > user closes stream from the same thread, > so we better fail to improve application design rather than produce leaks > and misbehavior. > > Could you please update from SVN, check how it goes in your app, and > notify me. I would appreciate that. > > Best regards, > Dmitry. > > Quoting Ralph Irving : > > Thanks. I actually removed all that code to reduce my post. 2 is the > > value returned from Pa_GetDefaultOutputDevice() for the headphones. > > > After updating to svn r1490 the next issue I've encountered is that the > > Win7 and greater if check at line 1907 of pa_win_wasapi.c fails with > gcc > > 3.4.4 > > > 1907:if (GetWindowsVersion() & WINDOWS_7_SERVER2008R2_AND_UP) > > > GetWindowsVersion() returns 2 but WINDOWS_7_SERVER2008R2_AND_UP > > evaluates to zero. > > > 800:WINDOWS_7_SERVER2008R2_AND_UP = (1 << 2) > > > If I remove the if statement from line 1907 I get the same 0x800401F0 > > error which is CO_E_NOTINITIALIZED according to MSN as my Vista test > from > > from a few days ago. > > > I added a couple additional debugging statements to the library and > > g_bCOMInitialized appears to be set. Here's the debug output on Win7pro > > 64-bit with the if at line 1907 removed. Any ideas? > > > before paHostApiInitializers[0]. > > g_bCOMInitialized: 1 > > WASAPI: device idx: 00 > > WASAPI: --------------- > > WASAPI:0| name[Digital Audio (S/PDIF) (High Definition Audio Device)] > > WASAPI:0| form-factor[8] > > WASAPI:0| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} > > WASAPI: device idx: 01 > > WASAPI: --------------- > > WASAPI:1| name[Digital Audio (S/PDIF) (High Definition Audio Device)] > > WASAPI:1| form-factor[8] > > WASAPI:1| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} > > WASAPI: device idx: 02 > > WASAPI: --------------- > > WASAPI:2| name[Speakers (High Definition Audio Device)] > > WASAPI:2| form-factor[1] > > WASAPI:2| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} > > dwMajorVersion:6 dwMinorVersion:1 > > WASAPI: initialized ok > > after paHostApiInitializers[0]. > > GetWindowsVersion: 2 > > beg pSubStream->period:29025.000000 > > end pSubStream->period:30000.000000 > > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > > [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c > {LINE: 2063}] > > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: > 2294}] > > WASAPI ERROR PAERROR: -9996 : Invalid device > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: > 2298}] > > output_thread: PortAudio error1: Invalid device > > > Regards, > > > Ralphy. > > > On Tue, 13 Apr 2010, Dmitry Kostjuchenko wrote: > > > > Hi Ralphy, > > > > Do not use 'WASAPI: device i: 2' id as device id for your parameters > for Pa_OpenStream call, 2 here is internal > for > > > WASAPI only, use PA methods to get correct device id. > > > > For that you shall have a kind of for loop and check there for API > type, then if it is Input or Output device (using > > > channels != 0 parameter for example). > > > > Regards, > > > Dmitry. > > > > Quoting ralph.irving at gmail.com: > > > > Thanks Dmitry. > > > > > Am I not actually trying to opening id 2 the headphones in the Win7 > > > > example? > > > > > > WASAPI: device i: 2 > > > > > WASAPI: device[Speakers (High Definition Audio Device)] > form-factor: 1 > > > > > WASAPI: initialized okafter paHostApiInitializers[0]. > > > > > slimaudio_output_init: PortAudio initialized > > > > > Using audio device index: 2 > > > > > paDeviceInfo->deviceid 2 > > > > > paDeviceInfo->maxOutputChannels 2 > > > > > My bad for the Vista example, I'll retest it later today. > > > > > Ralphy > > > > > > On Mon, 12 Apr 2010, Dmitry Kostjuchenko wrote: > > > > > > Hi Ralphy! > > > > > > The compiler is not a problem for WASAPI, it does not have > dependencies similar to ASIO. > > > > > > From the log you showed I see no output devices. WASAPI shows > just SPDIF HDA which is actually an > Input > > > > > device (capturing). > > > > > > see: Digital Audio (S/PDIF) (High Definition Audio Device)] > (form-factor: 8) > > > > > > For both OSes. > > > > > > Thus you can't open them for Output. > > > > > > Regards, > > > > > Dmitry. > > > > > > Quoting ralph.irving at gmail.com: > > > > > > I'm having a problem opening any WASAPI device on Vista 32-bit > and Win7Pro > > > > > > 64-bit using svn r1485 of portaudio. I'm using the 32-bit mingw > gcc > > > > > > compiler from cygwin 2.693. > > > > > > > $ gcc -mno-cygwin --version > > > > > > gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > > > > > Copyright (C) 2004 Free Software Foundation, Inc. > > > > > > > I configured portaudio using these options. > > > > > > $ CFLAGS="-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -O2 \ > > > > > > -mno-cygwin -march=i686 -mtune=pentium4" CPPFLAGS="$(CFLAGS)" \ > > > > > > ./configure --with-host_os=mingw --with-winapi=wasapi \ > > > > > > --without-jack --enable-shared=no --enable-debug-output=yes > > > > > > > Here is the debug output from libportaudio, and my Win32 > console > > > > > > application. I'm thinking that this might be a similar issue to > Frank > > > > > > Lichtner's ASIO MinGW4 compiler code generation between gcc 3 > and 4. I > > > > > > hoping to not have to move my project to the MSys/MinGW > compiler tools > > > > > > just to use WASAPI in my application. > > > > > > > Win7Pro 64-bit: > > > > > > > before paHostApiInitializers[0]. > > > > > > WASAPI: device i: 0 > > > > > > WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio > Device)] > > > > > > > WASAPI: device i: 1 > > > > > > WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio > Device)] > > > > > > form-factor: 8 > > > > > > WASAPI: device i: 2 > > > > > > WASAPI: device[Speakers (High Definition Audio Device)] > form-factor: 1 > > > > > > WASAPI: initialized okafter paHostApiInitializers[0]. > > > > > > slimaudio_output_init: PortAudio initialized > > > > > > Using audio device index: 2 > > > > > > paDeviceInfo->deviceid 2 > > > > > > paDeviceInfo->maxOutputChannels 2 > > > > > > paDeviceInfo->defaultHighOutputLatency 0 > > > > > > paDeviceInfo->defaultLowhOutputLatency 0 > > > > > > paDeviceInfo->defaultSampleRate 44100.000000 > > > > > > WASAPI ERROR HRESULT: 0x88890020 : > AUDCLNT_E_INVALID_DEVICE_PERIOD > > > > > > [FUNCTION: CreateAudioClient FILE: > src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1867}] > > > > > > WASAPI ERROR HRESULT: 0x88890020 : > AUDCLNT_E_INVALID_DEVICE_PERIOD > > > > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c > {LINE: 2098}] > > > > > > WASAPI ERROR PAERROR: -9996 : Invalid device > > > > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c > {LINE: 2102}] > > > > > > output_thread: PortAudio error1: Invalid device > > > > > > > Vista 32-bit: > > > > > > > before paHostApiInitializers[0]. > > > > > > WASAPI: device i: 0 > > > > > > WASAPI: device[Digital Output Device (SPDIF) (High Definition > Audio > > > > > > Device)] > > > > > > form-factor: 8 > > > > > > WASAPI: initialized ok > > > > > > after paHostApiInitializers[0]. > > > > > > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > > > > > > [FUNCTION: CreateAudioClient FILE: > src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1950}] > > > > > > WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR > > > > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c > {LINE: 2181}] > > > > > > WASAPI ERROR PAERROR: -9996 : Invalid device > > > > > > [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c > {LINE: 2185}] > > > > > > output_thread: PortAudio error1: Invalid device > > > > > > > Here's the code snippet; > > > > > > > PaStreamParameters outputParameters; > > > > > > PaWasapiStreamInfo streamInfo; > > > > > > const PaDeviceInfo * paDeviceInfo; > > > > > > PaDeviceIndex output_device_id = 2; > > > > > > > DeviceInfo = Pa_GetDeviceInfo(output_device_id); > > > > > > /* Device is not stereo or better, abort */ > > > > > > if (paDeviceInfo->maxOutputChannels < 2) > > > > > > { > > > > > > printf("output_thread: PortAudio device does not support stereo > audio.\n"); > > > > > > exit(-2); > > > > > > } > > > > > > > outputParameters.device = output_device_id; > > > > > > outputParameters.channelCount = 2; > > > > > > outputParameters.sampleFormat = paInt16; > > > > > > > streamInfo.size = sizeof(PaWasapiStreamInfo); > > > > > > streamInfo.hostApiType = paWASAPI; > > > > > > streamInfo.version = 1; > > > > > > streamInfo.flags = paWinWasapiExclusive; > > > > > > outputParameters.hostApiSpecificStreamInfo = &streamInfo; > > > > > > outputParameters.suggestedLatency = > paDeviceInfo->defaultLowOutputLatency; > > > > > > > DEBUGF("paDeviceInfo->deviceid %d\n", > > > > > > outputParameters.device); > > > > > > DEBUGF("paDeviceInfo->maxOutputChannels %i\n", > > > > > > paDeviceInfo->maxOutputChannels); > > > > > > DEBUGF("paDeviceInfo->defaultHighOutputLatency %i\n", > > > > > > (int) paDeviceInfo->defaultHighOutputLatency); > > > > > > DEBUGF("paDeviceInfo->defaultLowhOutputLatency %i\n", > > > > > > (int) paDeviceInfo->defaultLowOutputLatency); > > > > > > DEBUGF("paDeviceInfo->defaultSampleRate %f\n", > > > > > > paDeviceInfo->defaultSampleRate); > > > > > > > err = Pa_OpenStream (&audio->pa_stream, NULL, > &outputParameters, 44100.0, > > > > > > 0, paPrimeOutputBuffersUsingStreamCallback, pa_callback, > audio); > > > > > > > if (err != paNoError) { > > > > > > printf("output_thread: PortAudio error1: %s\n", > > > > > > Pa_GetErrorText(err) ); > > > > > > exit(-1); > > > > > > } > > > > > > > Thanks, > > > > > > > Ralphy > > > > > > _______________________________________________ > > > > > > Portaudio mailing list > > > > > > Portaudio at music.columbia.edu > > > > > > http://music.columbia.edu/mailman/listinfo/portaudio > > > > > > > > iAuxSoft > > > > > ------------------ > > > > > [www.iauxsoft.com] > > > > > > _______________________________________________ > > > > > Portaudio mailing list > > > > > Portaudio at music.columbia.edu > > > > > http://music.columbia.edu/mailman/listinfo/portaudio > > > > > _______________________________________________ > > > > Portaudio mailing list > > > > Portaudio at music.columbia.edu > > > > http://music.columbia.edu/mailman/listinfo/portaudio > > > > > > iAuxSoft > > > ------------------ > > > [www.iauxsoft.com] > > > > _______________________________________________ > > > Portaudio mailing list > > > Portaudio at music.columbia.edu > > > http://music.columbia.edu/mailman/listinfo/portaudio > > > _______________________________________________ > > Portaudio mailing list > > Portaudio at music.columbia.edu > > http://music.columbia.edu/mailman/listinfo/portaudio > > > > iAuxSoft > ------------------ > [www.iauxsoft.com] > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] From ralph.irving at gmail.com Fri Apr 16 07:37:32 2010 From: ralph.irving at gmail.com (Ralph Irving) Date: Fri, 16 Apr 2010 07:37:32 -0400 (EDT) Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: <1271353548.4bc750ccb0ef6@mail.inbox.lv> References: <1271102081.4bc37a81b32ed@mail.inbox.lv> <1271161272.4bc461b8eed07@mail.inbox.lv> <1271352530.4bc74cd27c492@mail.inbox.lv> <1271353548.4bc750ccb0ef6@mail.inbox.lv> Message-ID: Dmitry, My app is multithreaded and I have one thread, not the main one, for all Pa functions. After updating to SVN r1493 the Win7 check is working. I had to add a call to CoInitializeEx before Pa_OpenStream and a call to CoUninitialize after Pa_CloseStream in my Pa thread to avoid the CO_E_NOTINITIALIZED error. My app is currently streaming audio as I write this. Still need to test it with Vista. Thank-you for your help. Ralphy. On Thu, 15 Apr 2010, Dmitry Kostjuchenko wrote: > Sorry, I mistyped: assume CoCreate mentioning in my message as CoInitialize. > > Quoting "Dmitry Kostjuchenko" : >> Hi Ralphy, >> >> 1) Thank you very much for reporting that Windows 7+ version detection >> was broken, I fixed it (check latest SVN >> commit); >> 2) I finally recalled the root of CO_E_NOTINITIALIZED as we recently were >> messing around it: >> >> reason: >> * CO_E_NOTINITIALIZED: you probably have multithreaded application, PA >> was initialized in one/or main thread, >> and Pa_OpenStream you call from another. >> >> what happens: >> * during Pa_Initialize call CoCreate() is called but to create WASAPI >> audio client you must operate from the same >> thread were CoCreate() was called, or you get CO_E_NOTINITIALIZED. >> >> how to resolve: >> * try calling all PA functions from the same thread were Pa_Initialize >> was called, PA is not protected from race- >> conditions which may happen if you call varios PA functions from multiple >> threads. Organize thread event queue >> and do everything from it, it is the best solution for MT apps. >> If such solution is difficult to achieve: >> 1) you must protect calls to PA with external global mutex; >> 2) call CoCreate() before Pa_OpenStream (in WASAPI case) and this call >> must be matched with CoUninitialize in >> the same thread when you close stream with Pa_CloseStream, or you leak >> system resources; >> 3) Please remember to call Pa_Terminate from the same thread where >> Pa_Initialize was called!!! (I probably have to >> put assertion in debug mode and console warning in release if it is not >> so...). >> >> I could put CoCreate in WASAPI's OpenStream but then I do not know if >> user closes stream from the same thread, >> so we better fail to improve application design rather than produce leaks >> and misbehavior. >> >> Could you please update from SVN, check how it goes in your app, and >> notify me. I would appreciate that. >> >> Best regards, >> Dmitry. >> >> Quoting Ralph Irving : >>> Thanks. I actually removed all that code to reduce my post. 2 is the >>> value returned from Pa_GetDefaultOutputDevice() for the headphones. >> >>> After updating to svn r1490 the next issue I've encountered is that the >>> Win7 and greater if check at line 1907 of pa_win_wasapi.c fails with >> gcc >>> 3.4.4 >> >>> 1907:if (GetWindowsVersion() & WINDOWS_7_SERVER2008R2_AND_UP) >> >>> GetWindowsVersion() returns 2 but WINDOWS_7_SERVER2008R2_AND_UP >>> evaluates to zero. >> >>> 800:WINDOWS_7_SERVER2008R2_AND_UP = (1 << 2) >> >>> If I remove the if statement from line 1907 I get the same 0x800401F0 >>> error which is CO_E_NOTINITIALIZED according to MSN as my Vista test >> from >>> from a few days ago. >> >>> I added a couple additional debugging statements to the library and >>> g_bCOMInitialized appears to be set. Here's the debug output on Win7pro >>> 64-bit with the if at line 1907 removed. Any ideas? >> >>> before paHostApiInitializers[0]. >>> g_bCOMInitialized: 1 >>> WASAPI: device idx: 00 >>> WASAPI: --------------- >>> WASAPI:0| name[Digital Audio (S/PDIF) (High Definition Audio Device)] >>> WASAPI:0| form-factor[8] >>> WASAPI:0| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} >>> WASAPI: device idx: 01 >>> WASAPI: --------------- >>> WASAPI:1| name[Digital Audio (S/PDIF) (High Definition Audio Device)] >>> WASAPI:1| form-factor[8] >>> WASAPI:1| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} >>> WASAPI: device idx: 02 >>> WASAPI: --------------- >>> WASAPI:2| name[Speakers (High Definition Audio Device)] >>> WASAPI:2| form-factor[1] >>> WASAPI:2| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]} >>> dwMajorVersion:6 dwMinorVersion:1 >>> WASAPI: initialized ok >>> after paHostApiInitializers[0]. >>> GetWindowsVersion: 2 >>> beg pSubStream->period:29025.000000 >>> end pSubStream->period:30000.000000 >>> WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR >>> [FUNCTION: CreateAudioClient FILE: src/hostapi/wasapi/pa_win_wasapi.c >> {LINE: 2063}] >>> WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR >>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: >> 2294}] >>> WASAPI ERROR PAERROR: -9996 : Invalid device >>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c {LINE: >> 2298}] >>> output_thread: PortAudio error1: Invalid device >> >>> Regards, >> >>> Ralphy. >> >>> On Tue, 13 Apr 2010, Dmitry Kostjuchenko wrote: >> >>>> Hi Ralphy, >> >>>> Do not use 'WASAPI: device i: 2' id as device id for your parameters >> for Pa_OpenStream call, 2 here is internal >> for >>>> WASAPI only, use PA methods to get correct device id. >> >>>> For that you shall have a kind of for loop and check there for API >> type, then if it is Input or Output device (using >>>> channels != 0 parameter for example). >> >>>> Regards, >>>> Dmitry. >> >>>> Quoting ralph.irving at gmail.com: >>>>> Thanks Dmitry. >> >>>>> Am I not actually trying to opening id 2 the headphones in the Win7 >>>>> example? >> >>>>>> WASAPI: device i: 2 >>>>>> WASAPI: device[Speakers (High Definition Audio Device)] >> form-factor: 1 >>>>>> WASAPI: initialized okafter paHostApiInitializers[0]. >>>>>> slimaudio_output_init: PortAudio initialized >>>>>> Using audio device index: 2 >>>>>> paDeviceInfo->deviceid 2 >>>>>> paDeviceInfo->maxOutputChannels 2 >> >>>>> My bad for the Vista example, I'll retest it later today. >> >>>>> Ralphy >> >> >>>>> On Mon, 12 Apr 2010, Dmitry Kostjuchenko wrote: >> >>>>>> Hi Ralphy! >> >>>>>> The compiler is not a problem for WASAPI, it does not have >> dependencies similar to ASIO. >> >>>>>> From the log you showed I see no output devices. WASAPI shows >> just SPDIF HDA which is actually an >> Input >>>>>> device (capturing). >> >>>>>> see: Digital Audio (S/PDIF) (High Definition Audio Device)] >> (form-factor: 8) >> >>>>>> For both OSes. >> >>>>>> Thus you can't open them for Output. >> >>>>>> Regards, >>>>>> Dmitry. >> >>>>>> Quoting ralph.irving at gmail.com: >>>>>>> I'm having a problem opening any WASAPI device on Vista 32-bit >> and Win7Pro >>>>>>> 64-bit using svn r1485 of portaudio. I'm using the 32-bit mingw >> gcc >>>>>>> compiler from cygwin 2.693. >> >>>>>>> $ gcc -mno-cygwin --version >>>>>>> gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) >>>>>>> Copyright (C) 2004 Free Software Foundation, Inc. >> >>>>>>> I configured portaudio using these options. >>>>>>> $ CFLAGS="-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -O2 \ >>>>>>> -mno-cygwin -march=i686 -mtune=pentium4" CPPFLAGS="$(CFLAGS)" \ >>>>>>> ./configure --with-host_os=mingw --with-winapi=wasapi \ >>>>>>> --without-jack --enable-shared=no --enable-debug-output=yes >> >>>>>>> Here is the debug output from libportaudio, and my Win32 >> console >>>>>>> application. I'm thinking that this might be a similar issue to >> Frank >>>>>>> Lichtner's ASIO MinGW4 compiler code generation between gcc 3 >> and 4. I >>>>>>> hoping to not have to move my project to the MSys/MinGW >> compiler tools >>>>>>> just to use WASAPI in my application. >> >>>>>>> Win7Pro 64-bit: >> >>>>>>> before paHostApiInitializers[0]. >>>>>>> WASAPI: device i: 0 >>>>>>> WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio >> Device)] >> >>>>>>> WASAPI: device i: 1 >>>>>>> WASAPI: device[Digital Audio (S/PDIF) (High Definition Audio >> Device)] >>>>>>> form-factor: 8 >>>>>>> WASAPI: device i: 2 >>>>>>> WASAPI: device[Speakers (High Definition Audio Device)] >> form-factor: 1 >>>>>>> WASAPI: initialized okafter paHostApiInitializers[0]. >>>>>>> slimaudio_output_init: PortAudio initialized >>>>>>> Using audio device index: 2 >>>>>>> paDeviceInfo->deviceid 2 >>>>>>> paDeviceInfo->maxOutputChannels 2 >>>>>>> paDeviceInfo->defaultHighOutputLatency 0 >>>>>>> paDeviceInfo->defaultLowhOutputLatency 0 >>>>>>> paDeviceInfo->defaultSampleRate 44100.000000 >>>>>>> WASAPI ERROR HRESULT: 0x88890020 : >> AUDCLNT_E_INVALID_DEVICE_PERIOD >>>>>>> [FUNCTION: CreateAudioClient FILE: >> src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1867}] >>>>>>> WASAPI ERROR HRESULT: 0x88890020 : >> AUDCLNT_E_INVALID_DEVICE_PERIOD >>>>>>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c >> {LINE: 2098}] >>>>>>> WASAPI ERROR PAERROR: -9996 : Invalid device >>>>>>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c >> {LINE: 2102}] >>>>>>> output_thread: PortAudio error1: Invalid device >> >>>>>>> Vista 32-bit: >> >>>>>>> before paHostApiInitializers[0]. >>>>>>> WASAPI: device i: 0 >>>>>>> WASAPI: device[Digital Output Device (SPDIF) (High Definition >> Audio >>>>>>> Device)] >>>>>>> form-factor: 8 >>>>>>> WASAPI: initialized ok >>>>>>> after paHostApiInitializers[0]. >>>>>>> WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR >>>>>>> [FUNCTION: CreateAudioClient FILE: >> src/hostapi/wasapi/pa_win_wasapi.c {LINE: 1950}] >>>>>>> WASAPI ERROR HRESULT: 0x800401F0 : UNKNOWN ERROR >>>>>>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c >> {LINE: 2181}] >>>>>>> WASAPI ERROR PAERROR: -9996 : Invalid device >>>>>>> [FUNCTION: OpenStream FILE: src/hostapi/wasapi/pa_win_wasapi.c >> {LINE: 2185}] >>>>>>> output_thread: PortAudio error1: Invalid device >> >>>>>>> Here's the code snippet; >> >>>>>>> PaStreamParameters outputParameters; >>>>>>> PaWasapiStreamInfo streamInfo; >>>>>>> const PaDeviceInfo * paDeviceInfo; >>>>>>> PaDeviceIndex output_device_id = 2; >> >>>>>>> DeviceInfo = Pa_GetDeviceInfo(output_device_id); >>>>>>> /* Device is not stereo or better, abort */ >>>>>>> if (paDeviceInfo->maxOutputChannels < 2) >>>>>>> { >>>>>>> printf("output_thread: PortAudio device does not support stereo >> audio.\n"); >>>>>>> exit(-2); >>>>>>> } >> >>>>>>> outputParameters.device = output_device_id; >>>>>>> outputParameters.channelCount = 2; >>>>>>> outputParameters.sampleFormat = paInt16; >> >>>>>>> streamInfo.size = sizeof(PaWasapiStreamInfo); >>>>>>> streamInfo.hostApiType = paWASAPI; >>>>>>> streamInfo.version = 1; >>>>>>> streamInfo.flags = paWinWasapiExclusive; >>>>>>> outputParameters.hostApiSpecificStreamInfo = &streamInfo; >>>>>>> outputParameters.suggestedLatency = >> paDeviceInfo->defaultLowOutputLatency; >> >>>>>>> DEBUGF("paDeviceInfo->deviceid %d\n", >>>>>>> outputParameters.device); >>>>>>> DEBUGF("paDeviceInfo->maxOutputChannels %i\n", >>>>>>> paDeviceInfo->maxOutputChannels); >>>>>>> DEBUGF("paDeviceInfo->defaultHighOutputLatency %i\n", >>>>>>> (int) paDeviceInfo->defaultHighOutputLatency); >>>>>>> DEBUGF("paDeviceInfo->defaultLowhOutputLatency %i\n", >>>>>>> (int) paDeviceInfo->defaultLowOutputLatency); >>>>>>> DEBUGF("paDeviceInfo->defaultSampleRate %f\n", >>>>>>> paDeviceInfo->defaultSampleRate); >> >>>>>>> err = Pa_OpenStream (&audio->pa_stream, NULL, >> &outputParameters, 44100.0, >>>>>>> 0, paPrimeOutputBuffersUsingStreamCallback, pa_callback, >> audio); >> >>>>>>> if (err != paNoError) { >>>>>>> printf("output_thread: PortAudio error1: %s\n", >>>>>>> Pa_GetErrorText(err) ); >>>>>>> exit(-1); >>>>>>> } >> >>>>>>> Thanks, >> >>>>>>> Ralphy >>>>>>> _______________________________________________ >>>>>>> Portaudio mailing list >>>>>>> Portaudio at music.columbia.edu >>>>>>> http://music.columbia.edu/mailman/listinfo/portaudio >> >> >> >>>>>> iAuxSoft >>>>>> ------------------ >>>>>> [www.iauxsoft.com] >> >>>>>> _______________________________________________ >>>>>> Portaudio mailing list >>>>>> Portaudio at music.columbia.edu >>>>>> http://music.columbia.edu/mailman/listinfo/portaudio >> >>>>> _______________________________________________ >>>>> Portaudio mailing list >>>>> Portaudio at music.columbia.edu >>>>> http://music.columbia.edu/mailman/listinfo/portaudio >> >> >> >>>> iAuxSoft >>>> ------------------ >>>> [www.iauxsoft.com] >> >>>> _______________________________________________ >>>> Portaudio mailing list >>>> Portaudio at music.columbia.edu >>>> http://music.columbia.edu/mailman/listinfo/portaudio >> >>> _______________________________________________ >>> Portaudio mailing list >>> Portaudio at music.columbia.edu >>> http://music.columbia.edu/mailman/listinfo/portaudio >> >> >> >> iAuxSoft >> ------------------ >> [www.iauxsoft.com] >> >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > > > iAuxSoft > ------------------ > [www.iauxsoft.com] > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > From dmitrykos at inbox.lv Fri Apr 16 09:40:48 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Fri, 16 Apr 2010 16:40:48 +0300 Subject: [Portaudio] Fwd: Re: WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error Message-ID: <1271425248.4bc868e035555@mail.inbox.lv> Ralphy, If you could call Pa_Initialize from this same thread (for example when you start it), then additional CoInitializeEx would not be needed. On this thread closure you will need just to run Pa_Terrminate, and you are done! Dmitry. Quoting Ralph Irving : > Dmitry, > My app is multithreaded and I have one thread, not the main one, for all > Pa functions. After updating to SVN r1493 the Win7 check is working. I > had to add a call to CoInitializeEx before Pa_OpenStream and a call to > CoUninitialize after Pa_CloseStream in my Pa thread to avoid the > CO_E_NOTINITIALIZED error. My app is currently streaming audio as I write > this. Still need to test it with Vista. > Thank-you for your help. > Ralphy. From johngavingraham at googlemail.com Sat Apr 17 14:13:23 2010 From: johngavingraham at googlemail.com (John Graham) Date: Sat, 17 Apr 2010 19:13:23 +0100 Subject: [Portaudio] MinGW Compilation Problem Message-ID: Hi there, I'm having a problem compiling PortAudio using MinGW (i686-pc-mingw, version 3.4.5). After an apparently successful `./configure', I get this when doing `make': src/hostapi/wmme/.libs/pa_win_wmme.o: In function `QueryFormatSupported': /usr/local/trip2/src/lib/portaudio/portaudio-19-mingw32/src/hostapi/wmme/pa_win_wmme.c:549: undefined reference to `_PaWin_InitializeWaveFormatExtensible' (as well as some more undefined references) I seem to be having the same problem as described here: http://music.columbia.edu/pipermail/portaudio/2007-September/007562.html However, the suggested solution (the patches here: http://music.columbia.edu/pipermail/portaudio/2007-September/007554.html) don't seem to work, and the result is exactly the same. One thing about the patches, though - the second is for the configure script after it's been configured, which seems a little weird. I couldn't apply it as most of it failed, but I don't think that should matter too much (right?). I'd be grateful if anybody has any suggestions? John G P.S. All I pass to the configure script is a --prefix and --host=i686-pc-mingw32, if that makes any difference... From ralph.irving at gmail.com Sun Apr 18 08:21:59 2010 From: ralph.irving at gmail.com (Ralph Irving) Date: Sun, 18 Apr 2010 08:21:59 -0400 (EDT) Subject: [Portaudio] Fwd: Re: WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: <1271425248.4bc868e035555@mail.inbox.lv> References: <1271425248.4bc868e035555@mail.inbox.lv> Message-ID: I really don't want to change the code just to "cleanly" support WASAPI. Direct Sound, ASIO, ALSA, OSS and Core Audio all worked with my current code before adding WASAPI support. I need to cleanup several threads and plan to incorporate your recommendation at that time. For now, I'm happy that it's working with the added calls for WASAPI. On Fri, 16 Apr 2010, Dmitry Kostjuchenko wrote: > Ralphy, > > If you could call Pa_Initialize from this same thread (for example when you start it), then additional CoInitializeEx > would not be needed. On this thread closure you will need just to run Pa_Terrminate, and you are done! > > Dmitry. > > Quoting Ralph Irving : >> Dmitry, > >> My app is multithreaded and I have one thread, not the main one, for all >> Pa functions. After updating to SVN r1493 the Win7 check is working. I >> had to add a call to CoInitializeEx before Pa_OpenStream and a call to >> CoUninitialize after Pa_CloseStream in my Pa thread to avoid the >> CO_E_NOTINITIALIZED error. My app is currently streaming audio as I write >> this. Still need to test it with Vista. > >> Thank-you for your help. > >> Ralphy. > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > From dmitrykos at inbox.lv Mon Apr 19 04:23:31 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Mon, 19 Apr 2010 11:23:31 +0300 Subject: [Portaudio] Fwd: Re: WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: References: <1271425248.4bc868e035555@mail.inbox.lv> Message-ID: <1271665411.4bcc13038df6d@mail.inbox.lv> Hi Ralph! Well it is not all just about WASAPI implementation. For example, PA's ASIO implementation also requires more stricter approach towards CoInitialize/Uninitialize pair, now it is relaxed and calls CoInitialize when you do OpenStream. DS interface has CoInitialize/Uninitialize similarly to WASAPI in PA Initialization phase, but I think Microsoft tweaked DS and calls CoInitialize internally thus it may explain why it always works. The same is with WMME which does it internally. May be Microsoft internally has more abilities to cleanup COM in such situations but using public API and messing with CoInitialize/Uninitialize wrong order will simply lead to Exception thrown to your application if CoUninitialize is wrongly called. For WASAPI Microsoft does not do any additional calls to CoInitialize and thus it can't work like DS/WMME or ASIO (which does CoInitialize additionally). I did not want to put additional calls CoInitialize intentionally, as then if user opens stream in one thread and closes from another it would cause thrown Exception from PortAudio side and it could be percieved as PortAudio side bug. So let's avoid such case! It is not PortAudio's specifics but Microsoft's COM model which must be strictly followed by application developers. ALSA/OSS/CoreAudio do not have similar concept so we talk only about Windows platform. Best regards, Dmitry. Quoting *Ralph Irving *: > I really don't want to change the code just to "cleanly" support > WASAPI. > Direct Sound, ASIO, ALSA, OSS and Core Audio all worked with my > current > code before adding WASAPI support. I need to cleanup several threads > and > plan to incorporate your recommendation at that time. For now, I'm > happy > that it's working with the added calls for WASAPI. > > On Fri, 16 Apr 2010, Dmitry Kostjuchenko wrote: >> Ralphy, >> >> If you could call Pa_Initialize from this same thread (for example >> when you start it), then additional CoInitializeEx >> would not be needed. On this thread closure you will need just to >> run Pa_Terrminate, and you are done! >> >> Dmitry. >> >> Quoting Ralph Irving : >>> Dmitry, >> >>> My app is multithreaded and I have one thread, not the main one, >>> for all >>> Pa functions. After updating to SVN r1493 the Win7 check is >>> working. I >>> had to add a call to CoInitializeEx before Pa_OpenStream and a >>> call to >>> CoUninitialize after Pa_CloseStream in my Pa thread to avoid the >>> CO_E_NOTINITIALIZED error. My app is currently streaming audio as >>> I write >>> this. Still need to test it with Vista. >> >>> Thank-you for your help. >> >>> Ralphy. >> >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Mon Apr 19 05:51:01 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Mon, 19 Apr 2010 19:51:01 +1000 Subject: [Portaudio] Fwd: Re: WASAPI AUDCLNT_E_INVALID_DEVICE_PERIODError References: <1271425248.4bc868e035555@mail.inbox.lv> <1271665411.4bcc13038df6d@mail.inbox.lv> Message-ID: <00ba01cadfa5$d2ca9490$0f73a8c0@rossmacbook> Hi Ralph, Dmitry I havn't been following this closely enough to understand exactly who thinks what, but there are some facts about PortAudio which bear repeating here: - Calling PA from more than one thread is unspecified. So just because some implementations work says nothing about what should work or that WASAPI is broken. - If you are going to call PA from multiple threads you have to wrap PA calls in a Mutex on all platforms (because PA has no internal protection from simultaneous access from multiple threads). - As Dmitry says, COM thread initialization must be performed for any thread when PA is using a COM based host API (*I agree, but see below for my thoughts on this). Taken together, the above points mean that if you want to use PA accross multiple threads you are outside spec and need to take necessary precautions. You cannot expect things to be very clean, there will be PA-implementation-specific and host-API specific interactions. *Personally I think it is inappropriate for a PA implementation to call CoInitialize, except perhaps from Pa_Initialize. I notice Phil re-added a call to CoInitialize to Pa_ASIO a couple of years ago. IMHO Initializing COM on a thread should be the caller's responsibility (otherwise (1) the time of COM initialization is non-deterministic and hence (2) undesirable COM interactions could ensue for apps that actually use COM -- for example if PA initializes COM with a different threading model before the App initializes it). Just my 2 cents Ross ----- Original Message ----- From: Dmitry Kostjuchenko To: Portaudio Mailing List Sent: Monday, April 19, 2010 6:23 PM Subject: Re: [Portaudio] Fwd: Re: WASAPI AUDCLNT_E_INVALID_DEVICE_PERIODError Hi Ralph! Well it is not all just about WASAPI implementation. For example, PA's ASIO implementation also requires more stricter approach towards CoInitialize/Uninitialize pair, now it is relaxed and calls CoInitialize when you do OpenStream. DS interface has CoInitialize/Uninitialize similarly to WASAPI in PA Initialization phase, but I think Microsoft tweaked DS and calls CoInitialize internally thus it may explain why it always works. The same is with WMME which does it internally. May be Microsoft internally has more abilities to cleanup COM in such situations but using public API and messing with CoInitialize/Uninitialize wrong order will simply lead to Exception thrown to your application if CoUninitialize is wrongly called. For WASAPI Microsoft does not do any additional calls to CoInitialize and thus it can't work like DS/WMME or ASIO (which does CoInitialize additionally). I did not want to put additional calls CoInitialize intentionally, as then if user opens stream in one thread and closes from another it would cause thrown Exception from PortAudio side and it could be percieved as PortAudio side bug. So let's avoid such case! It is not PortAudio's specifics but Microsoft's COM model which must be strictly followed by application developers. ALSA/OSS/CoreAudio do not have similar concept so we talk only about Windows platform. Best regards, Dmitry. Quoting Ralph Irving : I really don't want to change the code just to "cleanly" support WASAPI. Direct Sound, ASIO, ALSA, OSS and Core Audio all worked with my current code before adding WASAPI support. I need to cleanup several threads and plan to incorporate your recommendation at that time. For now, I'm happy that it's working with the added calls for WASAPI. On Fri, 16 Apr 2010, Dmitry Kostjuchenko wrote: Ralphy, If you could call Pa_Initialize from this same thread (for example when you start it), then additional CoInitializeEx would not be needed. On this thread closure you will need just to run Pa_Terrminate, and you are done! Dmitry. Quoting Ralph Irving : Dmitry, My app is multithreaded and I have one thread, not the main one, for all Pa functions. After updating to SVN r1493 the Win7 check is working. I had to add a call to CoInitializeEx before Pa_OpenStream and a call to CoUninitialize after Pa_CloseStream in my Pa thread to avoid the CO_E_NOTINITIALIZED error. My app is currently streaming audio as I write this. Still need to test it with Vista. Thank-you for your help. Ralphy. _______________________________________________ Portaudio mailing list Portaudio at music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio _______________________________________________ Portaudio mailing list Portaudio at music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] _______________________________________________ Portaudio mailing list Portaudio at music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio From dmitrykos at inbox.lv Mon Apr 19 18:16:31 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Tue, 20 Apr 2010 01:16:31 +0300 Subject: [Portaudio] Fwd: Re: WASAPI AUDCLNT_E_INVALID_DEVICE_PERIODError In-Reply-To: <00ba01cadfa5$d2ca9490$0f73a8c0@rossmacbook> References: <1271425248.4bc868e035555@mail.inbox.lv> <1271665411.4bcc13038df6d@mail.inbox.lv> <00ba01cadfa5$d2ca9490$0f73a8c0@rossmacbook> Message-ID: <1271715391.4bccd63fcab94@mail.inbox.lv> Hi Ross, Yes, I completely agre that CoInitialize/CoUninitialize shall be run by Pa_Initialize/Pa_Terminate pair, and only. Actually was trying to explain that. This is Microsoft COM specifics and only user can determine the lifetime of the thread which operates with PA functions.  Ideally we could implement CurentThreadId checks in PA front functions and report warnings to console at least about different threads calling PA. Posix threads allow this to be done as well. I suspect there are many applications which may misuse PA in regards to multithreading. Dmitry. Quoting *Ross Bencina *: > Hi Ralph, Dmitry > > I havn't been following this closely enough to understand exactly > who thinks > what, but there are some facts about PortAudio which bear repeating > here: > > - Calling PA from more than one thread is unspecified. So just > because some > implementations work says nothing about what should work or that > WASAPI is > broken. > > - If you are going to call PA from multiple threads you have to wrap > PA > calls in a Mutex on all platforms (because PA has no internal > protection > from simultaneous access from multiple threads). > > - As Dmitry says, COM thread initialization must be performed for > any thread > when PA is using a COM based host API (*I agree, but see below for > my > thoughts on this). > > Taken together, the above points mean that if you want to use PA > accross > multiple threads you are outside spec and need to take necessary > precautions. You cannot expect things to be very clean, there will > be > PA-implementation-specific and host-API specific interactions. > > > *Personally I think it is inappropriate for a PA implementation to > call > CoInitialize, except perhaps from Pa_Initialize. I notice Phil > re-added a > call to CoInitialize to Pa_ASIO a couple of years ago. IMHO > Initializing COM > on a thread should be the caller's responsibility (otherwise (1) the > time of > COM initialization is non-deterministic and hence (2) undesirable > COM > interactions could ensue for apps that actually use COM -- for > example if PA > initializes COM with a different threading model before the App > initializes > it). > > Just my 2 cents > > Ross > > > > > > ----- Original Message ----- > From: Dmitry Kostjuchenko > To: Portaudio Mailing List > Sent: Monday, April 19, 2010 6:23 PM > Subject: Re: [Portaudio] Fwd: Re: WASAPI > AUDCLNT_E_INVALID_DEVICE_PERIODError > > > Hi Ralph! > > Well it is not all just about WASAPI implementation. > > For example, PA's ASIO implementation also requires more stricter > approach > towards CoInitialize/Uninitialize pair, now it is relaxed and calls > CoInitialize when you do OpenStream. DS interface has > CoInitialize/Uninitialize similarly to WASAPI in PA Initialization > phase, > but I think Microsoft tweaked DS and calls CoInitialize internally > thus it > may explain why it always works. The same is with WMME which does it > internally. > > May be Microsoft internally has more abilities to cleanup COM in > such > situations but using public API and messing with > CoInitialize/Uninitialize > wrong order will simply lead to Exception thrown to your application > if > CoUninitialize is wrongly called. > > For WASAPI Microsoft does not do any additional calls to > CoInitialize and > thus it can't work like DS/WMME or ASIO (which does CoInitialize > additionally). > > I did not want to put additional calls CoInitialize intentionally, > as then > if user opens stream in one thread and closes from another it would > cause > thrown Exception from PortAudio side and it could be percieved as > PortAudio > side bug. So let's avoid such case! It is not PortAudio's specifics > but > Microsoft's COM model which must be strictly followed by application > developers. > > ALSA/OSS/CoreAudio do not have similar concept so we talk only about > Windows > platform. > > Best regards, > Dmitry. > > Quoting Ralph Irving : > I really don't want to change the code just to "cleanly" support > WASAPI. > Direct Sound, ASIO, ALSA, OSS and Core Audio all worked with my > current > code before adding WASAPI support. I need to cleanup several threads > and > plan to incorporate your recommendation at that time. For now, I'm > happy > that it's working with the added calls for WASAPI. > > On Fri, 16 Apr 2010, Dmitry Kostjuchenko wrote: > > > Ralphy, > > If you could call Pa_Initialize from this same thread (for example > when you > start it), then additional CoInitializeEx > would not be needed. On this thread closure you will need just to > run > Pa_Terrminate, and you are done! > > Dmitry. > > Quoting Ralph Irving : > > Dmitry, > > > > My app is multithreaded and I have one thread, not the main one, for > all > Pa functions. After updating to SVN r1493 the Win7 check is working. > I > had to add a call to CoInitializeEx before Pa_OpenStream and a call > to > CoUninitialize after Pa_CloseStream in my Pa thread to avoid the > CO_E_NOTINITIALIZED error. My app is currently streaming audio as I > write > this. Still need to test it with Vista. > > > > Thank-you for your help. > > > > Ralphy. > > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > > > > > > iAuxSoft > ------------------ > [www.iauxsoft.com] > > > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio iAuxSoft ------------------ [www.iauxsoft.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Tue Apr 20 00:55:45 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Tue, 20 Apr 2010 14:55:45 +1000 Subject: [Portaudio] Fwd: Re: WASAPI AUDCLNT_E_INVALID_DEVICE_PERIODError References: <1271425248.4bc868e035555@mail.inbox.lv><1271665411.4bcc13038df6d@mail.inbox.lv><00ba01cadfa5$d2ca9490$0f73a8c0@rossmacbook> <1271715391.4bccd63fcab94@mail.inbox.lv> Message-ID: <008901cae045$be377070$0f73a8c0@rossmacbook> Hi Dmitry If we had an explicitly specified threading model we could have per-thread PA initialization. eg Pa_InitializeThread(), Pa_UninitializeThread() which could be used to portably initialize COM and would provide a clear synchronisation point for clients who need to manage their own COM initialziation. But, we don't have an explicit threading module. It would be nice to just make PA thread-safe but this is not a project I would want to undertake while there are other implementation shortcomings to be addressed -- especially since the hazards in introducing bugs seem to me much greater than the minor inconvenience of explicit mutual exclusion incurred at the moment. Ross. ----- Original Message ----- From: Dmitry Kostjuchenko To: Portaudio Mailing List Sent: Tuesday, April 20, 2010 8:16 AM Subject: Re: [Portaudio] Fwd: Re: WASAPI AUDCLNT_E_INVALID_DEVICE_PERIODError Hi Ross, Yes, I completely agre that CoInitialize/CoUninitialize shall be run by Pa_Initialize/Pa_Terminate pair, and only. Actually was trying to explain that. This is Microsoft COM specifics and only user can determine the lifetime of the thread which operates with PA functions. Ideally we could implement CurentThreadId checks in PA front functions and report warnings to console at least about different threads calling PA. Posix threads allow this to be done as well. I suspect there are many applications which may misuse PA in regards to multithreading. Dmitry. Quoting Ross Bencina : Hi Ralph, Dmitry I havn't been following this closely enough to understand exactly who thinks what, but there are some facts about PortAudio which bear repeating here: - Calling PA from more than one thread is unspecified. So just because some implementations work says nothing about what should work or that WASAPI is broken. - If you are going to call PA from multiple threads you have to wrap PA calls in a Mutex on all platforms (because PA has no internal protection from simultaneous access from multiple threads). - As Dmitry says, COM thread initialization must be performed for any thread when PA is using a COM based host API (*I agree, but see below for my thoughts on this). Taken together, the above points mean that if you want to use PA accross multiple threads you are outside spec and need to take necessary precautions. You cannot expect things to be very clean, there will be PA-implementation-specific and host-API specific interactions. *Personally I think it is inappropriate for a PA implementation to call CoInitialize, except perhaps from Pa_Initialize. I notice Phil re-added a call to CoInitialize to Pa_ASIO a couple of years ago. IMHO Initializing COM on a thread should be the caller's responsibility (otherwise (1) the time of COM initialization is non-deterministic and hence (2) undesirable COM interactions could ensue for apps that actually use COM -- for example if PA initializes COM with a different threading model before the App initializes it). Just my 2 cents Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Wed Apr 21 02:32:45 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 21 Apr 2010 16:32:45 +1000 Subject: [Portaudio] OSX 10.6 runLoop patch question Message-ID: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> Hi Guys I'm wondering what the following patch actually does for PA and CoreAudio behavior: "maccore: fixed MacOSX "Snow Leopard" 10.6+ deadlock on sample-rate change submitted by Olivier Tristan" http://www.portaudio.com/trac/changeset/1483 I've read the thread from February, but can anyone explain it in more detail? I have not yet pulled the above patch into my local copy of PA. I'm not currently using paMacCoreChangeDeviceParameters, but I'm wondering if it might fix another deadlock issue I have on Snow Leopard. I have a local modification here which improves PaStreamCallbackTimeInfo in CoreAudio (I havn't committed it because it is incomplete, but works for my cases). My mod calls AudioDeviceGetProperty to fetch kAudioDevicePropertyActualSampleRate and kAudioDevicePropertyLatency within the IOProc. One of the AudioDeviceGetProperty calls has started to intermittently deadlock on Snow Leopard when I open a standard file dialog and select different soundfiles (it looks like the dialog creates an AudioQueue and makes some changes to the HAL, for more detail see my post to the CoreAudio list http://lists.apple.com/archives/coreaudio-api/2010/Apr/msg00165.html). Do you think this is something that might be fixed by the runloop patch above? The deadlocks I'm seeing are intermittent so I'm kind of hoping to find out what's causing the problem rather than just updating with the patch, testing, and hoping for the best. Any thoughts? Thanks Ross. From o.tristan at ultimatesoundbank.com Wed Apr 21 03:59:03 2010 From: o.tristan at ultimatesoundbank.com (Olivier Tristan) Date: Wed, 21 Apr 2010 09:59:03 +0200 Subject: [Portaudio] OSX 10.6 runLoop patch question In-Reply-To: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> Message-ID: <4BCEB047.3070308@ultimatesoundbank.com> Hi, It fixes an issue related to notification from the HAL regarding properties modification. There is a change in the way 10.6 handles property listener thread and it didn't worked anymore. As you use properties too, I think it might fix your issue. HTH On 4/21/2010 8:32 AM, Ross Bencina wrote: > Hi Guys > > I'm wondering what the following patch actually does for PA and > CoreAudio behavior: > > "maccore: fixed MacOSX "Snow Leopard" 10.6+ deadlock on sample-rate > change submitted by Olivier Tristan" > http://www.portaudio.com/trac/changeset/1483 > > I've read the thread from February, but can anyone explain it in more > detail? > > I have not yet pulled the above patch into my local copy of PA. I'm > not currently using paMacCoreChangeDeviceParameters, but I'm wondering > if it might fix another deadlock issue I have on Snow Leopard. > > > I have a local modification here which improves > PaStreamCallbackTimeInfo in CoreAudio (I havn't committed it because > it is incomplete, but works for my cases). My mod calls > AudioDeviceGetProperty to fetch kAudioDevicePropertyActualSampleRate > and kAudioDevicePropertyLatency within the IOProc. One of the > AudioDeviceGetProperty calls has started to intermittently deadlock on > Snow Leopard when I open a standard file dialog and select different > soundfiles (it looks like the dialog creates an AudioQueue and makes > some changes to the HAL, for more detail see my post to the CoreAudio > list > http://lists.apple.com/archives/coreaudio-api/2010/Apr/msg00165.html). > > Do you think this is something that might be fixed by the runloop > patch above? The deadlocks I'm seeing are intermittent so I'm kind of > hoping to find out what's causing the problem rather than just > updating with the patch, testing, and hoping for the best. > > Any thoughts? > > Thanks > > Ross. > > > > > > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > -- Olivier Tristan Ultimate Sound Bank From rossb-lists at audiomulch.com Wed Apr 21 05:35:42 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 21 Apr 2010 19:35:42 +1000 Subject: [Portaudio] OSX 10.6 runLoop patch question References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> <4BCEB047.3070308@ultimatesoundbank.com> Message-ID: <000e01cae136$039217b0$0f73a8c0@rossmacbook> Hi Oliver Unfortunately it didn't fix my issue. > It fixes an issue related to notification from the HAL regarding > properties modification. Does the patch affect the correct internal functioning of the HAL or is it only related to PortAudio receiving notifications? Ross. ----- Original Message ----- From: "Olivier Tristan" To: "Portaudio Mailing List" Sent: Wednesday, April 21, 2010 5:59 PM Subject: Re: [Portaudio] OSX 10.6 runLoop patch question > Hi, > > It fixes an issue related to notification from the HAL regarding > properties modification. > There is a change in the way 10.6 handles property listener thread and it > didn't worked anymore. > > As you use properties too, I think it might fix your issue. > > HTH > > > On 4/21/2010 8:32 AM, Ross Bencina wrote: >> Hi Guys >> >> I'm wondering what the following patch actually does for PA and CoreAudio >> behavior: >> >> "maccore: fixed MacOSX "Snow Leopard" 10.6+ deadlock on sample-rate >> change submitted by Olivier Tristan" >> http://www.portaudio.com/trac/changeset/1483 >> >> I've read the thread from February, but can anyone explain it in more >> detail? >> >> I have not yet pulled the above patch into my local copy of PA. I'm not >> currently using paMacCoreChangeDeviceParameters, but I'm wondering if it >> might fix another deadlock issue I have on Snow Leopard. >> >> >> I have a local modification here which improves PaStreamCallbackTimeInfo >> in CoreAudio (I havn't committed it because it is incomplete, but works >> for my cases). My mod calls AudioDeviceGetProperty to fetch >> kAudioDevicePropertyActualSampleRate and kAudioDevicePropertyLatency >> within the IOProc. One of the AudioDeviceGetProperty calls has started to >> intermittently deadlock on Snow Leopard when I open a standard file >> dialog and select different soundfiles (it looks like the dialog creates >> an AudioQueue and makes some changes to the HAL, for more detail see my >> post to the CoreAudio list >> http://lists.apple.com/archives/coreaudio-api/2010/Apr/msg00165.html). >> >> Do you think this is something that might be fixed by the runloop patch >> above? The deadlocks I'm seeing are intermittent so I'm kind of hoping to >> find out what's causing the problem rather than just updating with the >> patch, testing, and hoping for the best. >> >> Any thoughts? >> >> Thanks >> >> Ross. >> >> >> >> >> >> >> _______________________________________________ >> Portaudio mailing list >> Portaudio at music.columbia.edu >> http://music.columbia.edu/mailman/listinfo/portaudio >> > > > -- > Olivier Tristan > Ultimate Sound Bank > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio From o.tristan at ultimatesoundbank.com Wed Apr 21 05:45:41 2010 From: o.tristan at ultimatesoundbank.com (Olivier Tristan) Date: Wed, 21 Apr 2010 11:45:41 +0200 Subject: [Portaudio] OSX 10.6 runLoop patch question In-Reply-To: <000e01cae136$039217b0$0f73a8c0@rossmacbook> References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> <4BCEB047.3070308@ultimatesoundbank.com> <000e01cae136$039217b0$0f73a8c0@rossmacbook> Message-ID: <4BCEC945.7030808@ultimatesoundbank.com> On 4/21/2010 11:35 AM, Ross Bencina wrote: > Hi Oliver > > Unfortunately it didn't fix my issue. > > >> It fixes an issue related to notification from the HAL regarding >> properties modification. > > Does the patch affect the correct internal functioning of the HAL or > is it only related to PortAudio receiving notifications? > Only related to PortAudio receiving notification. In your case, can't your retrieve the current Sample Rate synchronously using AudioDeviceGetProperty ? I'm currently using this to retrieve nominal sample rate available in my application instead of using Pa_IsFormatSupported. -- Olivier Tristan Ultimate Sound Bank From letz at grame.fr Wed Apr 21 07:13:04 2010 From: letz at grame.fr (=?iso-8859-1?Q?St=E9phane_Letz?=) Date: Wed, 21 Apr 2010 13:13:04 +0200 Subject: [Portaudio] OSX 10.6 runLoop patch question In-Reply-To: <4BCEC945.7030808@ultimatesoundbank.com> References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> <4BCEB047.3070308@ultimatesoundbank.com> <000e01cae136$039217b0$0f73a8c0@rossmacbook> <4BCEC945.7030808@ultimatesoundbank.com> Message-ID: <421D3191-EF36-4A49-8A8A-DD229FDB7F4A@grame.fr> Le 21 avr. 2010 ? 11:45, Olivier Tristan a ?crit : > On 4/21/2010 11:35 AM, Ross Bencina wrote: >> Hi Oliver >> >> Unfortunately it didn't fix my issue. >> >> >>> It fixes an issue related to notification from the HAL regarding properties modification. >> >> Does the patch affect the correct internal functioning of the HAL or is it only related to PortAudio receiving notifications? >> > > Only related to PortAudio receiving notification. > > In your case, can't your retrieve the current Sample Rate synchronously using AudioDeviceGetProperty ? > I'm currently using this to retrieve nominal sample rate available in my application instead of using Pa_IsFormatSupported. > > -- > Olivier Tristan > Ultimate Sound Bank > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio Her what Jeff Moore explained in october 2009 on CA list : ========= All that said, there may be a more simple cause. One thing that caught , my eye was your description of how the system was sleeping and waking , in fits and starts. I've seen that happen in processes that have , blocked on the HAL's notification thread. One thing that changed in , SnowLeopard is that by default, the HAL will use the process's main , thread for it's notifications. It is possible that the main thread in one of your processes has , blocked and is preventing the HAL from getting notifications. If this , is the problem, the fix is pretty simple. Just be sure to set the , system object property, kAudioHardwarePropertyRunLoop, to NULL. This , will cause the HAL to run it's own thread for handling notifications, , which was the default prior to SnowLeopard. ========= St?phane From lists.josh.business at gmail.com Wed Apr 21 23:31:45 2010 From: lists.josh.business at gmail.com (Josh Fisher) Date: Wed, 21 Apr 2010 20:31:45 -0700 Subject: [Portaudio] windows 7 asio weirdness Message-ID: I'm using the svn trunk from March 15, 2010 to build a static version of portaudio with support for directsound and asio on a 32 bit Windows XP machine. On XP machines in general everything works perfectly. I'm doing some testing on a 64 bit Windows 7 machine and whenever I launch the program it takes some amount of time for the callback to start, generally between a half minute and a minute. None of the initialization and setup calls report any errors, likewise with the teardown calls at the end. The device is a Line 6 Pod Studio GX with the most recent driver. I'm not sure if this is something I can work around with portaudio, or if its an issue with the driver? Line 6's drivers are usually quite good, so I'm a little confused. I wonder if anyone else has seen this same problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossb-lists at audiomulch.com Thu Apr 22 02:00:57 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Thu, 22 Apr 2010 16:00:57 +1000 Subject: [Portaudio] OSX 10.6 runLoop patch question References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> <4BCEB047.3070308@ultimatesoundbank.com><000e01cae136$039217b0$0f73a8c0@rossmacbook><4BCEC945.7030808@ultimatesoundbank.com> <421D3191-EF36-4A49-8A8A-DD229FDB7F4A@grame.fr> Message-ID: <021501cae1e1$2e7b6390$0f73a8c0@rossmacbook> Thanks Oliver, St?phane Responses below... > In your case, can't your retrieve the current Sample Rate synchronously > using AudioDeviceGetProperty ? I do use AudioDeviceGetProperty. See my description of what I'm doing here: http://lists.apple.com/archives/coreaudio-api/2010/Apr/msg00165.html That post also includes stack traces from the deadlocked threads. The problem is that AudioDeviceGetProperty is never returning and seems deadlocked with an AudioQueue thread created by the standard file dialog. St?phane wrote: >Her what Jeff Moore explained in october 2009 on CA list : ====== It is possible that the main thread in one of your processes has , blocked and is preventing the HAL from getting notifications. If this , is the problem, the fix is pretty simple. Just be sure to set the , system object property, kAudioHardwarePropertyRunLoop, to NULL. This will cause the HAL to run it's own thread for handling notifications, which was the default prior to SnowLeopard. ========= That's interesting. Perhaps it is Apple's AudioQueue code which is stalling due to runloop interactions in my app... and wedging the PA IOProc... Thanks! Ross. From johngavingraham at googlemail.com Fri Apr 23 06:49:42 2010 From: johngavingraham at googlemail.com (John Graham) Date: Fri, 23 Apr 2010 11:49:42 +0100 Subject: [Portaudio] MinGW Compilation Problem In-Reply-To: References: Message-ID: Okay, I solved this problem - just in case anyone else runs into the same, it was a simple case of adding src/os/win/pa_win_waveformat.o to OTHER_OBJS in the configure script. John G On Sat, Apr 17, 2010 at 7:13 PM, John Graham wrote: > Hi there, > > I'm having a problem compiling PortAudio using MinGW (i686-pc-mingw, > version 3.4.5). ?After an apparently successful `./configure', I get > this when doing `make': > > > src/hostapi/wmme/.libs/pa_win_wmme.o: In function `QueryFormatSupported': > /usr/local/trip2/src/lib/portaudio/portaudio-19-mingw32/src/hostapi/wmme/pa_win_wmme.c:549: > undefined reference to `_PaWin_InitializeWaveFormatExtensible' > > > (as well as some more undefined references) > > I seem to be having the same problem as described here: > http://music.columbia.edu/pipermail/portaudio/2007-September/007562.html > > However, the suggested solution (the patches here: > http://music.columbia.edu/pipermail/portaudio/2007-September/007554.html) > don't seem to work, and the result is exactly the same. > > One thing about the patches, though - the second is for the configure > script after it's been configured, which seems a little weird. I > couldn't apply it as most of it failed, but I don't think that should > matter too much (right?). > > I'd be grateful if anybody has any suggestions? > > John G > > P.S. All I pass to the configure script is a --prefix and > --host=i686-pc-mingw32, if that makes any difference... > From tendays-kde at gamboni.org Sat Apr 24 04:00:24 2010 From: tendays-kde at gamboni.org (Maxime) Date: Sat, 24 Apr 2010 10:00:24 +0200 Subject: [Portaudio] Capture hangs occasionally Message-ID: <201004241000.24516.tendays-kde@gamboni.org> Hello list, This is my first message in here I hope I am not doing anything wrong! I am trying to port a program I wrote from ALSA to portaudio but I am having issues with capture on my laptop. The same program works perfectly on another laptop I have access to so I don't quite know how to debug this. I am using the blocking API, and Pa_ReadStream sometimes does not return (like 0.1% of the times). My system specifications: Ubuntu 9.10 32bit (kernel 2.6.31-20-generic #58-Ubuntu SMP) dpkg-query -l | grep portaudio tells me I am running version 19+svn20090620-0ubuntu1 of the library lspci | grep Audio returns 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Running my test program in gdb and doing a control-C after it has hanged gives the following backtrace: #0 0x0012d422 in __kernel_vsyscall () #1 0x00212c5b in *__GI___poll (fds=0x294ff4, nfds=1, timeout=22) at ../sysdeps/unix/sysv/linux/poll.c:83 #2 0x0013ec64 in ?? () from /usr/lib/libportaudio.so.2 #3 0x0013f765 in ?? () from /usr/lib/libportaudio.so.2 #4 0x00134e3c in Pa_ReadStream () from /usr/lib/libportaudio.so.2 #5 0x08048987 in main () at rectest.c:49 I attached, reduced as much as I could, the source code of the "wire" example program that exhibits the problem. When I run it it shows a number of dots (different at each time, sometimes a few dozens, sometimes up to a hundred or two) before stopping. If anyone can help, thank you! Maxime -------------- next part -------------- A non-text attachment was scrubbed... Name: rectest.c Type: text/x-csrc Size: 1938 bytes Desc: not available URL: From Werner.Dittmann at t-online.de Sat Apr 24 14:37:17 2010 From: Werner.Dittmann at t-online.de (Werner Dittmann) Date: Sat, 24 Apr 2010 20:37:17 +0200 Subject: [Portaudio] Capture hangs occasionally In-Reply-To: <201004241000.24516.tendays-kde@gamboni.org> References: <201004241000.24516.tendays-kde@gamboni.org> Message-ID: <4BD33A5D.4000504@t-online.de> I saw this also some time ago I found a fix for it and sent it to the list (December/January). It's because a weired behaviour of some sound devices together with a missing reset of the capture device IIRC. This causes an endless loop in the poll to get new data. Do you have a way to build (compile/build) portaudio? If yes I can send you the fixed source file (or a patch because the ML is restricted with respect to attachment size) Regards, Werner Am 24.04.2010 10:00, schrieb Maxime: > Hello list, > > This is my first message in here I hope I am not doing anything wrong! > > I am trying to port a program I wrote from ALSA to portaudio but I am having > issues with capture on my laptop. The same program works perfectly on another > laptop I have access to so I don't quite know how to debug this. > > I am using the blocking API, and Pa_ReadStream sometimes does not return (like > 0.1% of the times). My system specifications: > > Ubuntu 9.10 32bit (kernel 2.6.31-20-generic #58-Ubuntu SMP) > > dpkg-query -l | grep portaudio tells me I am running version > 19+svn20090620-0ubuntu1 of the library > > lspci | grep Audio returns 00:1b.0 Audio device: Intel Corporation 82801I > (ICH9 Family) HD Audio Controller (rev 03) > > Running my test program in gdb and doing a control-C after it has hanged gives > the following backtrace: > > #0 0x0012d422 in __kernel_vsyscall () > #1 0x00212c5b in *__GI___poll (fds=0x294ff4, nfds=1, timeout=22) at > ../sysdeps/unix/sysv/linux/poll.c:83 > #2 0x0013ec64 in ?? () from /usr/lib/libportaudio.so.2 > #3 0x0013f765 in ?? () from /usr/lib/libportaudio.so.2 > #4 0x00134e3c in Pa_ReadStream () from /usr/lib/libportaudio.so.2 > #5 0x08048987 in main () at rectest.c:49 > > I attached, reduced as much as I could, the source code of the "wire" example > program that exhibits the problem. > > When I run it it shows a number of dots (different at each time, sometimes a > few dozens, sometimes up to a hundred or two) before stopping. > > If anyone can help, thank you! > > Maxime > > > > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio From tendays-kde at gamboni.org Sat Apr 24 15:55:21 2010 From: tendays-kde at gamboni.org (Maxime) Date: Sat, 24 Apr 2010 21:55:21 +0200 Subject: [Portaudio] Capture hangs occasionally In-Reply-To: <4BD33A5D.4000504@t-online.de> References: <201004241000.24516.tendays-kde@gamboni.org> <4BD33A5D.4000504@t-online.de> Message-ID: <201004242155.21931.tendays-kde@gamboni.org> Hello, On Saturday April 24th at 20:37, Werner Dittmann, you wrote: > I saw this also some time ago I found a fix for it and sent it to > the list (December/January). Okay I found your message in the archives (no need to resend). I'll try and report back how well it worked. Thanks! Maxime From tendays-kde at gamboni.org Sat Apr 24 16:54:41 2010 From: tendays-kde at gamboni.org (Maxime) Date: Sat, 24 Apr 2010 22:54:41 +0200 Subject: [Portaudio] Capture hangs occasionally In-Reply-To: <201004242155.21931.tendays-kde@gamboni.org> References: <201004241000.24516.tendays-kde@gamboni.org> <4BD33A5D.4000504@t-online.de> <201004242155.21931.tendays-kde@gamboni.org> Message-ID: <201004242254.42073.tendays-kde@gamboni.org> Hello, On Saturday April 24th at 21:55, I wrote: > Okay I found your message in the archives (no need to resend). I'll try and > report back how well it worked. So it works better! But still hangs sometimes :-( The basic rectest program I attached in my earlier mail now works. My larger program works better but still hangs every now and then, apparently because it does more processing between two calls to Pa_ReadStream. Indeed, adding usleep(8000) somewhere in the loop in that small rectest program simulates that extra processing and makes it freeze again. Symptoms are identical (loops a few dozen times and then Pa_ReadStream doesn't return) apart from the addresses in the backtrace being slightly different of course. If that's helpful I could recompile portaudio with debugging symbols, to have a human readable backtrace? Thanks, Maxime From jrom at seas.upenn.edu Sat Apr 24 17:28:15 2010 From: jrom at seas.upenn.edu (Joe Romano) Date: Sat, 24 Apr 2010 17:28:15 -0400 Subject: [Portaudio] Capture hangs occasionally Message-ID: Hi Maxime, I had a similar issue with the output thread hanging very rarely. I tried to debug for a long time with no luck. What I ended up doing is setting up another thread as a "watchdog" thread. This new thread continuously checks to see if the portaudio output function is hanging. If it does hang it kills it and restarts it. I know that is not a graceful solution, but I'd be happy to send you some example code. -Joe R. Message: 4 Date: Sat, 24 Apr 2010 10:00:24 +0200 From: Maxime To: portaudio at music.columbia.edu Subject: [Portaudio] Capture hangs occasionally Message-ID: <201004241000.24516.tendays-kde at gamboni.org> Content-Type: text/plain; charset="us-ascii" Hello list, This is my first message in here I hope I am not doing anything wrong! I am trying to port a program I wrote from ALSA to portaudio but I am having issues with capture on my laptop. The same program works perfectly on another laptop I have access to so I don't quite know how to debug this. I am using the blocking API, and Pa_ReadStream sometimes does not return (like 0.1% of the times). My system specifications: Ubuntu 9.10 32bit (kernel 2.6.31-20-generic #58-Ubuntu SMP) dpkg-query -l | grep portaudio tells me I am running version 19+svn20090620-0ubuntu1 of the library lspci | grep Audio returns 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Running my test program in gdb and doing a control-C after it has hanged gives the following backtrace: #0 0x0012d422 in __kernel_vsyscall () #1 0x00212c5b in *__GI___poll (fds=0x294ff4, nfds=1, timeout=22) at ../sysdeps/unix/sysv/linux/poll.c:83 #2 0x0013ec64 in ?? () from /usr/lib/libportaudio.so.2 #3 0x0013f765 in ?? () from /usr/lib/libportaudio.so.2 #4 0x00134e3c in Pa_ReadStream () from /usr/lib/libportaudio.so.2 #5 0x08048987 in main () at rectest.c:49 I attached, reduced as much as I could, the source code of the "wire" example program that exhibits the problem. When I run it it shows a number of dots (different at each time, sometimes a few dozens, sometimes up to a hundred or two) before stopping. If anyone can help, thank you! Maxime -------------- next part -------------- An HTML attachment was scrubbed... URL: From damencho at sip-communicator.org Sun Apr 25 03:33:36 2010 From: damencho at sip-communicator.org (Damian Minkov) Date: Sun, 25 Apr 2010 10:33:36 +0300 Subject: [Portaudio] Capture hangs occasionally In-Reply-To: References: Message-ID: Hi all and Werner, we were looking at the same issue this Thursday and made one more change to the alsa hostapi. We were also experiencing an endless loop while checking poll when using blocking api and Werner modifications. The problem was that in PaAlsaStream_WaitForFrames we enter the endless loop. And this was due to checks in PaAlsaStreamComponent_EndPolling and revents at some state are only 0 which lead to the endless loop and polling. So if revents are 0 we put a check for PaAlsaStreamComponent_GetAvailableFrames, which will actually first check for xrun and will return if its in this state and which prevents that endless loop. I attach latest changes which also include Werner modifications. Cheers damencho On Sun, Apr 25, 2010 at 12:28 AM, Joe Romano wrote: > Hi Maxime, > I had a similar issue with the output thread hanging very rarely. > I tried to debug for a long time with no luck. What I ended up doing is > setting up another thread as a "watchdog" thread. This new thread > continuously checks to see if the portaudio output function is hanging. If > it does hang it kills it and restarts it. I know that is not a graceful > solution, but I'd be happy to send you some example code. > > -Joe R. > > Message: 4 > Date: Sat, 24 Apr 2010 10:00:24 +0200 > From: Maxime > To:?portaudio at music.columbia.edu > Subject: [Portaudio] Capture hangs occasionally > Message-ID: <201004241000.24516.tendays-kde at gamboni.org> > Content-Type: text/plain; charset="us-ascii" > > Hello list, > > This is my first message in here I hope I am not doing anything wrong! > > I am trying to port a program I wrote from ALSA to portaudio but I am having > issues with capture on my laptop. The same program works perfectly on > another > laptop I have access to so I don't quite know how to debug this. > > I am using the blocking API, and Pa_ReadStream sometimes does not return > (like > 0.1% of the times). My system specifications: > > Ubuntu 9.10 32bit (kernel 2.6.31-20-generic #58-Ubuntu SMP) > > dpkg-query -l | grep portaudio tells me I am running version > 19+svn20090620-0ubuntu1 of the library > > lspci | grep Audio returns 00:1b.0 Audio device: Intel Corporation 82801I > (ICH9 Family) HD Audio Controller (rev 03) > > Running my test program in gdb and doing a control-C after it has hanged > gives > the following backtrace: > > #0 ?0x0012d422 in __kernel_vsyscall () > #1 ?0x00212c5b in *__GI___poll (fds=0x294ff4, nfds=1, timeout=22) at > ../sysdeps/unix/sysv/linux/poll.c:83 > #2 ?0x0013ec64 in ?? () from /usr/lib/libportaudio.so.2 > #3 ?0x0013f765 in ?? () from /usr/lib/libportaudio.so.2 > #4 ?0x00134e3c in Pa_ReadStream () from /usr/lib/libportaudio.so.2 > #5 ?0x08048987 in main () at rectest.c:49 > > I attached, reduced as much as I could, the source code of the "wire" > example > program that exhibits the problem. > > When I run it it shows a number of dots (different at each time, sometimes a > few dozens, sometimes up to a hundred or two) before stopping. > > If anyone can help, thank you! > > Maxime > _______________________________________________ > Portaudio mailing list > Portaudio at music.columbia.edu > http://music.columbia.edu/mailman/listinfo/portaudio > -------------- next part -------------- A non-text attachment was scrubbed... Name: pa_linux_alsa.c.patch Type: application/empty Size: 5755 bytes Desc: not available URL: From tendays-kde at gamboni.org Sun Apr 25 09:09:44 2010 From: tendays-kde at gamboni.org (Maxime) Date: Sun, 25 Apr 2010 15:09:44 +0200 Subject: [Portaudio] Capture hangs occasionally In-Reply-To: References: Message-ID: <201004251509.44588.tendays-kde@gamboni.org> Hello Damian et al, Still not there :( My program (the real one, not the little rectest) seems to hang less frequently, but still does. That "rectest" program I attached earlier with the usleep(8000) added in will hang after printing a few hundred points. I compiled portaudio with your patch. Running in gdb and doing a control-C after it freezes gives me this stack trace: #0 0x0012d422 in __kernel_vsyscall () #1 0x00213c5b in *__GI___poll (fds=0x295ff4, nfds=1, timeout=22) at ../sysdeps/unix/sysv/linux/poll.c:83 #2 0x00140dad in PaAlsaStream_WaitForFrames (self=0x8065a00, framesAvail=0xbffff690, xrunOccurred=0xbffff684) at src/hostapi/alsa/pa_linux_alsa.c:2938 #3 0x0014239e in ReadStream (s=0x8065a00, buffer=0x804b008, frames=1024) at src/hostapi/alsa/pa_linux_alsa.c:3482 #4 0x00135762 in Pa_ReadStream (stream=0x8065a00, buffer=0x804b008, frames=1024) at src/common/pa_front.c:1616 #5 0x0804898f in main () at rectest.c:49 I'll try reading that pa_linux_alsa.c file to see if I understand how it works and why it fails, unless someone can gather what the problem is from that stack trace? I'm keeping gdb open in case there are some other tests I can do. On Sunday April 25th at 09:33, Damian Minkov wrote: > Hi all and Werner, > > we were looking at the same issue this Thursday and made one more > change to the alsa hostapi. We were also experiencing an endless loop > while checking poll when using blocking api and Werner modifications. > The problem was that in PaAlsaStream_WaitForFrames we enter the > endless loop. And this was due to checks in > PaAlsaStreamComponent_EndPolling and revents at some state are only 0 > which lead to the endless loop and polling. So if revents are 0 we put > a check for PaAlsaStreamComponent_GetAvailableFrames, which will > actually first check for xrun and will return if its in this state and > which prevents that endless loop. I attach latest changes which also > include Werner modifications. > > I am trying to port a program I wrote from ALSA to portaudio but I am > > having issues with capture on my laptop. The same program works > > perfectly on another > > laptop I have access to so I don't quite know how to debug this. > > > > I am using the blocking API, and Pa_ReadStream sometimes does not return > > (like > > 0.1% of the times). My system specifications: > > > > Ubuntu 9.10 32bit (kernel 2.6.31-20-generic #58-Ubuntu SMP) > > > > dpkg-query -l | grep portaudio tells me I am running version > > 19+svn20090620-0ubuntu1 of the library > > > > lspci | grep Audio returns 00:1b.0 Audio device: Intel Corporation 82801I > > (ICH9 Family) HD Audio Controller (rev 03) > > > > When I run it it shows a number of dots (different at each time, > > sometimes a few dozens, sometimes up to a hundred or two) before > > stopping. Cheers and Thanks, Maxime From tendays-kde at gamboni.org Sun Apr 25 12:20:34 2010 From: tendays-kde at gamboni.org (Maxime) Date: Sun, 25 Apr 2010 18:20:34 +0200 Subject: [Portaudio] Capture hangs occasionally In-Reply-To: <201004251509.44588.tendays-kde@gamboni.org> References: <201004251509.44588.tendays-kde@gamboni.org> Message-ID: <201004251820.34720.tendays-kde@gamboni.org> Hello, Some progress: On Sunday April 25th at 15:09, I wrote: > I'll try reading that pa_linux_alsa.c file to see if I understand how it > works and why it fails, unless someone can gather what the problem is from > that stack trace? So it is stuck in that while(pollPlayback || pollCapture) loop inside PaAlsaStream_WaitForFrames, the reason, from my limited understanding of ALSA, that the pcm handle is in SND_PCM_STATE_PREPARED instead of SND_PCM_STATE_RUNNING, so: 1) polling always sets revents to 0 2) there's no xrun (the state is SND_PCM_STATE_PREPARED, not SND_PCM_STATE_XRUN) 3) querying for available frames returns zero My understanding of the ALSA state machine is still too limited for me to understand why or how it entered that SND_PCM_STATE_PREPARED state. Testing for the pcm state and executing snd_pcm_start if it is PREPARED seems to fix the problem. Any idea where it entered that state, and what would be a good place for testing that condition? > On Sunday April 25th at 09:33, Damian Minkov wrote: > > Hi all and Werner, > > > > we were looking at the same issue this Thursday and made one more > > change to the alsa hostapi. We were also experiencing an endless loop > > while checking poll when using blocking api and Werner modifications. > > The problem was that in PaAlsaStream_WaitForFrames we enter the > > endless loop. And this was due to checks in > > PaAlsaStreamComponent_EndPolling and revents at some state are only 0 > > which lead to the endless loop and polling. So if revents are 0 we put > > a check for PaAlsaStreamComponent_GetAvailableFrames, which will > > actually first check for xrun and will return if its in this state and > > which prevents that endless loop. I attach latest changes which also > > include Werner modifications. > > > > > I am using the blocking API, and Pa_ReadStream sometimes does not > > > return (like > > > 0.1% of the times). My system specifications: > > > > > > Ubuntu 9.10 32bit (kernel 2.6.31-20-generic #58-Ubuntu SMP) > > > > > > dpkg-query -l | grep portaudio tells me I am running version > > > 19+svn20090620-0ubuntu1 of the library > > > > > > lspci | grep Audio returns 00:1b.0 Audio device: Intel Corporation > > > 82801I (ICH9 Family) HD Audio Controller (rev 03) > > > > > > When I run it it shows a number of dots (different at each time, > > > sometimes a few dozens, sometimes up to a hundred or two) before > > > stopping. Cheers and Thanks, Maxime From ralph.irving at gmail.com Sun Apr 25 16:12:07 2010 From: ralph.irving at gmail.com (Ralph Irving) Date: Sun, 25 Apr 2010 16:12:07 -0400 (EDT) Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: <1271665411.4bcc13038df6d@mail.inbox.lv> References: <1271425248.4bc868e035555@mail.inbox.lv> <1271665411.4bcc13038df6d@mail.inbox.lv> Message-ID: Dmitry, Thanks for the clarification that CoInitialize/Uninitialize are for windows only. I finally had a chance to move the calls to Pa_Init/Term into my audio thread. I removed the CoInit/Uninit calls I had added and WASAPI still works fine. Ralphy. On Mon, 19 Apr 2010, Dmitry Kostjuchenko wrote: > Hi Ralph! > > Well it is not all just about WASAPI implementation. > > For example,?PA's ASIO implementation also requires more stricter approach towards CoInitialize/Uninitialize pair, > now it is relaxed and calls CoInitialize when you do OpenStream. DS interface has CoInitialize/Uninitialize > similarly to WASAPI in PA Initialization phase, but I think Microsoft tweaked DS and calls CoInitialize internally > thus it may explain why it always works. The same is with?WMME which does it internally. > > May be Microsoft internally has more abilities to cleanup COM in such situations but using public API and messing > with CoInitialize/Uninitialize wrong order will simply lead to Exception thrown to your application if > CoUninitialize is wrongly?called. > > For WASAPI Microsoft does not do any additional calls to CoInitialize and thus it can't work like DS/WMME or ASIO > (which does CoInitialize additionally). > > I did not want to put additional calls CoInitialize intentionally, as then if user opens stream in one thread and > closes from another it would cause thrown Exception from PortAudio side and it could be?percieved as PortAudio > side?bug. So let's avoid such case! It is not PortAudio's specifics but Microsoft's COM model which must be strictly > followed by application developers. > > ALSA/OSS/CoreAudio do not have similar concept so we talk only about Windows platform. > > Best regards, > Dmitry. From dmitrykos at inbox.lv Mon Apr 26 05:25:17 2010 From: dmitrykos at inbox.lv (Dmitry Kostjuchenko) Date: Mon, 26 Apr 2010 12:25:17 +0300 Subject: [Portaudio] WASAPI AUDCLNT_E_INVALID_DEVICE_PERIOD Error In-Reply-To: References: <1271425248.4bc868e035555@mail.inbox.lv> <1271665411.4bcc13038df6d@mail.inbox.lv> Message-ID: <1272273917.4bd55bfd67209@mail.inbox.lv> Hi Ralph! That's great and?an ideal model of PA usage in MT application under any platform. As to Windows just treat CoInitialize/Uninitialize?as thread-local storage for COM objects which will be called by a thread. Best regards, Dmitry. Quoting Ralph Irving : > Dmitry, > Thanks for the clarification that CoInitialize/Uninitialize are for > windows only. > I finally had a chance to move the calls to Pa_Init/Term into my audio > thread. I removed the CoInit/Uninit calls I had added and WASAPI > still works fine. > Ralphy. > On Mon, 19 Apr 2010, Dmitry Kostjuchenko wrote: > > Hi Ralph! > > > > Well it is not all just about WASAPI implementation. > > > > For example,?PA's ASIO implementation also requires more stricter approach towards CoInitialize/Uninitialize pair, > > now it is relaxed and calls CoInitialize when you do OpenStream. DS interface has CoInitialize/Uninitialize > > similarly to WASAPI in PA Initialization phase, but I think Microsoft tweaked DS and calls CoInitialize internally > > thus it may explain why it always works. The same is with?WMME which does it internally. > > > > May be Microsoft internally has more abilities to cleanup COM in such situations but using public API and messing > > with CoInitialize/Uninitialize wrong order will simply lead to Exception thrown to your application if > > CoUninitialize is wrongly?called. > > > > For WASAPI Microsoft does not do any additional calls to CoInitialize and thus it can't work like DS/WMME or ASIO > > (which does CoInitialize additionally). > > > > I did not want to put additional calls CoInitialize intentionally, as then if user opens stream in one thread and > > closes from another it would cause thrown Exception from PortAudio side and it could be?percieved as PortAudio > > side?bug. So let's avoid such case! It is not PortAudio's specifics but Microsoft's COM model which must be strictly > > followed by application developers. > > > > ALSA/OSS/CoreAudio do not have similar concept so we talk only about Windows platform. > > > > Best regards, > Dmitry. iAuxSoft ------------------ [www.iauxsoft.com] From rossb-lists at audiomulch.com Tue Apr 27 10:04:39 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 28 Apr 2010 00:04:39 +1000 Subject: [Portaudio] OSX 10.6 runLoop patch question References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> <4BCEB047.3070308@ultimatesoundbank.com><000e01cae136$039217b0$0f73a8c0@rossmacbook> <4BCEC945.7030808@ultimatesoundbank.com> Message-ID: <003001cae612$9487d490$0f73a8c0@rossmacbook> Hi Guys For those not watching the CoreAudio list, I've now resolved this issue. It turned out that it's not legal to call any AUHAL methods from the IOProc. > In your case, can't your retrieve the current Sample Rate synchronously > using AudioDeviceGetProperty ? I was calling AudioDeviceGetProperty from the IOProc. That is why I was getting a deadlock. The fix (hopefully) was to buffer all the properties I needed, subscribe to them via notifications and keep an io-proc exclusive copy synchronised with a trylock... I'll try to submit a clean patch soon. Thanks Ross. From o.tristan at ultimatesoundbank.com Tue Apr 27 10:17:13 2010 From: o.tristan at ultimatesoundbank.com (Olivier Tristan) Date: Tue, 27 Apr 2010 16:17:13 +0200 Subject: [Portaudio] OSX 10.6 runLoop patch question In-Reply-To: <003001cae612$9487d490$0f73a8c0@rossmacbook> References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> <4BCEB047.3070308@ultimatesoundbank.com><000e01cae136$039217b0$0f73a8c0@rossmacbook> <4BCEC945.7030808@ultimatesoundbank.com> <003001cae612$9487d490$0f73a8c0@rossmacbook> Message-ID: <4BD6F1E9.4090503@ultimatesoundbank.com> On 4/27/2010 4:04 PM, Ross Bencina wrote: >> In your case, can't your retrieve the current Sample Rate >> synchronously using AudioDeviceGetProperty ? > > I was calling AudioDeviceGetProperty from the IOProc. That is why I > was getting a deadlock. > > > The fix (hopefully) was to buffer all the properties I needed, > subscribe to them via notifications and keep an io-proc exclusive copy > synchronised with a trylock... > > I'll try to submit a clean patch soon. Not sure I understand correctly. Does the actual PortAudio exhibits that kind of issues ? If yes, in which use case. Thanks, -- Olivier Tristan Ultimate Sound Bank From rossb-lists at audiomulch.com Wed Apr 28 02:11:25 2010 From: rossb-lists at audiomulch.com (Ross Bencina) Date: Wed, 28 Apr 2010 16:11:25 +1000 Subject: [Portaudio] OSX 10.6 runLoop patch question References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> <4BCEB047.3070308@ultimatesoundbank.com><000e01cae136$039217b0$0f73a8c0@rossmacbook> <4BCEC945.7030808@ultimatesoundbank.com><003001cae612$9487d490$0f73a8c0@rossmacbook> <4BD6F1E9.4090503@ultimatesoundbank.com> Message-ID: <00ea01cae699$a31d9490$0f73a8c0@rossmacbook> >>> In your case, can't your retrieve the current Sample Rate synchronously >>> using AudioDeviceGetProperty ? >> >> I was calling AudioDeviceGetProperty from the IOProc. That is why I was >> getting a deadlock. > Not sure I understand correctly. > Does the actual PortAudio exhibits that kind of issues ? If yes, in which > use case. No, the current source in SVN doesn't exhibit this issue (but the PaStreamCallbackTimeInfo implementation is broken, which is what i'm trying to fix). I was just clarifying that you can't call AudioDeviceGetProperty directly from the IOProc Thanks Ross. From o.tristan at ultimatesoundbank.com Wed Apr 28 04:25:26 2010 From: o.tristan at ultimatesoundbank.com (Olivier Tristan) Date: Wed, 28 Apr 2010 10:25:26 +0200 Subject: [Portaudio] OSX 10.6 runLoop patch question In-Reply-To: <00ea01cae699$a31d9490$0f73a8c0@rossmacbook> References: <04c601cae11c$75563bc0$0f73a8c0@rossmacbook> <4BCEB047.3070308@ultimatesoundbank.com><000e01cae136$039217b0$0f73a8c0@rossmacbook> <4BCEC945.7030808@ultimatesoundbank.com><003001cae612$9487d490$0f73a8c0@rossmacbook> <4BD6F1E9.4090503@ultimatesoundbank.com> <00ea01cae699$a31d9490$0f73a8c0@rossmacbook> Message-ID: <4BD7F0F6.1020905@ultimatesoundbank.com> On 4/28/2010 8:11 AM, Ross Bencina wrote: >>>> In your case, can't your retrieve the current Sample Rate >>>> synchronously using AudioDeviceGetProperty ? >>> >>> I was calling AudioDeviceGetProperty from the IOProc. That is why I >>> was getting a deadlock. > >> Not sure I understand correctly. >> Does the actual PortAudio exhibits that kind of issues ? If yes, in >> which use case. > > No, the current source in SVN doesn't exhibit this issue (but the > PaStreamCallbackTimeInfo implementation is broken, which is what i'm > trying to fix). > > I was just clarifying that you can't call AudioDeviceGetProperty > directly from the IOProc Thanks for the clarification. -- Olivier Tristan Ultimate Sound Bank From tendays-kde at gamboni.org Thu Apr 29 16:07:29 2010 From: tendays-kde at gamboni.org (Maxime) Date: Thu, 29 Apr 2010 22:07:29 +0200 Subject: [Portaudio] Capture hangs occasionally In-Reply-To: <201004251820.34720.tendays-kde@gamboni.org> References: <201004251509.44588.tendays-kde@gamboni.org> <201004251820.34720.tendays-kde@gamboni.org> Message-ID: <201004292207.30297.tendays-kde@gamboni.org> Hello, On Sunday April 25th at 18:20, I wrote: > So it is stuck in that while(pollPlayback || pollCapture) loop inside > PaAlsaStream_WaitForFrames, the reason, from my limited understanding of > ALSA, that the pcm handle is in SND_PCM_STATE_PREPARED instead of > SND_PCM_STATE_RUNNING, so: > 1) polling always sets revents to 0 > 2) there's no xrun (the state is SND_PCM_STATE_PREPARED, not > SND_PCM_STATE_XRUN) > 3) querying for available frames returns zero > > My understanding of the ALSA state machine is still too limited for me to > understand why or how it entered that SND_PCM_STATE_PREPARED state. > > Testing for the pcm state and executing snd_pcm_start if it is PREPARED > seems to fix the problem. Any idea where it entered that state, and what > would be a good place for testing that condition? I finally decided to put a check inside PaAlsaStreamComponent_BeginPolling. It might be redundant/overkill but at least it works. The attached patch does that and includes the changes by Werner and Damian. Reading Damian's message again I realise it might be enough to put that test in the else clause next to (or instead of?) that call to PaAlsaStreamComponent_GetAvailableFrames? BTW: Is there any reason ReadStream contains a check for the handle being in prepared state but WriteStream doesn't? Thanks, Maxime -------------- next part -------------- A non-text attachment was scrubbed... Name: pa_linux_alsa.c.patch Type: text/x-patch Size: 3867 bytes Desc: not available URL: From zrimkunas at listeninc.com Fri Apr 30 16:17:30 2010 From: zrimkunas at listeninc.com (Zach Rimkunas) Date: Fri, 30 Apr 2010 16:17:30 -0400 Subject: [Portaudio] Picking and Choosing Output Channels Message-ID: <201004302017.o3UKHWCR021920@listeninc.com> Hi Everyone, I'm writing an application using PortAudio. I am on a Windows machine and I'm primarily trying to use the ASIO functionality of PortAudio. My question is this: How can I play out of just one channel (say channel 7) of my sound card without opening all 6 channels preceding channel 7? Looking at the function below I can see how to play out of just one channel but it must always be channel 1 (I set numInputChannels to 1). If I want to play out of channel 7 I would need to say that numInputChannels = 7. How have others dealt with this issue? PaError Pa_OpenStream( PortAudioStream** stream, PaDeviceID inputDevice, int numInputChannels, PaSampleFormat inputSampleFormat, void *inputDriverInfo, PaDeviceID outputDevice, int numOutputChannels, PaSampleFormat outputSampleFormat, void *outputDriverInfo, double sampleRate, unsigned long framesPerBuffer, unsigned long numberOfBuffers, PaStreamFlags streamFlags, PortAudioCallback *callback, void *userData ); Thanks, Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddrtist at gmail.com Fri Apr 30 18:36:26 2010 From: ddrtist at gmail.com (Tatsh) Date: Fri, 30 Apr 2010 18:36:26 -0400 Subject: [Portaudio] libmad and PortAudio Message-ID: <201004301836.26849.ddrtist@gmail.com> A big problem I suppose is the lack of 'official' documentation (by the authors) for libmad. There is however madlld, a demonstration code here: http://www.bsd-dk.dk/~elrond/audio/madlld/ . It is good but it only demonstrates how to go from stdin to stdout. I am working with its decoding function but I am wondering what is the best way to go about turning this function from outputting to stdout to a say an unsigned char* buffer. One of the biggest questions on my mind is whether or not to thread, regardless of whether I use a FIFO or not, or to use global variables (which I'd prefer not to). Also, is anyone familiar with MP3 enough to know about this note from the source of Madldd? /* {1} When decoding from a file we need to know when the end of * the file is reached at the same time as the last bytes are read * (see also the comment marked {3} bellow). Neither the standard * C fread() function nor the POSIX read() system call provides * this feature. We thus need to perform our reads through an * interface having this feature, this is implemented here by the * bstdfile.c module. */ Just kind of want to know more about the above and if there is any alternative to the library madldd uses for reading MP3s correctly (one that is seen on almost all platforms preferably). Thanks -- Tatsh www.tatsh.net ddrtist at gmail.com From lists.josh.business at gmail.com Fri Apr 30 19:25:54 2010 From: lists.josh.business at gmail.com (Josh Fisher) Date: Fri, 30 Apr 2010 16:25:54 -0700 Subject: [Portaudio] libmad and PortAudio In-Reply-To: <201004301836.26849.ddrtist@gmail.com> References: <201004301836.26849.ddrtist@gmail.com> Message-ID: > > Just kind of want to know more about the above and if there is any > alternative to the library madldd uses for reading MP3s correctly (one that is seen on > almost all platforms preferably). > i've had good luck with mpg123 http://www.mpg123.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddrtist at gmail.com Fri Apr 30 22:34:45 2010 From: ddrtist at gmail.com (Tatsh) Date: Fri, 30 Apr 2010 22:34:45 -0400 Subject: [Portaudio] libmad and PortAudio In-Reply-To: References: <201004301836.26849.ddrtist@gmail.com> Message-ID: <201004302234.45471.ddrtist@gmail.com> Yeah I am considering using it. I've had a look at it but my project is a Guitar Hero/Rock Band simulator and really needs the accuracy to sync MIDI, etc else required. That's why I'm trying to use the low-level API of mad and PortAudio's callback mechanism for maximum efficiency and closeness possible. In general terms, 4 tracks (guitar, bass, vocals, and background) and samples (drums) all need to play perfectly in sync. The drum samples have to respond to events (like the user hitting their representation on the peripheral or the game being in a lower difficulty and therefore needing to fill in the gaps programmatically). Will mpg123 fit my needs here? Really, I've brought the first version from scratch to a nearly playable game (the track renders, has buttons, they work including with the 360 guitar controller both on Windows and Linux), but of course I'm missing the key feature: audio. I am really stuck at bringing the audio given from the decoder (any one) to PortAudio's callback, most of the time it will be signed 16-bit integers but not very much success yet. One of my very first attempts is here: http://code.google.com/p/rockstars/source/browse/branches/freeband_old/test/portoggio/portogg.c It actually almost works but a FIFO will make it work much better I'm sure. Regardless of machine it still has quirks and on my old computer would always play the song as if lowered in speed and pitch. Thanks > > Just kind of want to know more about the above and if there is any > > alternative > > to the library madldd uses for reading MP3s correctly (one that is seen on > > > almost all platforms preferably). > > i've had good luck with mpg123 > http://www.mpg123.de/ > -- Tatsh www.tatsh.net ddrtist at gmail.com