| 29 | | 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 host APIs where format discovery is performed by polling the driver. 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 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. |
| 39 | | A number of options are being considered with regard to supplying clients with format information:</P> |
| | 40 | The PaDeviceInfo structure and Pa_GetDeviceInfo() function will be retained to provide simple |
| | 41 | attribute information about the device such as it's name, and for representing information |
| | 42 | that can be obtained without querying the host API multiple times, such as input and output channel counts: |
| | 43 | </P> |
| | 44 | |
| | 45 | <PRE> |
| | 46 | typedef struct PaDeviceInfo { |
| | 47 | int structVersion; |
| | 48 | const char *name; |
| | 49 | PaHostApiTypeCode hostApi; |
| | 50 | |
| | 51 | unsigned int maxInputChannels; |
| | 52 | unsigned int maxOutputChannels; |
| | 53 | } PaDeviceInfo; |
| | 54 | </PRE> |
| | 55 | |
| 43 | | <P>And/Or</P> |
| 44 | | <P>Add a Pa_IsFormatSupported() function:</P> |
| 45 | | <PRE>Pa_IsFormatSupported( PaDeviceIndex inputDevice, |
| | 61 | |
| | 62 | <P> |
| | 63 | A new Pa_IsFormatSupported() function will be added, which allows clients to query whether |
| | 64 | a particular combination of formats for input and output is valid. It returns 0 if the format |
| | 65 | is supported, and a PortAudio error code if the format is not supported. The special symbol |
| | 66 | paFormatIsSupported is provided to compare against the return value. |
| | 67 | </P> |
| | 68 | |
| | 69 | <PRE> |
| | 70 | #define paFormatIsSupported (0) |
| | 71 | |
| | 72 | PaError Pa_IsFormatSupported( PaDeviceIndex inputDevice, |
| 87 | | 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. |
| | 94 | Originally a goal existed to provide clients with information about which sample formats were |
| | 95 | natively supported and which were emulated by PortAudio. The idea was to allow clients to bypass |
| | 96 | PortAudio's conversion capabilities (and overhead) by using natively formatted buffers. This |
| | 97 | goal has been removed for three main reasons. A) Both buffer block adaption and unusual |
| | 98 | formats (such as varying endianness in ASIO, and multiple stereo interleaved with MME) |
| | 99 | make it difficult to provide |
| | 100 | a direct path between client and host api except in rare cases. B) PortAudio |
| | 101 | aims to use best-of-breed buffer conversion routines, thus making it undesirable for clients |
| | 102 | to implement their own conversion layer on top of PortAudio. C) It is difficult to imagine |
| | 103 | a Portable software design that would want to determine its output sample buffer format |
| | 104 | based on host api native format constraints; usually internal constraints such as use of a |
| | 105 | floating point signal path, or the format of a soundfile being played back would be more |
| | 106 | important. |
| | 107 | </P> |
| | 108 | |
| | 109 | |
| | 110 | <P> |
| | 111 | Although the retention of maxInputChannels and maxOutputChannels in the PaDeviceInfo |
| | 112 | structure is considered desirable by some clients, it has not yet been |
| | 113 | determined whether implementation of this feature is practical without polling |
| | 114 | some host APIs multiple times. |
| | 115 | </P> |
| | 116 | |
| | 117 | |
| | 118 | <P> |
| | 119 | It was suggested that we could do things the way MME does: if Pa_OpenStream() is called with a |
| | 120 | NULL stream parameter then the stream isn't opened, but it is checked to see if the device |
| | 121 | supports the specified format - if the format is supported then paNoError would be returned, |
| | 122 | otherwise an error code would be returned. However, this has been ruled to be unsatisfactory, |
| | 123 | since querying for supported formats is really a different function from opening a stream. |
