Writing a driver

Writing a driver

Drivers are SharpMik's way of passing out processed audio data. The driver doesn't have to send data to an audio system, they can be used to save to files.

SharpMik supports software and hardware mixing, but seeing very few soundcards support hardware mod mixing the software mixer is normally used. A LQ and HQ software mixer have been provided and will be correctly selected by the VirtualSoftwareDriver base class. The Hardware mixing has not been tested due to lack of hardware so its support is unkown.

Drivers work in one of two ways; either it pushes the data out to the audio system, or it can have the audio system request the data. There is a flag that should be set when creating the driver so the update function knows if it should push the data or not. Most drivers that are playing audio to an audio device will want to pull the data when the device requests it, where file writing drivers will get the data pushed to them from the update.

As it stands at the moment the drivers also handle the sample loading and storing, this is one area that would be nice to change.

Software Interface

As mentioned there are 2 ways to process a mod, in hardware and in software, most modern sound devices don't have hardware support for mods so the software processing is the most used.

Its possible to handle the whole processing and mixing your self in a driver, but for the most part it will be much easier to use the supplied software driver.

Base IModDriver interface This is the base class that all drivers will implement , this includes no direct support for module processing or sample loading and handling.

VirtualDriver1 Interface This base class supports software processing and full sample loading and handing. This is the old LQ software mixer and only supports LQ mixing, and will be removed at some point.

VirtualSoftwareDriver Interface This is the new software mixer class that supports both the LQ mixer and the HQ mixer. Due to the need to allocate memory the choice of which mixer should be made before init'ing the driver.

Creating a new software driver using VirtualSoftwareDriver This will implement all the functions needed to create a signed byte array of audio data, the following functions should be implemented in your driver:

CommandLine (String) used to pass data to the driver
IsPresent() tells the mod player the driver can be used, mostly redundant
Init() used to set the driver up
PlayStart() tells the driver that it should start playing
PlayStop() tells the driver that it should stop playing
Pause() tells the driver that the audio should be paused
Resume() tells the driver that the audio should be resumed

Getting the data from the software mixer is as simple as calling WriteBytes(sybte[], int). This will fill the signed byte buffer with audio data upto the requested amount (if possible), with the amount it actually got being returned.

Calling this function will also increment the time of the mod.

As audio can either be pushed or requested the driver should set if its auto updating. This will tell the mod engine to not update its self but wait for an audio pull request. This should be done while setting up the other variables in the constructor of the driver:

m_Name name of the driver
m_Version Version of the driver
m_HardVoiceLimit number of hardware voices the driver supports, typically 0
m_SoftwareVoiceLimit number of software voices the driver supports, typicall 255
m_AutoUpdating true if the driver works by request, false if the data should be pushed to the audio device