[SOC] ASIO

[Tom Spear (Dustin Booker, Dustin Navea)]

Paul Millar wrote:
> Hi Tom,
>
> On Tuesday 25 Apr 2006 19:05, Tom Spear wrote:
>   
>> On 4/25/06, Paul Millar <paul at 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.
>   
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