#169
- Created on2011-03-06 03:45
- Reported by
- StatusAccepted
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Portaudio should expose host API specific stream information
Today the PaStreamInfo struct contains no host API info of the stream. Portmixer relies on a patch that adds (unneccesarily) export symbols. PaStreamInfo should be extended to a) expose the host API type of the stream b) a void* ptr to a host API specific struct (which is defined in the host API headers) so that Portmixer can extract the information it needs.
We decided to add the hostApiType field a long time ago:
http://music.columbia.edu/pipermail/portaudio/2008-February/008314.html
We decided to add the hostApiType field a long time ago:
http://music.columbia.edu/pipermail/portaudio/2008-February/008314.html
Leave a comment
In case anyone queries whether we should be breaking binary compatibility by potting the host api id at the start of the struct. We already decided we're going to break things
http://music.columbia.edu/pipermail/portaudio/2008-February/008328.html
Richard Ash wrote:
> yes and yes from this end - break the compatibility, add the field
> where you think it fits in (at the start), increment the library version
> number, and whilst you are busy breaking binary compatibility, remove
> run-time struct versions as well. Some #defines would be a good idea,
> but I think API versions (on the same major / minor / point scheme as
> the library number) are the way to go.
http://music.columbia.edu/pipermail/portaudio/2008-February/008328.html
Richard Ash wrote:
> yes and yes from this end - break the compatibility, add the field
> where you think it fits in (at the start), increment the library version
> number, and whilst you are busy breaking binary compatibility, remove
> run-time struct versions as well. Some #defines would be a good idea,
> but I think API versions (on the same major / minor / point scheme as
> the library number) are the way to go.