Christian Gmeiner [mailto:christian.gmeiner@students.fhv.at] wrote:
Okay i think this project can be done by one student, because we can use the SDK for our work. We can take all API prototypes and build our own SDK based on the original SDK. We are only not allowed to share the original source files, but we are allowed to make them by our own by looking at orginal SDK. So if we dont do copy&paste, all should be okay.
I'm not exactly sure what the problem with ASIO is here. I have looked at it quite some time ago (not in relation to Wine actually but about providing an ASIO interface to the software environment we usually use) and it may have been updated/improved since but it seemed basically to consist of two things:
1) An example for an ASIO driver API that a hardware or other data source/sink provider needs to implement. 2) A simple and rather thin manager layer to load and access those drivers and as far as I could see are applications supposed to link that layer directly into their code.
As such both code parts are really examples of what API either an ASIO data source/sink would need to provide and what an ASIO application would need to use. Personally I think the example code for the driver manager layer to be sort of crude and minimalistic as it does not allow to open two or more interfaces at the same time, since it stores the driver DLL handle in an internal global variable.
As to support for ASIO enabled applications in Wine I think it would boil down to write an ASIO driver that provides the entire ASIO API to applications and gets properly registered on one side and accesses whatever (professional) audio hardware is accessible through whatever native Linux API. Trying to get Windows ASIO drivers to load and work under Wine would not only require Windows kernel driver support in Wine but also transparent hardware access for those drivers through some mechanisme since the actual hardware driver needs that and that is one path Wine is not gonna head anytime soon.
Rolf Kalbermatter