Design

When you start a port, you must make a decision if the driver must provide record, playback, or both playback and record.

If the PDD is to support audio transfer in a single direction, either record or playback, then a conventional PDD implementation is required. The PDD opens only a single driver channel and the PDD factory creates either a record or playback PDD object.

If the PDD is to support audio transfer in both directions then it must be implemented to open two units, one playback unit and one record unit. For each unit the PDD factory must create the appropriate PDD object.

One complication in this configuration is the need to co-ordinate access to the single audio hardware device from the two separate PDD objects. This configuration needs coordination when accessing the hardware device from two separate PDD objects, detecting and preventing situations where the handling of a PDD function for the channel in one direction conflicts with the channel setup in the other direction, specifically:

• preventing the setup of conflicting audio configurations between the record and playback channels.

• preventing the channel in one direction from powering down the audio hardware device while it is being used for data transfer by the other channel.

The solution is to move the code that controls those aspects of audio hardware setup which are shared between the two driver channels into the PDD factory object, as this object is shared.

The porting process focuses on implementing a PDD that supports both record and playback as this is the most common situation. The template port Sound Driver is setup for this configuration. A PDD that supports audio transfer in a single direction only omits the implementation for the direction not supported.