The Official Mailing List of the Portaudio project, a x-platform realtime audio API

headers Tzury Bar Yochay | 1 Nov 2010 18:06

_______________________________________________
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
Hi Everyone

A little while ago someone mentioned we needed an up-to-date overview 
document for the PortAudio API. I've always thought there should be some 
kind of architectural overview on the doxygen main page here:
http://www.portaudio.com/docs/v19-doxydocs/index.html

Since I've been slinging mud about poor documentation elsewhere lately I 
thought I'd better clean up my act a bit, so here's a draft of a new API 
overview for the PortAudio doxygen main page. It's a pdf at the moment 
because that was easiest for me to share but I intend to merge the final 
version into the doxygen documentation so it ends up with the rest of the 
API docs. As I note in the pdf, in the final version all function and type 
names will be hyperlinked to the appropriate entry in the doxygen reference.

Here's the draft:

http://www.audiomulch.com/~rossb/junk/NewPortAudioDocOverview_DRAFT_20101105.pdf

It's a bit different from the ICMC paper and the Audio Anecdotes book 
chapter we've written before in that it doesn't include a tutorial or 
discussion of internal implementation details. This is intended as a 
top-down overview or map, with hyperlinks to all the relevant API functions 
and data types -- kind of a way in to the existing API documentation. 
There's probably a room for a PortAudio Internals document too, and of 
course we already have tutorials 
(http://www.portaudio.com/trac/wiki/TutorialDir/TutorialStart)

Please tell me what you think. All corrections/notes/omissions etc welcome. 
It's not as easy to read as the Audio Anecdotes chapter on the same topic --  
if there's an experienced editor/tech writer out there who would be willing 
to help me smooth it out please get in touch 

I'm considering doing a UML diagram of the whole public API.. it's a lot of 
work and I'm not sure it's needed but I'd be interested to hear what people 
think.

Thanks!

Ross 

Ross! This looks terrific. The figure is a bit like something I tried  
to make a while ago and forgot about. Your figure is awesomer than  
what I was working on. I read it and have some minor corrections I am  
sending off list. I think it might be useful to add an FAQ section  
here even if there are FAQs elsewhere on the site just to cover the  
really top questions that get asked when someone is a total noob.  
Here's what came immediately to my mind.

What about reading and writing audio files? PortAudio doesn't do that.  
If you want to read and write files, one popular option is  
libSoundFile; however, there are many, many options for reading and  
writing sound files depending on your OS, licensing and other  
requirements.

Is PortAudio thread-safe? No. It is up to you to figure out how to  
ensure that PortAudio is used in a thread-safe manner. Above-and- 
beyond this, you must ensure that you do not perform certain  
operations such as mallocs, waiting on mutexs, or performing I/O while  
processing audio, as this may result in both audio quality problems,  
and, on some platforms, even more severe issues.
(this is mentioned in the callback section, but it's worth repeating.)

What about MIDI? PortAudio does not handle MIDI. For this, you may  
want to consider the PortMIDI library.

What about volume/pan/EQ controls on my sound device? For controlling  
the input and output volumes on your sound devices, you may want to  
use the PortMixer library.

What about sound processing and effects? You are talking about DSP, or  
Digital Signal Processing. That's cool, but PortAudio won't do it for  
you. You might want to ask on the Music-DSP list.

I want the sound that's coming out of the computer to be an input into  
my software! Unfortunately, this isn't part of most operating system's  
Audio I/O System, so it's not something you can do with PortAudio.

On Nov 4, 2010, at 6:31 PM, Ross Bencina wrote:

> Hi Everyone
>
> A little while ago someone mentioned we needed an up-to-date  
> overview document for the PortAudio API. I've always thought there  
> should be some kind of architectural overview on the doxygen main  
> page here:
> http://www.portaudio.com/docs/v19-doxydocs/index.html
>
>
> Since I've been slinging mud about poor documentation elsewhere  
> lately I thought I'd better clean up my act a bit, so here's a draft  
> of a new API overview for the PortAudio doxygen main page. It's a  
> pdf at the moment because that was easiest for me to share but I  
> intend to merge the final version into the doxygen documentation so  
> it ends up with the rest of the API docs. As I note in the pdf, in  
> the final version all function and type names will be hyperlinked to  
> the appropriate entry in the doxygen reference.
>
> Here's the draft:
>
> http://www.audiomulch.com/~rossb/junk/NewPortAudioDocOverview_DRAFT_20101105.pdf
>
>
> It's a bit different from the ICMC paper and the Audio Anecdotes  
> book chapter we've written before in that it doesn't include a  
> tutorial or discussion of internal implementation details. This is  
> intended as a top-down overview or map, with hyperlinks to all the  
> relevant API functions and data types -- kind of a way in to the  
> existing API documentation. There's probably a room for a PortAudio  
> Internals document too, and of course we already have tutorials
(http://www.portaudio.com/trac/wiki/TutorialDir/TutorialStart 
> )
>
> Please tell me what you think. All corrections/notes/omissions etc  
> welcome. It's not as easy to read as the Audio Anecdotes chapter on  
> the same topic --  if there's an experienced editor/tech writer out  
> there who would be willing to help me smooth it out please get in  
> touch 
>
> I'm considering doing a UML diagram of the whole public API.. it's a  
> lot of work and I'm not sure it's needed but I'd be interested to  
> hear what people think.
>
> Thanks!
>
> Ross
> _______________________________________________
> Portaudio mailing list
> Portaudio <at> music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/portaudio

-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration

_______________________________________________
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
Hello,

I've downloaded and installed both the "stable" and latest sources for 
Portaudio, and have compiled them with both VC2010 and VC2008 using the 
instructions from the tutorial. The ASIO2 SDK was downloaded from 
Steinberg just a couple of days ago.

The problem is that when Pa_OpenStream() is called with MME, ASIO or 
WASAPI devices, it causes the following error in my test app:

"An unhandled exception of type 'System.AccessViolationException' 
occurred in Portaudio Test.exe
Additional information: Attempted to read or write protected memory. 
This is often an indication that other memory is corrupt."

Interestingly enough, DirectSound devices *seem* to work, at least they 
don't crash.

The test programs in the "test" directory also fail in the same manner, 
however the pre-compiled test apps from the website do not. Since the 
pre-compiled continue to work after I rename portaudio_x86.dll to 
something else, I assume they were linked to a static lib instead of 
dynamically to portaudio_x86.dll ?

I have no doubt I'm doing something wrong, just not sure where to start. 
I can initialized Portaudio, enumerate devices and apparently use 
DirectSound devices without crashing.

I've tried various test apps on two different machines. One is x86 Vista 
and the other x64 Windows 7. ASIO devices I've tried include an EMU-0404 
on the x86 Vista box and an M-AUDIO Profire 2626 on the x64 Win7 box. 
Both systems will record and play back with Reaper without problems.

Oh - and I tried compiling a few of the command-line test samples with 
VC6 as well. Same problem occurs when using the portaudio_x86.dll I 
compiled myself with both VC2008 and VC2010.

Sorry for the rambling mail... It's 4AM and I think going to go fall 
into bed now... 

Thanks,
--jim

I'm wondering if anyone has a suggestion for improving this...

We have an application where we would like to run the following sort of loop:

for (whatever) {
 <set mixer volume level>
 Pa_StartStream();
 Pa_ReadStream();
 Pa_AbortStream();
}

The point being to grab short buffers (50 msec) at a variety of volume levels as part of a calibration
process. Unfortunately, even if we leave the volume setting out of the loop, the best we can do for
capturing 50-msec buffers is about 5 cycles of the loop per second. We've encountered the same issue on a
Mac and on a Windows 7 system, and seemingly regardless of the suggested latency. We were hoping to get much
closer to the theoretical 20 buffers per sec.

Does anyone know why it should take ~200 msec to do one cycle of the loop, and crucially, does anyone have
suggestions about things to change that might speed it up?

Thanks,

t
---
Director, Center for Pediatric Auditory and Speech Sciences (CPASS)
Head, Speech Research Lab    | Adjunct Associate Professor
duPont Hospital for Children | Comp. and Info. Sciences / Linguistics
Voice: 1+302+651-6835        | University of Delaware
Fax:   1+302+651-6895        | URL: www.asel.udel.edu/speech/

Hello Tim,

> Does anyone know why it should take ~200 msec to do one cycle of the
> loop, and crucially, does anyone have suggestions about things to
> change that might speed it up?

It takes a while to setup the audio device, prime the buffers and start
the IO, sync with background threads. The 200 msec does not surprise.

Ideally you don't want to be starting and stopping the stream.  If you
can, just leave the stream running. Then output silence between tests.

Something like this:

   Pa_StartStream();
   for (whatever) {
      output silence;
      detect silence;
      <set mixer volume level>
      output signal;
      detect signal;
      measure amplitude;
   }
   Pa_StopStream();

By having a silent gap you can sync with your mixer changes.  Hopefully
changing the mixer will affect the live PortAudio stream.  You may be 
able to speed up this loop better than one that restarts the stream.

Phil Burk

On 11/5/10 10:08 AM, Tim Bunnell wrote:
> I'm wondering if anyone has a suggestion for improving this...
>
> We have an application where we would like to run the following sort
> of loop:
>
> for (whatever) { <set mixer volume level> Pa_StartStream();
> Pa_ReadStream(); Pa_AbortStream(); }
>
> The point being to grab short buffers (50 msec) at a variety of
> volume levels as part of a calibration process. Unfortunately, even
> if we leave the volume setting out of the loop, the best we can do
> for capturing 50-msec buffers is about 5 cycles of the loop per
> second. We've encountered the same issue on a Mac and on a Windows 7
> system, and seemingly regardless of the suggested latency. We were
> hoping to get much closer to the theoretical 20 buffers per sec.
>

Hi,

I want to write a small, cross-platform program with port audio.
If you are up to this small project, mail me at tzury dot by at
reguluslabs dot com

thanks,
Tzury

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

32	May 2013
69	April 2013
51	March 2013
42	February 2013
138	January 2013
71	December 2012
96	November 2012
73	October 2012
77	September 2012
97	August 2012
109	July 2012
145	June 2012
201	May 2012
134	April 2012
145	March 2012
185	February 2012
48	January 2012
121	December 2011
97	November 2011
108	October 2011
42	September 2011
160	August 2011
202	July 2011
166	June 2011
159	May 2011
203	April 2011
262	March 2011
327	February 2011
233	January 2011
119	December 2010
88	November 2010
105	October 2010
67	September 2010
52	August 2010
312	July 2010
182	June 2010
83	May 2010
103	April 2010
145	March 2010
129	February 2010
86	January 2010
26	December 2008
45	November 2008
60	October 2008
51	September 2008
63	August 2008
41	July 2008
48	June 2008
65	May 2008
62	April 2008
141	March 2008
249	February 2008
222	January 2008
116	December 2007
114	November 2007
132	October 2007
121	September 2007
118	August 2007
73	July 2007
126	June 2007
137	May 2007
144	April 2007
108	March 2007
117	February 2007
181	January 2007
127	December 2006
169	November 2006
80	October 2006
93	September 2006
139	August 2006
80	July 2006
89	June 2006
165	May 2006
140	April 2006
127	March 2006
153	February 2006
23	January 2006
88	December 2005
131	November 2005
73	October 2005
62	September 2005
41	August 2005
22	July 2005
35	June 2005
44	May 2005
73	April 2005
186	March 2005
177	February 2005
49	January 2005
90	December 2004
82	November 2004
76	October 2004
89	September 2004
47	August 2004

Re: capturing the audio played on my computer's soundcard

Linux Audio Conference - Call for Participation - website

new PortAudio API overview documentation (DRAFT)

Re: new PortAudio API overview documentation (DRAFT)

Re: new PortAudio API overview documentation (DRAFT)

Re: 1st post and questions about building with MSVC2010 express on x64

Runtime crash when opening stream with MME, ASIO, WASAPI

Long latency on stopping a stream

Re: Long latency on stopping a stream

Is anyone available to write a small program with portaudio