kluyg
New Member
Posts: 2
|
Post by kluyg on Jul 10, 2012 14:23:25 GMT
Steps to reproduce: 1) Create ASIO4ALL COM object (object1) 2) call Init 3) call CreateBuffers passing new ASIOCallbacks struct address with pointers to bufferSwitch, asioMessage and other functions 4) call DisposeBuffers (this should clear callbacks pointers inside ASIO4ALL)
5) Release COM object (object1) 6) Create ASIO4ALL COM object (object2) 7) call Init 8) open ASIO4ALL panel (call controlPanel) 9) close ASIO4ALL panel - asioMessage callback registered with old object1 is called - this is bug
I'm using Windows 7 x64, but the app and driver is created in 32 bit mode.
|
|
|
Post by Michael Tippach on Jul 13, 2012 18:12:14 GMT
Steps to reproduce: 1) Create ASIO4ALL COM object (object1) 2) call Init 3) call CreateBuffers passing new ASIOCallbacks struct address with pointers to bufferSwitch, asioMessage and other functions 4) call DisposeBuffers (this should clear callbacks pointers inside ASIO4ALL) 5) Release COM object (object1) 6) Create ASIO4ALL COM object (object2) 7) call Init 8) open ASIO4ALL panel (call controlPanel) 9) close ASIO4ALL panel - asioMessage callback registered with old object1 is called - this is bug I'm using Windows 7 x64, but the app and driver is created in 32 bit mode. Technically, you are correct, and there is a reason for that behavior: A "kAsioResetRequest" message requires the host to do perform a complete Unload-Reload cycle on the driver object. Which is a bit problematic when the control panel is still open (and most likely has been the source of the message, to begin with) I will see if I can find a more elegant solution for this (maybe by "cacheing" the ResetRequest and re-issueing whenever AsioCreateBuffers is called again...) I'll see what I can do!
|
|
kluyg
New Member
Posts: 2
|
Post by kluyg on Jul 19, 2012 7:09:05 GMT
Thank you for the response! The "cacheing" solution is a great idea. But as a quick fix (and the way Steinberg do this in their example driver implementation) I suggest just setting callbacks to null on DisposeBuffers call. This way the host will miss all the "kAsioResetRequest" messages, which will came before calling CreateBuffers. But I think it is OK since there is no way (without "cacheing") to get "kAsioResetRequest" message, if the driver is started at the first time and CreateBuffers was not called yet.
|
|
|
Post by hakemhakemy on Jul 19, 2012 16:05:59 GMT
[glow=red,2,300][/glow] Steps to reproduce: 1) Create ASIO4ALL COM object (object1) 2) call Init 3) call CreateBuffers passing new ASIOCallbacks struct address with pointers to bufferSwitch, asioMessage and other functions 4) call DisposeBuffers (this should clear callbacks pointers inside ASIO4ALL) 5) Release COM object (object1) 6) Create ASIO4ALL COM object (object2) 7) call Init 8) open ASIO4ALL panel (call controlPanel) 9) close ASIO4ALL panel - asioMessage callback registered with old object1 is called - this is bug I'm using Windows 7 x64, but the app and driver is created in 32 bit mode.
|
|