[quote=“Kevin Granade, post:150, topic:3053”]*kevingranade pokes at the SDL_mixer API with a stick.
Huh, that’s not as bad as I thought…[/quote]
Actually about the post you made about SDL API only, but yet…
Regarding this, I did some research on my own behalf. If there’s no doubt to what port, interrupt and handler for memory access are, the nature of the Windows XP (ver 5+) is to parse everything to the Primary Device Driver. The utility port therefore is the driver, mostly WHQ certified, which is in most cases the only one. However, XP can have multiple drivers installed and running for the same piece of (physical) hardware, but not for the exact device they represent. This way some aux input could be digitally outputted in a stand-alone manner, whilst your analog output is using the exact hardware the driver’s aimed for. Altough it’s only a mapper of a sort, it still prevents from mishaps if there’s, say, an application that utilizes the installed hardware to the full extent, such as a studio port of a recording utility, and a simple audio player and exporter with software mixing; your common audio player software. Now for the “research” part:
Example_1: An application with suitable background music and sound effects running over Media Player. This is when the native mixer pokes the sound card for resources and capabilities, and mixes them to the same output if available (that’s 99.9% of the time). Works as long as the OS can assign port maps without coliding with reserved resources - so it’s full-proof most of the time, as far as the driver’s concerned.
Example_2: A piece of software that’s written so to use another, inbound API. This works through more than one IRQ (interrupt request) address and handles virtual devices on both levels - frontend and process. The “depth” of the code should render the sound card driver usable or unusable to other apps; a standard, enterprise suite such as Cubase should leave the default mapping to the system so you can exercise some basic forms of sound rendering, no matter what the main utility (here Cubase) figures are at the moment. A “savage” sound processing app may reserve all the resources from the driver but not the driver itself (a pro really) so no rendering happens or there’s a warning message at most.
Example_3 XP has certain extensions to the Windows core, such as CMD for some basic DOS support. On the DOS end, sound needs to be initialized regardless of the mapping in the AUTOEXEC or CONFIG native scripts. For more than a few games this is a issue resolved in a suitable way that represents a stand-alone mixer utility that attempts to reserve resources based on the chosen driver, and parse everything to the main app in the way its code requires. Since DOS and Windows cores are very different on this issue, the main OS asks for the primary driver on those specific ports - if there’s no 100% DOS EMU driver installed (it’s not there in most WHQ cases, DOS is considered obsolete). The main problem here lies with reserving those resources, because they aren’t discarded with Windows XP and are captured as long as the DOS app runs in the background. The consequences could be dire even with the different addresses usage for both Core and the Extension, and the loop for sound rendering may “lock” the sound card, or the most of its part. However, this is only the worst scenario - in majority of the cases only the sound init does the mentioned lock, so if you initialize the sound card with some software that points to the “Media Player” mixer (e.g. Winamp) and run the DOS app at pretty much the same time, you get a result based on priorities; preset or the default setting having the upper hand, so Winamp with its internal error handling resolves the issue - and the background CMD line app is freezed by the Windows core. My impression with the main Mixer app is that of a system driver that doesn’t have a way of handling exceptions, but the Primary Driver has some discretion over this.
You get the picture with the above mentioned examples - in most cases there is no alternate choice for the Primary Driver. It defines the versatility of the hardware and based on that sends information to the sound mixer system driver. If you engage in forcing a third-party driver whereas the Primary one stands it is possible that the mixer won’t accept input, altough a mixer with the app itself can stand in between your code and the actions that the Primary Driver parses to the system mixer.
