gnustep/libs-gui
0
0
Fork 0
mirror of https://github.com/gnustep/libs-gui.git synced 2025-04-28 22:00:51 +00:00
Code Issues Projects Releases Packages Wiki Activity
libs-gui/Tools/gsnd/portaudio/docs/proposals.html
fedor 81632bcf5b Initial revision 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/gui/trunk@14212 72102866-910b-0410-8b05-ffd578937521
2002-07-30 17:01:47 +00:00

614 lines
63 KiB
HTML
Raw Blame History

<HTML>
<HEAD>
<TITLE>Proposed Changes to PortAudio API</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META content="Phil Burk, Ross Bencina" name=Author>
<META content="Changes being discussed by the community of PortAudio deveopers."
name=Description>
<META
content="audio, tutorial, library, portable, open-source, DirectSound,sound, music, JSyn, synthesis,"
name=KeyWords>
</HEAD>
<BODY LINK="#0000ff" VLINK="#800080">&nbsp;
<CENTER>
<TABLE bgColor=#fada7a cols=1 width="100%">
<TBODY>
<TR>
<TD>
<CENTER>
<H1>Proposed Changes to PortAudio API</H1>
</CENTER>
</TD></TR></TBODY></TABLE></CENTER>
<P><A href="http://www.portaudio.com/">PortAudio Home Page</A></P>
<P>Updated: January 11, 2002 </P>
<H2>Introduction</H2>
<P>This document describes modifications to the PortAudio API currently being considered by the developer community. It is intended to capture the current state of discussions. The authors are the various members of the PortAudio community and are too numerous to mention. Please refer to the mailing list archives to see who said what. </P>
<P>We are still at the design stage with all of these proposals - if you think something is missing, could be improved, or would just like to comment please do so on the PortAudio mailing list.</P>
<P>&nbsp; <A HREF="http://techweb.rfa.org/mailman/listinfo/portaudio">http://techweb.rfa.org/mailman/listinfo/portaudio</A> </P>
<H2>Contents</H2>
<UL>
<LI><A HREF="#Underflow">PortAudioCallback Underflow/Overflow Handling</A> </LI>
<LI><A HREF="#ImproveDeviceFormatQuerySystem">Improve Device Format Query System</A> * </LI>
<LI><A HREF="#Latency">Improve Latency Mechanisms</A> * </LI>
<LI><A HREF="#AllowCallbackVariableFramesPerBuffer">Allow Callbacks to Accept Variable framesPerBuffer</A> *</LI>
<LI><A HREF="#Blocking">Blocking Read/Write API</A> |C| </LI>
<LI><A HREF="#Interleaved">Non-Interleaved Buffers</A> </LI>
<LI><A HREF="#MultipleDriverModels">Support for Multiple Driver Models in a Single PortAudio Build</A> |C| </LI>
<LI><A HREF="#DriverModelSpecificPa_OpenStream">Driver Model Specific Pa_OpenStream() Parameters</A> |C| </LI>
<LI><A HREF="#Error">Handling of Host-Specific Error Codes</A> * </LI>
<LI><A HREF="#RenamePa_GetCPULoad">Rename Pa_GetCPULoad() and paInvalidDeviceId for Consistency</A> </LI>
<LI><A HREF="#CodingStyleGuidelines">Coding Style Guidelines</A> * </LI>
<LI><A HREF="#AdditionalPa_TerminateBehaviour">Additional Pa_Terminate() Behaviour</A> </LI>
<LI><A HREF="#ReviseInternalHostAPI">Revise Internal Host API</A> *</LI></UL>
<I><P>The proposals above which are marked with a * are under construction, those marked with |</I>C<I>| are essentially complete but require community approval or comment before they are considered complete. The remaining proposals are essentially complete and will be implemented as-is unless significant objections are raised.</P>
</I><H2>Status </H2>
<P>This document describes proposals that range in complexity from clarifications of existing API functionality, through to renaming API functions for consistency, through to significant feature additions. Due to the interdependency of many of the proposed changes, we plan to introduce all API changes simultaneously as part of release 19.</P>
<P>The developer community is in the process of reviewing all proposals. Most proposals are defined in sufficient detail to implement, however some completed proposals are dependent on proposals that are still under construction. Of the remaining unfinished proposals, only <A HREF="#ImproveDeviceFormatQuerySystem">Improve Device Format Query System</A>, <A HREF="#Latency">Improve Latency Mechanisms</A>, <A HREF="#AllowCallbackVariableFramesPerBuffer">Allow Callbacks to Accept Variable framesPerBuffer</A>, and <A HREF="#Error">Handling of Host-Specific Error Codes</A> require significant attention. Both the <A HREF="#CodingStyleGuidelines">Coding Style Guidelines</A> and <A HREF="#ReviseInternalHostAPI">Revise Internal Host API</A> proposals only effect implementors and do not effect the API definition itself. Refinement of these proposals is desirable but not critical to the development of release 19. Interested readers are advised to consult the Dependencies section of each proposal for more detailed information.</P>
<H2>Client Impact</H2>
<P>Some of the proposed changes will break existing client code. Usually these breakages involve renaming of constant identifiers or function calls. In a small number of cases additional parameters will be added to existing API functions. Concerned readers are advised to consult the Impact Analysis section of each proposal for further details.</P>
<P>____________</P>
<H2>PortAudioCallback&nbsp;<A NAME="Underflow"></A>Underflow/Overflow Handling</H2>
<H4>Status</H4>
<P>This proposal is sufficiently well defined to be implemented</P>
<H4>Background</H4>
<P>There are conditions where a full-duplex stream needs to generate output but doesn't have any input available, or where it has too much input so some input needs to be discarded (not passed to the output.) There is also the case where output is needed, but the callback has (transiently) consumed so much CPU time that output has to be generated without the callback being called.</P>
<P>Currently (V17) the PortAudioCallback Function handles these underflow/overflow conditions by passing NULL buffer pointers to the callback. This can happen if the output is pre-rolled and there is not yet any input data. It can also happen if the input underflows. </P>
<P>A number of concerns have been raised about the current system: For PortAudio to discard input just because it is not needed for output is considered unacceptable for some recording applications. Passing of NULL buffer pointers has been deemed to be too error prone and requires too much housekeeping for simple programs. </P>
<P>See <A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-October/000222.html">http://techweb.rfa.org/pipermail/portaudio/2001-October/000222.html</A> and subsequent messages in various threads.</P>
<P>This proposal seeks to keep the PortAudioCallback as simple as possible for ease-of-use while providing full access to overflow/underflow information, and all input and output sample data when clients require it.</P>
<H4>Proposal</H4>
<P>For streams providing input, the inputBuffer parameter will always point to a valid memory location containing framesPerBuffer frames of sample data in the requested format. The inputBuffer parameter will be NULL for output only streams. Similarly, the outputBuffer parameter will be NULL for input only streams, otherwise it will point to a valid memory location containing framesPerBuffer frames of sample data.</P>
<P>A new parameter will be added to the PortAudioCallback Function that gives the status of the data as bit flags. </P>
<TT><PRE>typedef int (PortAudioCallback)(</TT>
<TT>&nbsp; void *inputBuffer, void *outputBuffer,</TT>
<TT>&nbsp; unsigned long framesPerBuffer,</TT>
<TT>&nbsp; PaTimestamp outTime,
unsigned long&nbsp; statusFlags,
void *userData );</TT>
These bits may be set in the statusFlags parameter.
<TT>#define paInputUnderflow&nbsp;&nbsp; (1&lt;&lt;0) /* Input data is all zeros because no real data is available. */</TT>
#define paInputOverflow (1&lt;&lt;1) /* Input data was discarded by PortAudio */
<TT>#define </TT>paOutputUnderflow <TT>(1&lt;&lt;2) </TT>/* Output data was inserted by PortAudio because the callback is using too much CPU */
#define paOutputOverflow (1&lt;&lt;3) <TT>/* Output data will be ignored because no room is available. */</PRE>
</TT><P>&nbsp;</P>
<P>New rules will govern when the <TT>PortAudioCallback</TT> is called:</P>
<UL>
<LI>For input-only streams, the callback will be called for every available input buffer. If the callback takes too long to complete and input samples have to be discarded the paInputOverflow flag will be set the next time the callback is called. In input-only stream will never be called with the paInputUnderflow flag set. </LI>
<LI>For output-only streams, the callback will be called whenever an output buffer needs to be filled, except when doing so would cause the stream to fall further behind real-time due to CPULoad being too high. In such cases PortAudio will insert silence or repeat the previous buffer to the output and the paOutputUnderflow bit will be set next time the callback is called. An output-only stream will never be called with the paOutputOverflow flag set. </LI>
<LI>By default, a full duplex stream will behave according to the same rules as an output-only stream. If input is not available, the paInputUnderflow bit will be set and the input buffers will contain zeros. In the case of an input buffer overflow, PortAudio will discard input - in such cases the input samples will <B>not</B> be passed to a callback, and paInputOverflow will be set next time the callback is called to generate more output. A default full-duplex stream will never be called with the paOutputOverflow flag set. </LI>
<LI>A new mode flag <I>paNeverDropInput</I> to Pa_OpenStream() specifies that a full duplex stream will not discard overflowed input samples without calling the callback. When an input buffer overflow occurs, the callback will be called with the paOutputOverflow flag set, when the callback completes the output buffers will be discarded.</LI></UL>
<P>Note that the default full-duplex mode is intended to cover most common uses of PortAudio, where the client wants a simple audio streaming interface, and is happy to let PortAudio handle buffer underflow/overflow conditions when they occurs.</P>
<H4>Impact Analysis</H4>
<P>This proposal involves adding a new statusFlags parameter to PortAudioCallback. This will require all clients to update their callback implementations accordingly. Clients who previously checked for NULL buffers will be able to remove such checks.</P>
<P>____________</P>
<H2><A NAME="ImproveDeviceFormatQuerySystem">Improve Device Format Query System</A></H2>
<H4>Status</H4>
<P>This proposal is open for discussion.</P>
<H4>Background</H4>
<P>It has been noted that the current method (Pa_GetDeviceInfo()) of querying devices for supported sample formats, channels and sample rates is weak. It does not cleanly differentiate between 'PortAudio supported' formats and 'native' formats, and it is incapable of representing formats where the parameters are interdependent (eg where full duplex is only supported for certain sample rates.) We have also found that a static structure is not a good match for many driver models where format discovery is performed by polling the driver. Even if a sound card supports arbitrary sample rates, the driver model may only allow a client to poll to see whether a rate is available rather than providing the available rate ranges.</P>
<P>It has been noted that most (platform specific) audio APIs do a pretty bad job of allowing for device capability querying. Even the better APIs (ALSA is perhaps one) don't necessarily provide accurate information. This proposal should seek to maximise the amount of information that can be extracted from existing APIs while remaining expressive enough to take full advantage of APIs with more advanced capability querying systems should they become available in the future.</P>
<H4>Proposal</H4>
<P>A number of options are being considered with regard to supplying clients with format information:</P>
<P>Use PaDeviceInfo only for representing information that can be expressed without polling the driver multiple times, or only check for "standard" formats, or leave it unchanged.</P>
<P>And/Or</P>
<P>Add a Pa_IsFormatSupported() function:</P>
<PRE>Pa_IsFormatSupported( PaDeviceID inputDevice,
int numInputChannels,
PaSampleFormat inputSampleFormat,
void *inputDriverInfo,
PaDeviceID outputDevice,
int numOutputChannels,
PaSampleFormat outputSampleFormat,
void *outputDriverInfo,
double sampleRate );</PRE>
<H4>Discussion</H4>
<P>At present it seems desirable to retain Pa_GetDeviceInfo() and the PaDeviceInfo structure. At a minimum PaDeviceInfo needs to contain name and driver model type code fields:</P>
<PRE>typedef struct{
int structVersion;
const char *name;
PaDriverModelTypeCode driverModel;
} PaDeviceInfo;</PRE>
<P>It was suggested that we could do things the way MME does: if Pa_OpenStream() is called with a NULL stream parameter then the stream isn't opened, but it is checked to see if the device supports the specified format - if the format is supported then paNoError would be returned, otherwise an error code would be returned. However, this has been ruled to be unsatisfactory, since querying for supported formats is really a different function from opening a stream.</P>
<H4>Impact Analysis</H4>
<P>This proposal will provide clients with more expressive methods for querying device capabilities, which should improve the utility of PortAudio. It is not yet clear what the full impact of this proposal will be.</P>
<P>____________</P>
<H2><A NAME="Latency"></A>Improve Latency Mechanisms</H2>
<H4>Status</H4>
<P>This proposal is open for discussion.</P>
<H4>Background</H4>
<P>The current mechanism for setting latency is not considered optimal by all clients of the API. There seems to be some tension between using the framesPerBuffer parameter of Pa_OpenStream as a latency control parameter and as a specifier for the number of frames supplied to the callback. Specifying latency as a single millisecond value would be more user friendly for some users, however some driver models need latency to be tuned by specifying buffer sizes and number of buffers. Additionally, it not clear whether separate input and output buffer counts would allow tuning of lower latencies in some circumstances.</P>
<P>A related issue is the need to improve the interface available to determine default latency parameters. The most recent proposal is documented below, however there is still some debate as to whether this is satisfactory. </P>
<P>See this thread: <A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-October/000196.html">http://techweb.rfa.org/pipermail/portaudio/2001-October/000196.html</A> </P>
<H4>Proposal</H4>
<P>The numBuffers parameter for Pa_OpenStream() could accept the following values in addition to the normal N&gt;0 values.&nbsp; Use PA_LATENCY_LOW for interactive performance, when response time is critical.&nbsp; Use PA_LATENCY_HIGH when playing sound files or other non-interactive uses, when glitch free operation is more critical. </P>
<PRE>
#define PA_LATENCY_WHATEVER&nbsp;&nbsp; (0) /* or _NO_OPINION or? */
#define PA_LATENCY_LOW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-1)&nbsp; /* For interactive performance. */
#define PA_LATENCY_HIGH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-2)&nbsp; /* For playing sound files. */</PRE>
<P>Currently, when numBuffers&gt;0, Pa_OpenStream will constrain the actual numBuffers so that the latency is within a valid range determined by the driver, or an environment variables such as PA_MIN_LATENCY_MSEC. Propose changing the behaviour so that the requested value is honoured as much as possible. This will allow the user to override the minimum if they know their system can handle it. This might be used, for example on patched Linux kernels. By doing this we simplify the implementations and eliminate the need for adding a Pa_SetMinimumLatency() function. </P>
<PRE>
/* Negative return values are (double) paError */
double Pa_GetMinimumLatency( int deviceId, double frameRate );
double Pa_GetPreferredLatency( int deviceId, double frameRate );
double Pa_GetMaximumLatency( int deviceId, double frameRate );
/* the following would operate directly on streams */
double Pa_StreamInputLatency( PortAudioStream *stream );
double Pa_StreamOutputLatency(PortAudioStream *stream );</PRE>
<H4>Discussion</H4>
<P>This proposal does not yet address the question of whether there needs to be separate numInputBuffers and numOutputBuffers parameters for optimal latency specification.</P>
<P>____________</P>
<H2><A NAME="Blocking"><A NAME="AllowCallbackVariableFramesPerBuffer"></A>Allow Callbacks to Accept Variable framesPerBuffer</A></H2>
<H4>Status</H4>
<P>This proposal is under construction.</P>
<B><P>Background</B><BR>
<BR>
Some devices prefer, or even require, a particular value for framesPerBuffer. Some applications also prefer a particular buffer size because they may, for example, be doing FFTs. If possible, an integral number of application buffers can be fit into a device buffer. If an integral number of application buffers cannot be fit into an application buffer then some system for adapting between them is required. Stephane Letz implemented a block adapter for the ASIO driver that could perhaps be made part of a utility library for PortAudio.<BR>
<BR>
Adapting between different block size, unfortunately, involves extra memory movement and should be avoided. One way to avoid this is to allow an application to say "I can handle any value for framesPerBuffer". An example would be a simple algorithm like the one in "pa_tests/pa_fuzz.c". Its callback function could easily work with any value for FramesPerBuffer.<BR>
<BR>
<B>Proposal</B><BR>
<BR>
Pa_OpenStream() should be able to accept a zero value for framesPerBuffer. When framesPerBuffer is zero, the implementation can choose any value that it thinks will work best given the other constraints. That value will be passed to the user callback.<BR>
<BR>
To make the code more obvious, this constant could be used:<BR>
<BR>
<FONT FACE="Courier New" SIZE=2>#define paFramesPerBufferUnspecified (0)</FONT><BR>
<BR>
In order to find out what value the implementation chose, and also to help the application determine the actual latency, the following calls could be added:<BR>
<BR>
<FONT FACE="Courier New" SIZE=2>int Pa_GetFramesPerBuffer( PortAudioStream* stream );<BR>
int Pa_GetNumOutputBuffers( PortAudioStream* stream );<BR>
int Pa_GetNumInputBuffers( PortAudioStream* stream );</FONT><BR>
</P>
<P>____________</P>
<H2>Blocking Read/Write API</H2>
<H4>Status</H4>
<P>This proposal is open for comment.</P>
<H4>Background</H4>
<P>Many PortAudio users have requested a blocking read()/write() API that will be supported in addition to the current callback based API. A blocking Read/Write API would allow a more natural style of multi-threaded programming, and facilitate single-threaded reactive applications, while insulating clients from platform-specific thread synchronisation facilities. </P>
<P>A blocking read/write API would also be useful when binding PortAudio to languages that don't easily support callbacks such as Python, Java, Lisp and Smalltalk. However in this case it has been noted that a blocking API is not sufficient - the host language also needs to support native threads to interact efficiently with blocking. Dannenberg observes that native thread support cannot be added without major redesign (based on a study of Python and Squeak), but given blocking calls, there are several ways to structure programs using non-native threads.</P>
<P>Adding a blocking Read/Write interface to PortAudio has been discussed on a number of occasions, including the following threads:</P>
<P><A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-August/000063.html">http://techweb.rfa.org/pipermail/portaudio/2001-August/000063.html</A> a long thread about blocking calls.</P>
<P><A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-August/000137.html">http://techweb.rfa.org/pipermail/portaudio/2001-August/000137.html</A> this is Roger Dannenberg's proposal and a subsequent discussion</P>
<P><A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-August/000144.html">http://techweb.rfa.org/pipermail/portaudio/2001-August/000144.html</A> is a thread discussing using blocking APIs with other languages</P>
<H4>Proposal</H4>
<P>If a NULL callback parameter is passed to Pa_OpenStream() then the stream will be opened in blocking mode. This enables users to call Pa_WriteStream() and Pa_ReadStream() to read and write sample data. (The PaErrorNum item "paNullCallback" becomes obsolete.)</P>
<P>Pa_WriteStream() writes a buffer of frames to a stream. The length of the buffer is arbitrary and specified by the frames parameter. Pa_WriteStream() returns when all samples have been copied from buffer. If necessary, Pa_WriteStream() will wait until buffer space becomes available. (Waiting on Unix will be the by-product of an I/O system call, waiting in Win32 will be implemented by waiting on an Event object, and waiting on MacOS 9 will probably require a busy wait.) High performance applications will want to match the length of the buffer to framesPerBuffer, but this is not a requirement.</P>
<P>The buffer parameter has the same semantics and format as the inputbuffer and outputbuffer parameters of a PortAudioCallback function. In particular, non-interleaved data is handled in the same way.</P>
<P>Pa_ReadStream() is similar, but it reads rather than writes. </P>
<PRE>PaError Pa_WriteStream( PortAudioStream *stream,
void *buffer,
unsigned long frames );
PaError Pa_ReadStream( PortAudioStream *stream,
void *buffer,
unsigned long frames );</PRE>
<P>Pa_ReadStream() returns <I>paInputUnderflow</I> if input data was discarded by PortAudio after the previous call and before this call. Pa_WriteStream() returns <I>paOutputUnderflow</I> if output data was inserted after the previous call and before this call. The mode flag <I>paNeverDropInput</I> is ignored because Pa_ReadStream() and Pa_WriteStream() are not synchronized.</P>
<P>There are two functions to determine the number of frames available for writing and reading. These functions may be called to determine whether calls to Pa_WriteStream() or Pa_ReadStream() will return immediately or will wait. The return value, if non-negative, is the maximum number of frames that can be written or read without blocking or busy waiting. A negative value is a PaErrorNum.</P>
<PRE>long Pa_StreamWriteAvailable( PortAudioStream *stream );
long Pa_StreamReadAvailable( PortAudioStream *stream );</PRE>
<P>The stream functions Pa_CloseStream(), Pa_StartStream(), Pa_StopStream(), Pa_AbortStream(), Pa_StreamActive(), and Pa_StreamTime() work with the blocking API as well as with callbacks. Pa_StreamCPULoad() does not work with the blocking API. PortAudio might be extended to give applications access to the internal routines that compute Pa_StreamCPULoad(). Applications using blocking calls could then bracket audio computation with these calls to determine the CPU load. (This additional functionality is not being proposed here.)</P>
<H4>Discussion</H4>
<P>A rejected alternative is to allow Pa_WriteStream() and Pa_ReadStream() to return the number of frames actually written or read so that a Mac implementation could return immediately and avoid blocking. This would require applications to be prepared to handle partial read/writes. It seems simpler and more consistent to use "Available" to determine in advance whether blocking or busy waiting will occur if that is a concern. Also, note that data is almost certainly copied; however, it seems likely that the copy will be folded into any format conversion.</P>
<P>Implementations may want to provide a way for applications to be notified when data can be written or read. For example, one might want to know the file ID of an ALSA or OSS stream for use in a select() system call. Since this sort of information will be platform-specific and non-portable, no interface is defined here, but implementations can include a device-model-specific access function. If applications commonly need this information, we can think about how to make this more standardized.</P>
<H4>Implementation Notes</H4>
<P>Implementing blocking i/o will be quite simple for driver models where the underlying API is blocking-based. Under Windows (MME), the arrival of a buffer will signal an Event passed to waveOutOpen(). Pa_WriteStream() and Pa_ReadStream() will do all the work (no server threads necessary). Writes will make waveOutWrite calls. When no buffer is available, the writer will wait on the event and try again. Reading is similar. On the Mac, a double-buffer scheme can be set up where the Mac callbacks pick up data placed in buffers by Pa_WriteStream(). The double-buffer adds to the latency. Alternatively (and preferably) callbacks can be used only for notification, and Pa_WriteStream() can issue all the calls to write samples.</P>
<P>PABLIO currently contains a busy-wait ring buffer in "ringbuffer.c" which is generic, used in many projects and is pretty solid. This code could be a useful starting point for implementing the new blocking API on some platforms.</P>
<P>Pa_WriteStream() and Pa_ReadStream() are not thread safe. Applications wanting to call these from multiple threads should manage their own mutual exclusion. <I>[Roger: Is any of PortAudio thread safe? I don't think so. This is good because it avoids many system calls for mutual exclusion.]</P>
</I><P>At one time it was suggested that implementations only implement blocking calls and that callbacks would be required to implement callbacks in terms of the blocking API. The current direction is that this decision should be made independently for each driver-model.</P>
<H4>Impact Analysis</H4>
<P>This proposal would extend the functionality of PortAudio without requiring any changes to client code with the exception that the PaErrorNum paNullCallback will no longer be defined. As noted above, implementation complexity is dependent on the target platform.</P>
<P>____________</P>
<H2>Non-<A NAME="Interleaved"></A>Interleaved Buffers</H2>
<H4>Status</H4>
<P>This proposal is sufficiently well defined to be implemented. No objections have been raised.</P>
<H4>Background</H4>
<P><A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-October/000210.html">http://techweb.rfa.org/pipermail/portaudio/2001-October/000210.html</A> </P>
<P>Some native APIs use non-interleaved buffers, particularly those that support N&gt;2 channels. Additionally, many client applications use non-interleaved buffers internally. In order to avoid adding unnecessary overhead, PortAudio should support both interleaved and non-interleaved buffers on all platforms. </P>
<P>The current PortAudio/ASIO implementation works as follows : ASIO native buffers are non-interleaved and the de-interleaving, format conversion and copying the data into PortAudio interleaved buffers is done in one loop. But if PortAudio supported non-interleaved buffers then we could use efficient vector operations even for native buffer &lt;==&gt; port audio buffers transfers. </P>
<H4>Proposal</H4>
<P>A new sample format could be defined: </P>
<PRE>#define paNonInterleaved ((PaSampleFormat) (1&lt;&lt;31)) </PRE>
<P>&nbsp;</P>
<P>This could be used as a modifier flag to the buffer format fields of Pa_OpenStream(). When present, this flag would indicate that non-interleaved buffers would be passed to the callback. When not present, interleaved buffers would be used as is currently always the case. For example, the following code would open an interleaved stream:</P>
<PRE>
Pa_OpenStream(&amp;stream,
paNoDevice,
0,
paFloat32
NULL,
Pa_GetDefaultOutputDeviceID(),
2,
paFloat32,
NULL,
SAMPLE_RATE,
FRAMES_PER_BUFFER,
0,
paClipOff,
patestCallback,
&amp;data );</PRE>
<P>And the following code would open a non-interleaved stream:</P>
<PRE>
Pa_OpenStream(&amp;stream,
paNoDevice,
0,
paFloat32|paNonInterleaved,
NULL,
Pa_GetDefaultOutputDeviceID(),
2,
paFloat32|paNonInterleaved,
NULL,
SAMPLE_RATE,
FRAMES_PER_BUFFER,
0,
paClipOff,
patestCallback,
&amp;data );</PRE>
<P>In the user callback, the application would be passed a pointer to an array of buffers. The left and right buffers of a non-interleaved stream could be accessed as follows: </P>
<PRE>
float *left = ((float **) inputBuffer)[0];
float *right = ((float **) inputBuffer)[1];</PRE>
<P>This new sample format could also be used to interrogate the native driver to see if it supports interleaved or non-interleaved buffers. This would be achieved by reading the nativeSampleFormats field of the PaDeviceInfo structure. </P>
<H4>Impact Analysis</H4>
<P>This proposal extends the functionality of PortAudio without any impact on existing client code. It will require new conversion functions and all existing PortAudio implementations will have to be modified to reference these new conversion functions.</P>
<P>____________</P>
<H2><A NAME="MultipleDriverModels">Support For Multiple Driver Models</A> in a Single Build</H2>
<H4>Status</H4>
<P>This proposal is currently being discussed. Its final form depends on a number of other unfinished proposals.</P>
<H4>Dependencies </H4>
<P>The API changes described in this proposal are independent of all other proposals. However, changes to the host error mechanism defined in <A HREF="#Error">Handling of Host-Specific Error Codes</A>, and the addition of new API functions due to the <A HREF="#Blocking">Blocking Read/Write API</A> proposal may effect the implementation of this proposal. Changes to the API defined by the <A HREF="#ImproveDeviceFormatQuerySystem">Improve Device Format Query System</A> and the <A HREF="#Latency">Improve the Latency Setting Mechanism</A> proposals will need to be multi-driver-model capable. </P>
<H4>Background</H4>
<P>As the number of supported driver models available on each platform grows (WMME, ASIO, and DirectSound under Windows for example) client applications need to be able to select between different driver models at run-time. At least four platforms supported by PortAudio have multiple native driver models. At present PortAudio allows clients to link in support for at most one driver model.</P>
<P>This proposal is based this email: <A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-December/000308.html">http://techweb.rfa.org/pipermail/portaudio/2001-December/000308.html</A></P>
<H4>Requirements</H4>
<P>It will be necessary to supply clients with a method of displaying a textual description of the driver model for each PortAudio device.</P>
<P>Some PortAudio functions do not operate on PortAudioStreams, but rather they operate on or return the global state of the PortAudio library as a whole. If multiple driver-models were present, some of these functions would have different implementations, or would return different values depending on which the driver model they applied to. These functions include:</P>
<PRE> int Pa_GetMinNumBuffers( int framesPerBuffer, double sampleRate );
PaDeviceID Pa_GetDefaultInputDeviceID( void );
PaDeviceID Pa_GetDefaultOutputDeviceID( void );
</PRE>
<P>Note that Pa_CountDevices() could also be interpreted as applying to a specific driver model.</P>
<P>PortAudio currently implements a per-driver-model extension mechanism via the inputDriverInfo and outputDriverInfo parameters to Pa_OpenStream(). For code to take advantage of driver-model-specific extensions when multiple driver models are present there needs to be a way to establish which (statically named) driver model is associated with each device. This is because driver-model-specific extensions should only be used in combination with devices supplied by that driver model.</P>
<P>PortAudio should present clients with all of the devices made available by each driver model. This means that some physical devices may be accessible though multiple driver models. Since it will not be possible to open a full duplex stream with input and output devices from different driver models, some clients may want to enumerate the available driver models and only display devices from one driver model at a time.</P>
<P>Introducing a new PortAudioDriverModel abstraction could fulfil the above requirements. At a minimum, this abstraction would need to have the following attributes:</P>
<UL>
<LI>A textual description for display on user interfaces </LI>
<LI>Functions for querying default device ids and latency parameters for each driver model </LI>
<LI>A unique identifier published in portaudio.h for use in code which takes advantage of driver model specific extensions</LI></UL>
<P>Additionally, the following features could be present:</P>
<UL>
<LI>A method for querying the default PortAudioDriverModel (perhaps the "best" driver model which has more than 0 devices available) </LI>
<LI>A method for enumerating 'currently available' PortAudioDriverModels. 'Currently available' could be interpreted as meaning the driver models linked into the current PortAudio implementation, or it could mean the driver models which currently have more than zero devices available. </LI>
<LI>A method of enumerating PortAudioDevices independently for each available PortAudioDriverModel</LI></UL>
<H4>Proposal</H4>
<P>This proposal consists of the 7 modifications to the PortAudio API listed below.</P>
<P>1. Define a new PaDriverModelTypeID enumeration, with fixed values for each driver model:</P>
<PRE>
/*
The PaDriverModelTypeID enumeration contains constants for uniquely
Identifying each driver model supported by PortAudio. This type
is used in the PaDriverModelInfo structure below. Driver model type ids
are guaranteed to never change, thus allowing code to be written that
conditionally uses driver model specific extensions.
New type ids will only be allocated when support for a new driver
model reaches "public alpha" status, prior to that developers should
use the paInDevelopment type id.
*/
typedef enum {
paInDevelopment=0, /* use while developing support for a new driver model */
paWin32DirectSound=1,
paWin32MME=2,
paWin32ASIO=3,
paMacOSSoundManager=4,
paMacOSCoreAudio=5,
paMacOSASIO=6,
paOSS=7,
paALSA=8,
paIRIXAL=9,
paBeOS=10
}PaDriverModelTypeID;</PRE>
<P>2. Define a method for enumerating driver models:</P>
<PRE>
/*
Driver model enumeration mechanism.
Driver model ids range from 0 to Pa_CountDriverModels()-1.
The default driver model is the lowest common denominator
driver model on the current platform and is unlikely to provide
the best performance.
*/
typedef int PaDriverModelID;
#define paDefaultDriverModel 0;
struct{
int structVersion;
PaDriverModelTypeID typeID; /* the well known unique identifier of this driver model */
const char *name; /* a textual description of the driver model for display on user interfaces */
}PaDriverModelInfo;
PaDriverModelID Pa_CountDriverModels();</PRE>
<P>3. Provide a method for retrieving information about a given driver model:</P>
<PRE>
/*
Pa_ GetDriverModelInfo () returns a pointer to an immutable
PaDriverModelInfo structure referring to the device specified by driverModelID.
If driverModelID is out of range the function returns NULL. The returned structure
is owned by the PortAudio implementation and must not be manipulated or
freed. The pointer is only guaranteed to be valid between calls
to Pa_Initialize() and Pa_Terminate().
*/
const PaDriverModelInfo* Pa_GetDriverModelInfo( PaDriverModelID driverModelID );</PRE>
<P>4. Add a new field to PaDeviceInfo to identify the driver model type:</P>
<PRE>
struct{
...
PaDriverModelID driverModel; /* note this is the run-time id */
...
}PaDeviceInfo;</PRE>
<P>This would enable the following two code fragments to be written.</P>
<PRE>
/* obtain the user-readable name of a device's driver model */
Pa_GetDriverModelInfo( deviceInfo-&gt;driverModel )-&gt;name;
/* implement special behavior for a specific driver model */
if( Pa_GetDriverModelInfo( deviceInfo-&gt;driverModel )-&gt;typeID == paWin32MME ){
InitialiseMMESpecificDeviceInfo();
}</PRE>
<P>5. Provide methods for finding per-driver model default devices and latency settings:</P>
<PRE>
PaDeviceID Pa_DriverModelDefaultInputDeviceID( PaDriverModelID driverModelID );
PaDeviceID Pa_DriverModelDefaultOutputDeviceID( PaDriverModelID driverModelID );
int Pa_DriverModelMinNumBuffers( PaDriverModelID driverModelID, int framesPerBuffer, double sampleRate );</PRE>
<P>6. Provide functions for enumerating devices on a per-driver-model basis. Note that this functionality is provided in addition to the current Pa_CountDevices() and Pa_GetDeviceInfo() functions:</P>
<PRE>
int Pa_DriverModelCountDevices( PaDriverModelID driverModelID );
PaDeviceID Pa_DriverModelGetDeviceID( PaDriverModelID driverModelID, int perDriverModelIndex );</PRE>
<P>7. Re-implement the following existing functions to use the default driver model. This would be a backwards compatible change except for Pa_GetMinNumBuffers() which gains an extra parameter.</P>
<PRE>
PaDeviceID Pa_GetDefaultInputDeviceID( void ); /* returns the default device id for the default driver model */
PaDeviceID Pa_GetDefaultOutputDeviceID( void );
int Pa_GetMinNumBuffers( PaDeviceID id, int framesPerBuffer, double sampleRate );</PRE>
<P>Note that Pa_GetMinNumBuffers() takes a device id, not a driver model id. This minimises the need for clients to be aware of the multiple driver model extensions. </P>
<H4>Discussion</H4>
<P>The main disadvantage of this proposal it that it may make the API seem more complex for new users.</P>
<P>There is concern that this proposal is too complex, and that the simpler solution of simply adding a driverModel string to the device info structure of each device would be sufficient. It is true that the simple solution would allow clients to duplicate the functionality of this proposal, provided driverModel strings were published and guaranteed not to change in the future. However, the bulk of the functionality included in this proposal will need to be implemented internally to facilitate multiple driver model support anyway. This proposal is based on the assumption that it is better to expose such functionality in the PortAudio API rather than require clients to reimplement what is already present internally. </P>
<P>There has been discussion about supporting "pluggable" driver models - the general idea is that a client application could link against PortAudio and PortAudio would load the available Driver Models at run-time using "PortAudio Driver Model Plugins." Some people consider this to be an overly complex solution, and no significant advantages over a monolithic PortAudio dll have been submitted yet. Some people would like PortAudio to always be able to be statically linked with multiple driver model support.</P>
<P>The overhead (both processor and memory) of the Multiple Driver Model support should be minimised on platforms which don't have multiple driver models (such as BeOS and some handheld devices.) Essentially this means that the functionality provided in the multiple driver model fa&ccedil;ade should be easy to duplicate.</P>
<H4>Implementation Notes</H4>
<P>The implementation will follow the methodology currently employed in PortMIDI described here: <A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-December/000295.html">http://techweb.rfa.org/pipermail/portaudio/2001-December/000295.html</A></P>
<P>An implementation of the driver model neutral "Fa&ccedil;ade" of this proposal exists here: </P>
<P><A HREF="http://www.portaudio.com/docs/pa_drivermodel.c.txt">http://www.portaudio.com/docs/pa_drivermodel.c.txt</A></P>
<P><A HREF="http://www.portaudio.com/docs/pa_drivermodel.h.txt">http://www.portaudio.com/docs/pa_drivermodel.h.txt</A></P>
<P>This proposal will involve the changes described below. Note that the string &lt;DM&gt; will be replaced with a driver model tag for each implementation.</P>
<P>Each driver model will have it's own Initialize function which PortAudio will call in response to client calls to Pa_Initialize and Pa_Terminate respectively. This will be the only identifier each driver model implementation will be required to expose.</P>
<PRE>PaError Pa&lt;DM&gt;_MultiDriverInitialize( PaDriverModelImplementation **impl );</PRE>
<P>PaDriverModelImplementation is an internal data structure containing a set of function pointers for globally relevant functions: (function pointer type declarations omitted for simplicity:)</P>
<PRE>struct{
fptr terminate; /* takes the PaDriverModelImplementation* returned by initialize */
fptr getDriverModelInfo;
fptr getHostError;
fptr getHostErrorText;
fptr countDevices;
fptr getDefaultInputDeviceID;
fptr getDefaultOutputDeviceID;
fptr getDeviceInfo;
fptr openStream;
fptr getMinNumBuffers;
} PaDriverModelImplementation;</PRE>
<P>The function pointers in PaDriverModelImplementation will point to the corresponding functions in current PortAudio implementations. The new multiple driver model support code will take care of mapping per-driver model device ids onto a single homogenous driver id range. A significant advantage of this scheme is that it will require very little change to existing PortAudio implementations.</P>
<P>A new PaStreamImplementation internal data structure will be defined to contain function pointers to implementations of the stream functions for each driver model. This structure will be placed at the head of implementation-specific data structures returned as PortAudioStream* in current implementations.</P>
<PRE>struct{
unsigned long magic;
fptr close;
fptr start;
fptr stop;
fptr abort;
fptr read;
fptr write;
fptr readAvailable;
fptr writeAvailable;
fptr active;
fptr time;
fptr cpuLoad;
} PaStreamImplementation;</PRE>
<P>Magic contains a unique bit pattern which should be set by implementations when a stream is opened, and cleared when it is closed. This technique will allow implementations to perform some degree of validation on PortAudioStream* passed to PortAudio.</P>
<H4>Impact Analysis</H4>
<P>This proposal will significantly improve the utility of PortAudio by allowing clients to support multiple driver models in a single executable. </P>
<P>The only required change for existing clients will to insert an extra deviceID parameter into calls to Pa_GetMinNumBuffers().</P>
<P>Since multiple driver models may return devices with the same names, a minimum requirement for clients who want to be "multiple driver model aware" will be to ensure that the appropriate driver model name is displayed alongside device names in the user interface.</P>
<P>____________</P>
<H2><A NAME="DriverModelSpecificPa_OpenStream">Driver Model Specific Pa_OpenStream() Parameters</A></H2>
<H4>Status</H4>
<P>This proposal is essentially complete, but is pending the final definition of PaDriverModelTypeID (see below.) </P>
<H4>Dependencies</H4>
<P>If the PaDriverModelSpecificStreamInfo structure defined in this proposal includes a PaDriverModelTypeID driver model identifier, then this proposal depends on the <A HREF="#MultipleDriverModels">Support for Multiple Driver Models in a Single PortAudio Build</A> proposal to define the form of the identifier.</P>
<H4>Background</H4>
<P>Pa_OpenStream has always had the inputDriverInfo and outputDriverInfo parameters, which were defined to support passing driver-model specific information to PortAudio implementations. Currently these parameters are defined as void* and are not used by any implementation. Two uses of inputDriverInfo and outputDriverInfo are planned for the near future: passing device names to OSS drivers, and passing additional device ids for opening multichannel soundcards under MME.</P>
<H4>Proposal</H4>
<P>The following structure could be defined and be placed at the head of all data structures passed to the inputDriverInfo and outputDriverInfo parameters of Pa_OpenStream:</P>
<PRE>struct{
unsigned long size; /* size of whole structure including this header */
PaDriverModelTypeID driverModel; /* driver model for which this data is intended */
unsigned long version; /* structure version */
}PaDriverModelSpecificStreamInfo;</PRE>
<P>The following driver model specific extensions should be placed in separate header files rather than being placed in portaudio.h</P>
<P>___</P>
<P>The following structure is proposed for passing device names to the OSS implementation:</P>
<PRE>struct{
PaDriverModelSpecificStreamInfo header;
char *deviceName;
}PaOSSSpecificStreamInfo;</PRE>
<P>A pointer to this structure could be passed to Pa_OpenStream() to request that a device other than the default dsp device be opened. This structure could be used for opening input and/or output devices.</P>
<P>___</P>
<P>The following structure is proposed for passing multiple interleaved device ids to the MME implementation in order to open a multichannel stream with some soundcards that support multichannel operation via multiple stereo (or other number of channels) interleaved devices. When this structure is passed, the MME implementation would ignore the deviceId parameters passed directly to Pa_OpenStream(), however it would not ignore the channelCount parameters.</P>
<P>#define paWMMEPassMultipleInterleavedBuffers 0x01 /* a flag */</P>
<PRE>struct{
PaDriverModelSpecificStreamInfo header;
int *deviceIdsAndChannelCounts; /* interleaved deviceIds and channelCounts */
int deviceCount;
int flags;
}PaMMESpecificStreamInfo;</PRE>
<P>The deviceIdsAndChannelCounts field points to an array of ints containing multiple {deviceId, channelCount} pairs. The number of integer elements in the array must be two times the value of the deviceCount field. Specified deviceIds must have a driver model type of Windows MME. Currently only one flag is defined: paWMMEPassMultipleInterleavedBuffers, this can be used to request that the raw, multiple interleaved buffers be passed to the callback.</P>
<H4>Discussion</H4>
<P>The type of the inputDriverInfo and outputDriverInfo parameters could be changed to PaDriverModelSpecificStreamInfo* however this may cause more trouble that it's worth.</P>
<P>The PaMMESpecificStreamInfo functionality may require the common buffer conversion functions defined in the <A HREF="#ReviseInternalHostAPI">Revise Internal Host API</A> proposal to support (multiple interleave &lt;==&gt; unified interleave) and (multiple interleave &lt;==&gt; non-interleaved) conversions.</P>
<H4>Impact Analysis</H4>
<P>This proposal provides access to new platform-specific extensions. No existing client code will be modified. Only implementations that implement the extensions will be effected.</P>
<P>____________</P>
<H2><A NAME="Error"></A>Handling of Host-Specific Error Codes</H2>
<H4>Status</H4>
<P>This proposal is sufficiently well defined to be implemented immediately. However, the possibility of extending the scope of this proposal is being discussed in this thread: <A HREF="http://techweb.rfa.org/pipermail/portaudio/2002-January/000358.html">http://techweb.rfa.org/pipermail/portaudio/2002-January/000358.html</A></P>
<H4>Background</H4>
<P>Currently the PaHostError error code is used to notify clients that a platform-specific error condition occurred. This is considered ambiguous and difficult to work with. </P>
<H4>Proposal</H4>
<P>PortAudio should seek to avoid returning ambiguous paHostError error codes, and instead translate to portable PortAudio error codes instead. In the case of the pa_win_mme implementation this means translating the following MME error codes:</P>
<P>MMSYSERR_ALLOCATED to paDeviceBusy (new) <BR>
MMSYSERR_BADDEVICEID to paInvalidDeviceId (already defined) <BR>
MMSYSERR_NODRIVER to paDriverMissing (new) <BR>
MMSYSERR_NOMEM to paInsufficientMemory (already defined) <BR>
WAVERR_BADFORMAT to paSampleFormatNotSupported (already defined) </P>
<H4>Discussion</H4>
<P>It is suggested that all implementations should be audited for their use of PaHostError.</P>
<P>There was some concern about polluting the PortAudio error code namespace with platform-specific error codes, and of the potential overhead of including platform specific error strings on other platforms. Another suggestion has been to add a Pa_GetHostErrorText() function.</P>
<P>If all error codes are mapped to PortAudio error codes do we need a PaHostError code and the Pa_GetHostErrorCode() function?</P>
<P>A suggestion has been made to extend Pa_GetErrorText() so that it retrieved driver model specific error strings when a host error occurs.</P>
<H4>Impact Analysis</H4>
<P>This proposal improves the quality of PortAudio diagnostics. Client code that depends on paHostError code to flag certain conditions may be effected.</P>
<P>____________</P>
<H2><A NAME="RenamePa_GetCPULoad">Rename Pa_GetCPULoad() </A>and paInvalidDeviceId for Consistency</H2>
<H4>Status</H4>
<P>Proposal is sufficiently well defined to be implemented. No objections have been raised.</P>
<H4>Background</H4>
<P>PortAudio functions that return global information typically have names of the form Pa_Get*() (eg. Pa_GetDeviceInfo). Almost all functions operating on PortAudio streams conform to the following implicit naming convention: Pa_*Stream( stream ) performs an action on a stream (eg Pa_StartStream() ) and Pa_Stream*( stream ) returns a stream attribute (eg. Pa_StreamTime() ). The only exception to this convention is the confusingly named Pa_GetCPULoad() which actually returns the CPU consumption of a particular stream's callback. </P>
<P>PortAudio functions and parameter names that operate on integer identifiers use the string ID (all uppercase.) The paInvalidDeviceId error code is an exception to this convention.</P>
<H4>Proposal</H4>
<P>Rename PaGetCPULoad() to Pa_StreamCPULoad() in order to conform to the established naming conventions.</P>
<P>Rename the paInvalidDeviceId error code to paInvalidDeviceID to conform to the established naming conventions.</P>
<H4>Impact Analysis</H4>
<P>This proposal improves the consistency of the naming scheme making the API easier to learn and remember. All clients which call Pa_GetCPULoad() will need to alter their code by renaming the function call. Clients who explicitly check for the paInvalidDeviceId error code will have to edit its capitalisation.</P>
<P>____________</P>
<H2><A NAME="CodingStyleGuidelines">Coding Style Guidelines</A></H2>
<H4>Status</H4>
<P>This proposal is under construction. Further suggestions and comments would be extremely welcome.</P>
<H4>Background</H4>
<P>Since the PortAudio code is commonly edited on many different platforms using different editors it has been suggested that some conventions be adopted to improve readability and consistency. The general opinion is that the definition of such conventions, and their enforcement shouldn't be too extreme. There are also a number of unspoken implementation standards that could be usefully written down. This proposal consists of a list of mechanical formatting conventions, and a list of "quality of implementation" conventions. When completed this proposal will packaged with the distribution and placed on the web site as "Coding Style Guidelines for PortAudio Implementors."</P>
<H4>Proposal</H4>
<P>The following formatting conventions should be adhered to in all PortAudio code:</P>
<UL>
<LI>TABs should not be used in .c and .h files; instead 4 spaces should be used. Makefiles should continue to use TABs since this is required by Make </LI>
<LI>Adopt a consistent set of rules for placement of braces (see note regarding Astyle below) </LI>
<LI>Adopt a consistent policy for line-end characters. This could be 'use CR on Mac, CRLF on Windows and LF on Unix' or it could be 'use Unix style new-lines in all source files.</LI></UL>
<P>AStyle ( <A HREF="http://astyle.sourceforge.net/">http://astyle.sourceforge.net/</A> ) has been proposed as helpful tool for cleaning code, however we haven't yet decided whether to use it on an ongoing basis. Once our style guidelines have been established it is expected that contributors of each implementation will take responsibility for keeping their code clean, as an automated tool applied by someone unfamiliar with the code will probably just mess things up.</P>
<P>In addition to the formatting conventions noted above, the following "quality of implementation" coding guidelines are being proposed to establish a quality baseline for our implementations:</P>
<UL>
<LI>All code should be written in C++-compatible plain ANSI-C (i.e. no // comments). The following guideline has been proposed: should compile silently with both "gcc -ansi -pedantic -Wall" and "g++ -ansi -pedantic -Wall" </LI>
<LI>Think of PortAudio as a heavyweight library rather than a lightweight wrapper. Always code defensively. Efficiency is important where it matters (eg in real-time callbacks) but safety is important everywhere. </LI>
<LI>All parameters passed to PortAudio by the user should be validated, and error codes returned where necessary. All reasonable efforts should be made to minimise the risk of a crash resulting from passing incorrect parameters to PortAudio. </LI>
<LI>Error handling should be complete. Every host function that can return an error condition should have its status checked. PortAudio may attempt to recover from errors, but generally error codes should be returned to the client. </LI>
<LI>In almost all cases, a PortAudio error code should be preferred to returning PaHostError. If a new PortAudio error code is needed it should be discussed with the maintainer to coordinate updating port_audio.h </LI>
<LI>PortAudio code should not cause resource leaks. After Pa_Terminate() is called, implementations should guarantee that all dynamically allocated resources have been freed. </LI>
<LI>The definition of the PortAudio API should minimise "implementation defined behaviour". For example, calling functions such as Pa_Initialize() after PortAudio is initialised, or Pa_Terminate() after PortAudio has been terminated should have well defined behaviour. (In this example, both calls should be safe and simply return an error code.) </LI>
<LI>Minimise dependence on ANSI C runtime on platforms where it would have to be loaded separately (eg on Win32 prefer Win32 API functions such as GlobalAlloc() to ANSI C functions such as malloc().) <I>(Ross: this may be problematic, since some portable parts of the implementation may need to allocate memory -- perhaps we should define our own internal memory allocation functions.)</LI></UL>
</I><P>It has been suggested that we make an effort to minimise the use of global and static data in PortAudio implementations. Another related goal is to reduce name pollution in the global scope. Some possible guidelines in this regard are:</P>
<UL>
<LI>Implementations should avoid exporting any symbols except where absolutely necessary. Specifically, global data must be declared statically. We will need a naming convention for non-public global symbols, such as internal functions defined in one module and used in another. </LI>
<LI>Implementations should minimise their use of static data. </LI></UL>
<H4>Discussion</H4>
<P>There will always be time to improve these guidelines, however we are making a concerted effort to document some standards before the next round of changes are implemented.</P>
<H4>Impact Analysis</H4>
<P>This proposal will require all existing code to be reviewed and possibly revised. This is not expected to be a "big-bang" operation. Rather it is envisaged that this will be a long term, ongoing process aimed at improving the quality of the PortAudio codebase. </P>
<P>____________</P>
<H2><A NAME="AdditionalPa_TerminateBehaviour">Additional Pa_Terminate() Behaviour</A></H2>
<H4>Status</H4>
<P>This proposal is sufficiently well defined to be implemented. </P>
<H4>Background</H4>
<P>Some driver models (eg ASIO, MME and DirectSound under Windows NT) can require a reboot to free devices when they are not closed properly (due to a program not calling Pa_Close() either in error, or due to a crash.) As a quality of implementation issue PortAudio should seek to avoid such circumstances.</P>
<H4>Proposal</H4>
<P>The definition of Pa_Terminate() should be extended as follows:</P>
<PRE>/*
Pa_Terminate() is the library termination function - call this after
using the library. This function deallocates all resources allocated
by PortAudio since it was initializied using Pa_Initialize(). Any open
PortAudioStreams are closed.
Pa_Terminate() MUST be called before exiting a program which
uses PortAudio. Failure to do so may result in serious resource
leaks, such as audio devices not being available until the next reboot.
*/
PaError Pa_Terminate( void );</PRE>
<H4>Implementation Notes</H4>
<P>One possible implementation strategy would be to add a "next" member to the internal stream data structure thus making it a linked list node, which could be linked into a list of all open streams.</P>
<H4>Discussion</H4>
<P>Some concerns have been raised about the overhead involved in PortAudio having to keep track of which streams are currently open. </P>
<P>There has been some discussion about the behaviour of nesting multiple calls to Pa_Initialize() and Pa_Terminate() - there is no intention of changing the current behaviour, which is that PortAudio has two states: "Initialized" and "Uninitialized" - in the Initialized state, Pa_Initialize() does nothing and returns an error, in the Uninitialized state Pa_Terminate() does nothing and returns an error.</P>
<H4>Impact Analysis</H4>
<P>This proposal changes the termination behaviour of PortAudio to reduce the likelihood of resource leaks.</P>
<P>On Windows, the new Pa_Terminate() behaviour would allow users who want full protection against device leakage to install a global Win32 exception handler that calls Pa_Terminate() before exiting when a crash occurs. Similar techniques (using SIGNAL handlers perhaps?) may be possible on other platforms where necessary.</P>
<P>____________</P>
<H2><A NAME="ReviseInternalHostAPI">Revise Internal Host API</A></H2>
<H4>Status</H4>
<P>This proposal is under construction. Ideally, someone should go through all of the existing implementations and identify code that could be factored into a common library (parameter validation code for example.)</P>
<H4>Dependencies</H4>
<P>This proposal is dependent on the <A HREF="#MultipleDriverModels">Support for Multiple Driver Models in a Single PortAudio Build</A> proposal, and the <A HREF="#Interleaved">Non-Interleaved Buffers</A> proposal. The proposed conversion functions may be dependent on the MME multichannel via stereo pairs extension which is part of the <A HREF="#DriverModelSpecificPa_OpenStream">Driver Model Specific Pa_OpenStream() Parameters</A> proposal.</P>
<H4>Background</H4>
<P>PortAudio defines a set of helper functions that all implementations share. It is envisaged that these internal functions will need to be revised in response to the changes proposed in this document. It would also be beneficial to take this opportunity to refactor any other common code fragments that could be shared by multiple implementations.</P>
<P>A refactoring of the buffer data conversion functions was proposed here: <A HREF="http://techweb.rfa.org/pipermail/portaudio/2001-November/000244.html">http://techweb.rfa.org/pipermail/portaudio/2001-November/000244.html</A> However the proposal below is not quite the same. A significant benefit of formally specifying the interface to the buffer conversion functions is that it would facilitate the creation of optimised assembly language versions for different platforms.</P>
<H4>Proposal</H4>
<P>A common set of buffer conversion functions should be defined and shared by all implementations. The buffer conversion functions should handle all permutations of:</P>
<UL>
<LI>Sample format </LI>
<LI>Channels </LI>
<LI>Interleave / Non-interleave </LI>
<LI>Endianness </LI>
<LI>Channel compensation</LI></UL>
<P>"Channel-compensation" is necessary when certain devices require a higher number of channels than the user requests. With the Midiman Delta1010, for example, the device always needs to be fed 10 channels of output and you must read 12 channels of input (at least under ALSA without the "plug" interface).</P>
<P>The conversion functions could look something like:</P>
<PRE>void ConversionFunction_DestType_DestInterleave_SrcType_SrcInterleave_ ( void *dest, int destChannels, void *src, int srcChannels, int frames );</PRE>
<P>The dest and src parameters have the same format as those supplied to the PortAudio client callback.</P>
<P>Rather than have each implementation call these conversion functions directly, a 'factory function' could be implemented that returns a pointer to a conversion function based on parameters specifying the format of the source and destination buffers. This factory function could be called as needed when a stream is opened. The conversion functions could then be made static and hidden from the rest of PortAudio. The 'factory function' could have the following form:</P>
<PRE>enum PaEndiannes { paBigEndian, paSmallEndian, paHostEndian };
PaBufferConversionFunction* Pa_GetBufferConversionFunction(
PaSampleFormat destFormat, int destChannels, PaEndianness destEndianness,
PaSampleFormat srcFormat, int srcChannels, PaEndianness srcEndianness );</PRE>
<P>Note that the interleave/deinterleave status is encoded in the destFormat and srcFormat parameters. paHostEndian is used to represent the endianness of the current platform since some driver models (eg ASIO) allow the driver to use samples in a different endianness from the host endianness. Another alternative is to encode sample endianness in PaSampleFormat - this would allow clients to write sample data of either endianness to PortAudio (e.g. soundfile playback direct from file) and benefit from PortAudio's byte swapping code.</P>
<P>The redundant use of channel parameters in both the conversion functions and the factory function is intentional and would allow channel-optimised conversion functions to be supplied for common cases such as 16-bit stereo.</P>
<H4>Discussion</H4>
<P>This proposal currently only addresses buffer conversion functions, however it is important to identify other common code fragments that could be placed in the shared PortAudio library.</P>
<P>This proposal has not yet addressed the fact that the conversion functions also need to handle clipping and dithering.</P>
<P>It is not clear whether additional conversion functions will be needed to accommodate the MME interleaved stereo pairs for multichannel devices proposal.</P>
<P>It hasn't been established whether PortAudio will be extended to support all PaSampleFormats on all devices.</P>
<P>It isn't clear whether paCustomFormat is viable under this proposal, or how it would be accommodated.</P>
<P>When the client requested format and the host format are different a temporary buffer may be required to hold the converted data. However, in general PortAudio should aim to convert data in-place. Functions may be needed to establish when temporary buffers are needed, and to allocate them.</P>
<P>Due to a mismatch between the API buffer size and the PortAudio callback buffer size some driver models require PortAudio to shuffle data among multiple buffers in order to fulfil client requests - this has not yet been considered within the current proposal.</P>
<P>Memory allocation should probably be handled with platform specific functions such as Win32 GlobalAlloc() rather than using malloc()</P>
<H4>Impact Analysis</H4>
<P>This proposal only effects PortAudio implementors. Increasing the utility of shared code will improve the quality of all PortAudio implementations in terms of speed, size, and robustness. It should also reduce the effort involved in porting PortAudio to a new driver model.</P>
<P>____________</P></BODY>
</HTML>
Reference in a new issue View git blame Copy permalink