diff -r 578be2adaf3e -r 307f4279f433 Adaptation/GUID-B4C05C46-F2C9-57FA-AD85-EFE6479C2FF1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Adaptation/GUID-B4C05C46-F2C9-57FA-AD85-EFE6479C2FF1.dita Fri Oct 15 14:32:18 2010 +0100 @@ -0,0 +1,42 @@ + + + + + +DesignWhen 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:

+ +

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.

+
\ No newline at end of file