hpw
New Member
Posts: 14
|
Post by hpw on Mar 9, 2010 10:03:12 GMT
In my opinion the ASIO4ALL has a principal problem on ASIO reset. Usual ASIO HW implementations have a DLL (the ASIO driver) and an EXE (the driver GUI) to configure the driver settings. The GUI itself acts within it's own window process (PID) and isolates the GUI message queue to the ASIO driver. The problem rises (in the current implementation) as soon the users changes the channel & Sound card driver, and the ASIO4All sends a ASIO Reset to the user application. The user application (reading the ASIO spec's) has to reload the ASIO driver (here the ASIO4ALL) and this fails completely while the ASIO4ALL GUI (Driver & GUI) itself cannot be reloaded and it results in crashed ASIO4ALL GUI. In my opinion, it would be a very easy step to isolate the ASIO4ALL GUI and driver into real driver and standalone configure EXE. Just my 2 cents  Hp |
|
|
|
Post by Michael Tippach on Mar 9, 2010 13:28:45 GMT
The problem rises (in the current implementation) as soon the users changes the channel & Sound card driver, and the ASIO4All sends a ASIO Reset to the user application. The user application (reading the ASIO spec's) has to reload the ASIO driver (here the ASIO4ALL) and this fails completely while the ASIO4ALL GUI (Driver & GUI) itself cannot be reloaded and it results in crashed ASIO4ALL GUI What comes into mind is that: Normally, it doesn't (crash). As can be evidenced by any number of ASIO hosts out there that work just fine with ASIO4ALL the way it is now. From a more technical angle: you cannot completly unload the DLL for as long as the control panel is open, since DllCanUnloadNow() will always return S_FALSE in that case. |
|
hpw
New Member
Posts: 14
|
Post by hpw on Mar 10, 2010 7:05:39 GMT
Hi, >> As can be evidenced by any number of ASIO >> hosts out there that work just fine with ASIO4ALL >> the way it is now. The real question is who they deal with the ASIO reset command = NOP or  >> From a more technical angle: >> you cannot completly unload the DLL for as long >> as the control panel is open, since >> DllCanUnloadNow() will always return S_FALSE in that case. In other words: you do not like comply with the given ASIO specs!  Cheers Hp |
|
|
|
Post by Michael Tippach on Mar 10, 2010 12:29:51 GMT
The real question is who they deal with the ASIO reset command = NOP or They deal with it by... resetting the ASIO driver, as per the ASIO spec. There are exceptions that ignore the reset message, but most handle the reset just fine. In other words: you do not like comply with the given ASIO specs! How did you arrive at this conclusion? |
|
hpw
New Member
Posts: 14
|
Post by hpw on Mar 12, 2010 7:38:48 GMT
Hi,
>> There are exceptions that ignore the reset message
I am not able to read any "exceptions" in the given ASIO SDK manual... Please specify!
>> but most handle the reset just fine.
well, while they do not unload the driver. Keep in mind that it's a COM based INTERFACE, not simple a DLL ;D
>>>> you do not like comply with the given ASIO specs!
>>How did you arrive at this conclusion?
while with your current implemention the Driver & GUI is in your case one thing, that all run's within the application process.
Just simple isolate this...
Hp
|
|
|
|
Post by Michael Tippach on Mar 12, 2010 17:52:06 GMT
I am not able to read any "exceptions" in the given ASIO SDK manual... Please specify! With "exceptions" I'm referring to ASIO host applications that generally do not handle reset messages. From any ASIO driver. If you download the evaluation version of Reaper, you can observe reset message handling (or lack thereof) by turning it on and off in the Reaper audio config dialog. This would also give you the opportunity to verify that ASIO reset message processing works just fine, it does reset the driver - and it does not crash the GUI. - Or try Cubase
- Nuendo
- FL Studio
- Or even the Otachan Winamp ASIO output plugin (this one comes with source code, AFAIR, should you be in need a working reference in source code form)
well, while they do not unload the driver. Keep in mind that it's a COM based INTERFACE, not simple a DLL ;D Exactly. And I haven't managed to find the relevant bit in the ASIO spec that requires forced unloading of the DLL after Release() on the COM interface - which is what ASIOexit() does. Quite the contrary, COM specifically implies that it is up to the server to decide when to allow unloading of the DLL - and when not. >>>> you do not like comply with the given ASIO specs! >>How did you arrive at this conclusion? while with your current implemention the Driver & GUI is in your case one thing, that all run's within the application process. Where exactly in the spec does it say that this is something one must not do? Please be a little more specific! |
|
|
|
Post by Ian Green on Mar 13, 2010 10:29:11 GMT
For what it's worth, I have recently written a couple of programs with ASIO interfaces. When running active audio in and out of the sound card, changing the ASIO4ALL settings does (and should) result in reset messages. But restarting the driver works just fine. The only serious problems I have had (blue screens on Windows 7) were caused by a different ASIO driver, and not ASIO4ALL. You do have to close down the driver properly before restarting it . . .  |
|
hpw
New Member
Posts: 14
|
Post by hpw on Mar 14, 2010 16:52:30 GMT
Hi, >> Where exactly in the spec does it say that this is something one must not do? Please be a little more specific! Just read the ASIO SDK 7.Driver Notifications to the Host Application on page 8. Specially the Note section. Just a simple question: why do you like to keep the GUI within ther driver? All known ASIO HW have all GUi's as a sepearted process (EXE). Cheers HpW |
|
|
|
Post by Michael Tippach on Mar 15, 2010 0:37:06 GMT
Just read the ASIO SDK 7.Driver Notifications to the Host Application on page 8. Specially the Note section. It says: This totally unloads the problem onto the host. A PostMessage() is the canonical solution and pretty much the de-facto "industry standard" here. Specifically, it says nothing about the driver GUI being required to run in a separate process. May be your copy of the ASIO spec. is different from mine? Just a simple question: why do you like to keep the GUI within ther driver? All known ASIO HW have all GUi's as a sepearted process (EXE). The simple answer is that it is not required. An additional process implies additional resource use for no reason, background detection of ASIO hosts fails if the GUI Window does not belong to their process, ... there is no real upside! The way it is now works for everyone but your code, has not yet been demonstrated to be in violation of any spec. and further it is not true that all commercial ASIO drivers run the GUI in a separate process either. I suggest finding out why exactly your code does not work (while others works just fine) and if there should indeed be a problem within ASIO4ALL, I'm happy to fix it. |
|
hpw
New Member
Posts: 14
|
Post by hpw on Mar 17, 2010 7:43:18 GMT
Well, >> The way it is now works for everyone but your code, has not yet been demonstrated to be in violation of any spec. 1. I tested some public ASIO host examples an they really do not have this problem on ASIO reset 2. I do use a postmessage on RESET to a hidden window too! 3. what I do is on this event a complete reload of the available Input & Output channels to have the proper / valid channel items on a check-listbox. I have to investigate some more on this..... stay tuned BTW: Did you get any e-mail's from may side? Hp |
|
hpw
New Member
Posts: 14
|
Post by hpw on Mar 20, 2010 10:43:02 GMT
OK, after several tests I found the following issue (GPF=crash on ASIO4ALL thread) doing the following. 1) load my app 2) select asio4all 3) show all available in/out channels & description 4) open the asio4all control panel 5) select / unselect on given device channel where it fires a ASIOReset 6) just move the cursor left (horizonal away from the clicked channel) 7)now, just move the cursor back to the same button where the previous click was issued.... then I get repeatly a GPF (If I do not unload the driver the GPF to dot happen) If you are interested, I may send the eurekalog dump with the given test-app.... Cheers hpw |
|
