Request for method to determine which host-API specific extensions are installed (at compile time & runtime)
[Trac: Originally assigned to none]
see thread:
http://techweb.rfa.org/pipermail/portaudio/2007-July/007320.html
In summary:
1. People want a way to detect which host APIs are available when compiling PA
2. People want a way to detect which host APIs are compiled-in at runtime
3. People want a way to look up function-pointers for host-API extensions
These are in part separate issues.
Issue 1 is related to the configuration (how PA is built/configured). As noted below we would need to agree on some standard preprocessor symbols, and then they would need to be used on different platforms.
It has been noted that 2 can be addressed by changing the specification such that all compiled-in host APIs are always reported by PA, even those with no devices, or who returned an error during initialization.
Issue 3 can be handled in a number of different ways... possibly without the help of PortAudio if issues 1 and 2 are resolved.
Arve wrote:
Tim Blechmann made a valid point regarding the use of host-API specific
PortAudio extensions: These should be exposed to client code in some
standard manner. He maintains we should install these headers in a
"portaudio" directory, (e.g. include/portaudio), and then advertise which
are available through macros such as PA_HAVE_JACK (or PA_USE_JACK?) etc in
a generated header portaudio/config.h. He also suggested that these
headers be automatically included via portaudio.h when available, but I'm
unsure whether convention dictates to let the client include such headers
himself (depending on PA_HAVE_* macros).
see thread:
http://techweb.rfa.org/pipermail/portaudio/2007-July/007320.html
In summary:
1. People want a way to detect which host APIs are available when compiling PA
2. People want a way to detect which host APIs are compiled-in at runtime
3. People want a way to look up function-pointers for host-API extensions
These are in part separate issues.
Issue 1 is related to the configuration (how PA is built/configured). As noted below we would need to agree on some standard preprocessor symbols, and then they would need to be used on different platforms.
It has been noted that 2 can be addressed by changing the specification such that all compiled-in host APIs are always reported by PA, even those with no devices, or who returned an error during initialization.
Issue 3 can be handled in a number of different ways... possibly without the help of PortAudio if issues 1 and 2 are resolved.
Arve wrote:
Tim Blechmann made a valid point regarding the use of host-API specific
PortAudio extensions: These should be exposed to client code in some
standard manner. He maintains we should install these headers in a
"portaudio" directory, (e.g. include/portaudio), and then advertise which
are available through macros such as PA_HAVE_JACK (or PA_USE_JACK?) etc in
a generated header portaudio/config.h. He also suggested that these
headers be automatically included via portaudio.h when available, but I'm
unsure whether convention dictates to let the client include such headers
himself (depending on PA_HAVE_* macros).
Leave a comment