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

Last edited Jul 11, 2013 at 9:49 AM by TheGouldfish, version 9


No comments yet.