How about this?
regards, Jakob
How about starting a blacklist framework. You could have a table with the function that fails and some caps info that identifies the driver. I would suspect that there is more than one buggy driver out there. You could then just add it's info to the table when it is found.
You could then do:
if (!inBlacklist(WAVE_IN_OPEN, &capsA)) { // do the test ... } else trace("blacklisted ..... \n");
There are modems that do strange things and the Remote Desktop Protocol driver and other third party sound rerouting pseudo drivers also do strange things. These will need to be added someday also.
This could become a real maintenance nightmare if not done properly from the start.
Robert Reif wrote:
How about starting a blacklist framework. You could have a table with the function that fails and some caps info that identifies the driver. I would suspect that there is more than one buggy driver out there. You could then just add it's info to the table when it is found.
You could then do:
if (!inBlacklist(WAVE_IN_OPEN, &capsA)) { // do the test ... } else trace("blacklisted ..... \n");
There are modems that do strange things and the Remote Desktop Protocol driver and other third party sound rerouting pseudo drivers also do strange things. These will need to be added someday also.
This could become a real maintenance nightmare if not done properly from the start.
Yes, I too thought about creating a blacklist framework. But I want to wait a bit before starting on it, until I see:
a) how common buggy drivers are - the framework must not be heavier than the issues it solves.
b) with some more issues at hand, it's easier to see the patterns and what a blacklist framework should look like. I don't like coding without a clear vision of what I want.
regards, Jakob
-
Jakob Eriksson -
Robert Reif