What is ASIO?
ASIO is a driver interface for pro-audio apps developed by Steinberg. It's somewhat similar to our beloved Jack sound server, but not as advanced.
I thought about implementing ASIO for wine so we are one step neaer to a running Cubase. I have also some advanced audio hardware - hercules 16/12 fw (need to check if there are some dirvers).
At the moment I am a student of Computer Sciences in the 4 term and have done programming with c, c++ and java.
Bugs, which get fixed: http://bugs.winehq.com/show_bug.cgi?id=2161
What do you think about this idea?
Thanks, Christian
Am Dienstag, 18. April 2006 11:56 schrieb Christian Gmeiner:
What is ASIO?
ASIO is a driver interface for pro-audio apps developed by Steinberg. It's somewhat similar to our beloved Jack sound server, but not as advanced.
I thought about implementing ASIO for wine so we are one step neaer to a running Cubase. I have also some advanced audio hardware - hercules 16/12 fw (need to check if there are some dirvers).
At the moment I am a student of Computer Sciences in the 4 term and have done programming with c, c++ and java.
Bugs, which get fixed: http://bugs.winehq.com/show_bug.cgi?id=2161
What do you think about this idea?
Thanks, Christian
I like the idea - obviously, I reported the bug... ;-)
Some more infos about ASIO: ASIO is a low-latency audio protocol. ASIO is not part of Windows, and was not developed by Microsoft, but by Steinberg Media Technologies. It comes with most soundcard drivers, though, and is a de-facto standard for pro-audio applications. Most (all?) pro-audio applications at least support ASIO, and many applications _only_ support ASIO these days (no DSound/ MME/ whatever at all). Those applications won't ever work on Wine without ASIO.
There are some problems, though. The ASIO SDK license is quite free, you can basically do what you want with it AFAIU, but you may not redistribute parts of the SDK. Steinberg intended to BSD-license all their SDKs a while ago, but that idea was canned after Yamaha bought Steinberg. Everyone may download it from the Steinberg website, though, and the binaries may be redistributed. So prebuilt Wine packages may come with ASIO support enabled. If anyone wants to build Wine from source and needs ASIO support, they need to get the SDK from Steinberg.
ASIO EULA and SDK: http://www.steinberg.de/329+M54a708de802.html
ASIO description on Wikipedia: http://en.wikipedia.org/wiki/Audio_stream_input_output
Willie Sippel wrote:
Am Dienstag, 18. April 2006 11:56 schrieb Christian Gmeiner:
What is ASIO?
ASIO is a driver interface for pro-audio apps developed by Steinberg. It's somewhat similar to our beloved Jack sound server, but not as advanced.
I thought about implementing ASIO for wine so we are one step neaer to a running Cubase. I have also some advanced audio hardware - hercules 16/12 fw (need to check if there are some dirvers).
At the moment I am a student of Computer Sciences in the 4 term and have done programming with c, c++ and java.
Bugs, which get fixed: http://bugs.winehq.com/show_bug.cgi?id=2161
What do you think about this idea?
Thanks, Christian
I like the idea - obviously, I reported the bug... ;-)
Some more infos about ASIO: ASIO is a low-latency audio protocol. ASIO is not part of Windows, and was not developed by Microsoft, but by Steinberg Media Technologies. It comes with most soundcard drivers, though, and is a de-facto standard for pro-audio applications. Most (all?) pro-audio applications at least support ASIO, and many applications _only_ support ASIO these days (no DSound/ MME/ whatever at all). Those applications won't ever work on Wine without ASIO.
There are some problems, though. The ASIO SDK license is quite free, you can basically do what you want with it AFAIU, but you may not redistribute parts of the SDK. Steinberg intended to BSD-license all their SDKs a while ago, but that idea was canned after Yamaha bought Steinberg. Everyone may download it from the Steinberg website, though, and the binaries may be redistributed. So prebuilt Wine packages may come with ASIO support enabled. If anyone wants to build Wine from source and needs ASIO support, they need to get the SDK from Steinberg.
ASIO EULA and SDK: http://www.steinberg.de/329+M54a708de802.html
ASIO description on Wikipedia: http://en.wikipedia.org/wiki/Audio_stream_input_output
While I like the idea, I don't necessarily agree with adding yet another dependency (even optional), as that would require another doc mod and of course support for anyone wanting to use a pro-audio app. It would be nice if we could convince Yamaha to let us use the code from Steinberg, but that is doubtful.. Our best bet is to figure out some way to do what ASIO does without actually looking at the SDK or sources.... Anyone else have an opinion?
Tom
Hi Tom,
Yes, this looks to be amenable to a clean-room implementation.
This could involve two students: one activity would be to write a document describing the API and write a suite of functional tests that "define" correct behaviour of the API; the other activity would be to use the document and functional test-suite to implement a version of the asio dll for wine.
Would this be an appropriate SoC project? I speak as someone who's got a mate who (independently) came up with much the same idea and this might allow both to contribute.
Cheers,
Paul.
On Tuesday 18 Apr 2006 17:27, Tom Spear (Dustin Booker, Dustin Navea) wrote:
Our best bet is to figure out some way to do what ASIO does without actually looking at the SDK or sources.... Anyone else have an opinion?
On 4/25/06, Paul Millar paul@astro.gla.ac.uk wrote:
Hi Tom,
Yes, this looks to be amenable to a clean-room implementation.
This could involve two students: one activity would be to write a document describing the API and write a suite of functional tests that "define" correct behaviour of the API; the other activity would be to use the document and functional test-suite to implement a version of the asio dll for wine.
Would this be an appropriate SoC project? I speak as someone who's got a mate who (independently) came up with much the same idea and this might allow both to contribute.
Cheers,
Paul.
I don't see any reason why that couldn't work. We could combine that test suite with users that use various pro-audio apps tests of said apps. For example, some users prefer fruity loops over soundforge or acid, but we can test all 3 against the implementation, modify (or initially write) the tests to do the same things as these apps, and then build the implementation based on the tests..
Not to go off topic, but that might be a good method (now that I think about it) to find out what various other apps do.. Sure it is the same as making a testcase, but in this case, we are working backwards, which might speed up patch production in some cases
If I am reading what you said above, you basically want to for example, take fruity loops, figure out what it does when you do various things (by tracing that app's execution), then using that trace, write our own code to produce an _identical_ trace, and then use that code to make patches to other areas of wine..
Am I off the mark here? If not that really could help out our release cycle, and increase the number of bugs fixed per release.....
On 4/25/06, Tom Spear speeddymon@gmail.com wrote:
If I am reading what you said above, you basically want to for example, take fruity loops, figure out what it does when you do various things (by tracing that app's execution), then using that trace, write our own code to produce an _identical_ trace, and then use that code to make patches to other areas of wine..
While reading through traces can give you some idea of what a particular app or native dll is doing, trying to match traces identically is a bad way to go about achieving interoperability. For one, traces just output one particular code path, and leaves you with no idea about what else there is to implement. A better method is to use the traces as one tool in a larger toolkit to understand what is going on behind the scenes then implement your own version of the code that has the same outcome (usually not the same trace.)
-- James Hawkins
Hi Tom,
On Tuesday 25 Apr 2006 19:05, Tom Spear wrote:
On 4/25/06, Paul Millar paul@astro.gla.ac.uk wrote:
Yes, this looks to be amenable to a clean-room implementation. [...]
I don't see any reason why that couldn't work. We could combine that test suite with users that use various pro-audio apps tests of said apps. For example, some users prefer fruity loops over soundforge or acid, but we can test all 3 against the implementation, modify (or initially write) the tests to do the same things as these apps, and then build the implementation based on the tests..
Yes, one option is to use applications to do the testing. Another is to write discrete functional tests against each part of the API (c.f. the wine test framework). Both approaches have pros and cons.
I was thinking more the wine test framework in mind. Assuming we use wine test, part of the "contaminated" student's job would be to write a set of tests (presumably with loads of todo_wine ok()s to begin with :). These tests would hopefully "cover" all the documented expected behaviour.
As a bonus, writing the tests through wine test means it could be fairly easily tested what we (and presumably the SDK) thinks is correct behaviour against the various (close-source) implementations.
The "clean" student would implement code and remove the "todo_wine" bit as she proceeds.
Not to go off topic, but that might be a good method (now that I think about it) to find out what various other apps do.. Sure it is the same as making a testcase, but in this case, we are working backwards, which might speed up patch production in some cases
If I am reading what you said above, you basically want to for example, take fruity loops, figure out what it does when you do various things (by tracing that app's execution), then using that trace, write our own code to produce an _identical_ trace, and then use that code to make patches to other areas of wine..
At the risk of pointing out what may be obvious, what you describe here is (one element of) reverse engineering rather than a clean-room method.
Yeah, you can do reverse engineering to figure out the *actual* behaviour, but: 1. its (probably) slower that doing a proper clean-room implementation, 2. you'd inherit any "bugs" from your applications, 3. you (probably) won't cover all the functionality. Some new app. might come along that wine won't support,
On the plus side you see how applications are *actually* using the API (hence can support broken or illdefined behaviour, if the app needs it).
Am I off the mark here? If not that really could help out our release cycle, and increase the number of bugs fixed per release.....
Its horses for courses. Some of wine comes from applications not working, which is subsequently traced back to some undocumented behaviour in Windows.
But, given the information available in the SDK, it would be a shame not to use it if we can.
Cheers,
Paul.
Paul Millar wrote:
Hi Tom,
On Tuesday 25 Apr 2006 19:05, Tom Spear wrote:
On 4/25/06, Paul Millar paul@astro.gla.ac.uk wrote:
Yes, this looks to be amenable to a clean-room implementation. [...]
I don't see any reason why that couldn't work. We could combine that test suite with users that use various pro-audio apps tests of said apps. For example, some users prefer fruity loops over soundforge or acid, but we can test all 3 against the implementation, modify (or initially write) the tests to do the same things as these apps, and then build the implementation based on the tests..
Yes, one option is to use applications to do the testing. Another is to write discrete functional tests against each part of the API (c.f. the wine test framework). Both approaches have pros and cons.
I was thinking more the wine test framework in mind. Assuming we use wine test, part of the "contaminated" student's job would be to write a set of tests (presumably with loads of todo_wine ok()s to begin with :). These tests would hopefully "cover" all the documented expected behaviour.
As a bonus, writing the tests through wine test means it could be fairly easily tested what we (and presumably the SDK) thinks is correct behaviour against the various (close-source) implementations.
The "clean" student would implement code and remove the "todo_wine" bit as she proceeds.
Not to go off topic, but that might be a good method (now that I think about it) to find out what various other apps do.. Sure it is the same as making a testcase, but in this case, we are working backwards, which might speed up patch production in some cases
If I am reading what you said above, you basically want to for example, take fruity loops, figure out what it does when you do various things (by tracing that app's execution), then using that trace, write our own code to produce an _identical_ trace, and then use that code to make patches to other areas of wine..
At the risk of pointing out what may be obvious, what you describe here is (one element of) reverse engineering rather than a clean-room method.
Yeah, you can do reverse engineering to figure out the *actual* behaviour, but:
- its (probably) slower that doing a proper clean-room implementation,
- you'd inherit any "bugs" from your applications,
- you (probably) won't cover all the functionality. Some new app. might
come along that wine won't support,
On the plus side you see how applications are *actually* using the API (hence can support broken or illdefined behaviour, if the app needs it).
Am I off the mark here? If not that really could help out our release cycle, and increase the number of bugs fixed per release.....
Its horses for courses. Some of wine comes from applications not working, which is subsequently traced back to some undocumented behaviour in Windows.
But, given the information available in the SDK, it would be a shame not to use it if we can.
Cheers,
Paul.
Doing a trace as far as I understood it isn't really reverse engineering, because you dont see the actual low-level or high level code, you just see the result of what the code did.. Now if I am wrong, then ya we definitely don't want to do that in our clean room implementation, but it might be useful for the "contaminsted" student that was mentioned in a previous email..
Tom
Hi all.
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.
OF: An other question: How will the projects gets assigned to a student?
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
On 4/25/06, Paul Millar paul@astro.gla.ac.uk wrote:
Hi Tom,
Yes, this looks to be amenable to a clean-room implementation.
This could involve two students: one activity would be to write a document describing the API and write a suite of functional tests that "define" correct behaviour of the API; the other activity would be to use the document and functional test-suite to implement a version of the asio dll for wine.
Would this be an appropriate SoC project? I speak as someone who's got a mate who (independently) came up with much the same idea and this might allow both to contribute.
Cheers,
Paul.
Would it be a good idea to code the DirectPlay provider the same way using the two person approach?
Jesse
-
Christian Gmeiner -
Christian Gmeiner -
James Hawkins -
Jesse Allen -
Paul Millar -
Rolf Kalbermatter -
Tom Spear -
Tom Spear (Dustin Booker, Dustin Navea)
-
Willie Sippel