You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In dechamps/FlexASIO#236 I received a feature request for my app (FlexASIO, which really just uses PortAudio) to support native Linux/Mac audio APIs when running the Windows build of PortAudio on these OSes. Of course this necessarily implies the code is running under an emulation layer such as Wine.
This may seem like an odd thing to do, but it arguably could make sense in some contrived scenarios - the idea is a given application may only be available on Windows, but if it uses PortAudio (directly, or indirectly though something like FlexASIO), then it would still be possible to use native Linux/Mac native audio APIs within that application.
I'm honestly not sure how messy this would be to implement. I'm guessing it would somehow involve making it possible to link a Windows PortAudio build to Linux/Mac audio APIs, which may involve build system and ABI heroics. I'm not sure the extra maintenance burden in keeping this working would be justified for such a contrived use case.
Be that as it may, I'm opening this FR for discussion in case people have opinions on this.
The text was updated successfully, but these errors were encountered:
In dechamps/FlexASIO#236 I received a feature request for my app (FlexASIO, which really just uses PortAudio) to support native Linux/Mac audio APIs when running the Windows build of PortAudio on these OSes. Of course this necessarily implies the code is running under an emulation layer such as Wine.
This may seem like an odd thing to do, but it arguably could make sense in some contrived scenarios - the idea is a given application may only be available on Windows, but if it uses PortAudio (directly, or indirectly though something like FlexASIO), then it would still be possible to use native Linux/Mac native audio APIs within that application.
I'm honestly not sure how messy this would be to implement. I'm guessing it would somehow involve making it possible to link a Windows PortAudio build to Linux/Mac audio APIs, which may involve build system and ABI heroics. I'm not sure the extra maintenance burden in keeping this working would be justified for such a contrived use case.
Be that as it may, I'm opening this FR for discussion in case people have opinions on this.
The text was updated successfully, but these errors were encountered: