A believe a critical point in regards to my article is the proper, fresh reinstallation of Windows [XP Pro] along with previously noted Soundblaster installation steps.

The article, admidittedly challenging and involved, was written in repsonse to information and insight from this thread while initially searching for assistance to the problems described in this and other threads.

I felt a sense of obligation to take the time to follow up and post my findings and experiences to give back and more importantly, document my loosely organized self.

Somber Ghost,

You posted the devldr32 phenomenon has returned to your system as a result of migrating PCI cards between slots.

Perhaps due to removing and reinstalling your PCI card(s), specifically the Soundblaster *, I believe Windows was prompted to reinstall native drivers hence leaving you with the dreaded phenomenon as previously described.

By the way, I only install the Soundblaster drivers from the Soundblaster driver package. No applications [bloat]. But remember I do not use my Soundblaster for anything other than playing music (audio) and Windows sounds.

From the solution you descirbe in your post you have more or less discovered the same solution, give and take [this long post/threads] details.

You are probably one of the individuals responsible for the initial informatoin which led me to probe further into understanding this annoying phenomenon in the first place. Thanks!

Update:

My system is running extrememly well without devldr32. I can't directly, factually relate the next statement to devldr32 but I believe they are related.

Since solving the issue my system is performing input/output (audio/video) tasks and anything PCI-intensive such as transfers over the PCI bus with positive, appropriate performance.

(Note from my original [long] article I took additional steps which could be and probably are as important to performance improvements. e.g. Promise Fasttrack 100 controller removal.)

As I work with professional audio the most important difference I immediately noticed by resolving the devldr32 issue was the ability to push the PCI bus I/O much harder and get expected results.

In this case I am speaking specifically about latency. e.g. the time it takes for sound to enter the computer and come back out again to my ears. Of course added processing or effects lengthens that time and is reliant upon processor speed and RAM but basic latency always exists.

With devldr32 and prior to creating the process I documented audio I/O and latency were problematic and frankly impossible to work with.

I employ a high end, professional audio card capable of latencies down to 1.5ms [multiplied times 2 as latency is measured one direction (typical marketing propeganda)] for a total of 3ms roundtrip. That's 3 milliseconds!

Example of why anyone would care about that:
An artist plays a midi keyboard which triggers a very large and expensive grand piano sample in real time on the computer which is also doing the recording to disk during an expensive and important session when the artist is in the groove and in the zone.

Somber Ghost,

Lastly, if your assumption about sharing IRQ and the presence of devldr32 are related you may wish to do some sanity checks to understand if that is possible.

For example:

Check with Device Manager and view resources by connetion so you can view IRQ assignments.

If PCI devices are sharing IRQ, that information may be applied to the article and your information from your post and findings.

In summary,

I am not sharing IRQ for any device within my system.

I have rid my system of the devldr32 phenomenon by following my [long] documented process and have found success with it.

I had to give things up to get what I wanted: performance and stability.

I had to spend time tearing down, documenting, rebuilding, testing and finalizing the system to enjoy the success.

empathy