Changeset 23
- Timestamp:
- 08/24/02 05:47:48 (6 years ago)
- Files:
-
- 1 modified
Legend:
- Unmodified
- Added
- Removed
-
pa_proposals/trunk/002-ImproveDeviceFormatsQueryInterface.html
r16 r23 18 18 <P><A href="index.html">Enhancement Proposals Index</A>, 19 19 <A href="http://www.portaudio.com/">PortAudio Home Page</A></P> 20 <P>Updated: August 1, 2002 </P>20 <P>Updated: August 24, 2002 </P> 21 21 22 22 <H4>Status</H4> 23 23 24 <P>This proposal is open for discussion.</P>24 <P>This proposal is sufficiently well defined to be implemented.</P> 25 25 26 26 <H4>Background</H4> 27 27 28 28 <P> 29 The current (V18) method of querying devices for supported sample formats, channels, and sample rates (Pa_GetDeviceInfo()) is weak. 30 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 host APIs where format discovery is performed by polling the driver, as filling the structure may involve many polling operations. Even if a sound card supports arbitrary sample rates, the host API may only allow a client to poll to see whether a rate is available rather than providing the available rate ranges. 29 The current (V18) method of querying devices for supported sample formats, channels, and sample rates (Pa_GetDeviceInfo()) is considered to be weak. It is incapable of representing formats where stream parameters are interdependent (for example where full duplex is only supported for certain sample rates.) We have found that representing device capabilities using a static structure is not a good match for many host APIs where format discovery is performed by polling the driver. This is because populating the structure may involve many polling operations. The current PortAudio API is able to provide details about hardware which supports a continuous range of sample rates, however many host APIs only allow sample rate information to be gathered by polling for specific rates. 31 30 </P> 32 31 33 32 <P> 34 It has been noted that most (platform specific) audio APIs have poor device capability querying mechanisms. 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.33 It has been noted that most host audio APIs have poor device capability querying mechanisms. Even the better APIs (ALSA is perhaps one) don't necessarily provide accurate information. Ideally 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. In reality, the available design options consist of providing an expressive interface that may provide inaccurate information on some platforms, or providing a less expressive interface which is more likely to provide accurate information, but may limit the amount and detail of information compared to that supplied by the underlying host API. The latter design option has been chosen for this proposal. 35 34 </P> 36 35 … … 55 54 56 55 <P> 57 The notion of "native sample formats" - those that are directly supported by the underlying 56 The following fields have been removed from the above structure, relative to V18: 57 numSampleRates, sampleRates, nativeSampleFormats. Sample rate information will only 58 be available by polling PortAudio using the Pa_IsFormatSupported() function defined below. 59 The concept of "native sample formats" - those that are directly supported by the underlying 58 60 host API - will be removed from the PortAudio specification as PortAudio's conversion 59 61 capabilities allow support for all PortAudio sample formats. … … 81 83 </PRE> 82 84 85 <P> 86 The <A href="016-UseStructsForOpenStreamParameters.html">Use Structs for Pa_OpenStream() Parameters</A> proposal defines 87 the PaStreamParameters structure which will replace the individual parameters in the Pa_IsFormatSupported() definition above, 88 resulting in the following prototype: 89 </P> 90 91 <PRE> 92 PaError Pa_IsFormatSupported( 93 PaStreamParameters *inputParameters, 94 PaStreamParameters *outputParameters, 95 double sampleRate ); 96 </PRE> 97 83 98 84 99 … … 87 102 <P> This proposal provides a mechanism for querying PortAudio for supported 88 103 formats without requiring implementations to construct device information structures 89 by polling the host api multiple times. 104 by polling the host api multiple times. The down side to this design is that 105 some information that host APIs may make available without polling is hidden 106 from PortAudio clients. Most significantly, if a PortAudio client wishes to display 107 a list of supported sample rates, it's only option is to poll PortAudio. This was 108 deemed to be satisfactory because in many cases PortAudio is unable to establish 109 the available sample rates without polling itself. The alternative of providing 110 sample rate information only when it is available was considered, but discarded 111 as being confusing and error prone. 90 112 </P> 91 113 … … 102 124 to implement their own conversion layer on top of PortAudio. C) It is difficult to imagine 103 125 a Portable software design that would want to determine its output sample buffer format 104 based on host apinative format constraints; usually internal constraints such as use of a126 based on host API native format constraints; usually internal constraints such as use of a 105 127 floating point signal path, or the format of a soundfile being played back would be more 106 128 important.
