Microsoft DirectX 8.0 |
The process of tuning a digital receiver involves a different set of parameters depending on the network type. The purpose of the Tuning Model is to encapsulate these differences within a standard set of objects and procedures for manipulating those objects, and thereby free the application from having to manage low-level tuning details. Whether an application is tuning to a program coming from a DVB-S provider, or a local analog broadcaster, the basic procedure will be the same. This procedure is also independent of the underlying hardware. All the objects of the Tuning Model support the standard COM interface IPersistPropertyBag and so can be persisted to any sort of storage mechanism.
It is important to note that applications based on Microsoft® DirectX® 8.0 will not realize the full benefits of the Microsoft Tuning Model, because DirectX 8.0 does not provide a standardized Guide Store and Tuning Space-aware Guide Store Loader. Future releases of DirectX and of Microsoft® Windows® are expected to include these components. The Guide Store Loader monitors the Program Service Information (PSI) stream on the Transport Information Filter, and automatically creates Tune Requests for all the available channels or frequencies in a tuning space, and stores them in the Guide Store database. With these components, all the application has to do is create a User Interface showing the available channels, and submit the pre-prepared Tune Request to the Network Provider when the user makes a selection. For DirectX 8.0, however, the application must be involved in the creation of Tune Requests (which requires knowledge of their semantics). The other alternative is to write your own Guide Store Loader and Guide Store.
The two primary objects in the Tuning Model are the Tuning Space and the Tune Request. The Tuning Space describes the provider or transmission source, for example, a local cable service or a digital satellite network. Applications use the Tuning Space Container to enumerate the available Tuning Spaces on the local system, and then use the Tuning Space to create the Tune Request. The application submits Tune Requests to the Network Provider, which is the source filter in the graph. The Network Provider extracts the necessary information from the Tune Request and passes that information down to the kernel-mode driver. The following illustration shows the high-level relationship between an application, the tuning model objects, the BDA filter graph, and the kernel mode drivers.
A Tuning Space describes a specific network provider. Examples of tuning spaces include EchoStar®, DirecTV®, local analog broadcast via antenna, local analog cable, and local digital broadcast via antenna. The tuning space information includes information about the type of network, such as terrestrial analog broadcast television, ATSC, DVB-T, DVB-C, or DVB-S. A tuning space defines the context for a tune request; a Tune Request is meaningless apart from a particular Tuning Space. Therefore, a Tuning Space object has the job of creating its associated Tune Request objects. For example, an ATSC Tuning Space object creates ATSC Tune Requests, a DVB-S Tuning Space object makes DVB-S Tune Requests, and so on. Tuning Space objects and Tune Request objects are Automation® compliant and can be configured either through script, Microsoft® Visual Basic®, or C/C++.
Because different network types carry different types of data in different formats, each tuning space will require a particular Network Provider in the filter graph. For example, to create a tune request for a channel that is broadcast in ATSC digital format, an application would begin with an ATSC tuning space, which supports IATSCTuningSpace, and has a network type of ATSC and is associated with a default locator (discussed later in this section) that has been configured with the IATSCLocator interface. When the application calls ITuningSpace::CreateTuneRequest, it will receive back an ITuneRequest interface pointer. The application uses that interface to query for the IATSCTuneRequest interface, and then uses that interface to configure the tune request. When the tune request is submitted, it must be submitted to the Microsoft ATSC Network Provider (or to some other third-party BDA-compliant tuner filter that supports ITuner as well as an ATSC tuning space).
Note For this version of Microsoft® Broadcast Driver Architecture, two Network Provider filters are provided, one for ATSC networks and one for DVB-S networks. No default Tuning Spaces are provided for any DVB-S providers because of the specific information required to define them. Applications must use the SystemTuningSpaces object (using the ITuningSpaceContainer interface in C++) to create their own DVB-S Tuning Spaces based on basic information provided by the user about the service they are subscribed to.
The Microsoft Tuning Model includes other objects besides the ones mentioned earlier in this section. The following illustration shows the general relationship between all of the Tuning Model objects. In C++ terms, this diagram shows relations between base classes. In the actual process of creating and submitting a Tune Request, an application will always work with derived classes that are all specific to the same type of network.
The Tuning Space Container searches the Registry for tuning spaces available on the system, and instantiates Tuning Space objects.
A Tuning Space plays three primary roles. For a specific program source, it describes the type of network, contains parsing rules for the "TV:" moniker namespace, and is a factory for Tune Request Objects. "TV:" Uniform Resource Identifiers (URIs) can be embedded in HTML or XML, and must be parsed in order to bind to the correct object instance. Binding is the COM terminology for obtaining a COM object from a Moniker. In this case, the Tuning Space provides the network-specific parsing, so that binding to a "TV:" URI will result in a Tune Request object for that Tuning Space.
Locator objects are associated with a Tuning Space and provide further information that will be used ultimately by the device driver to tune to a specified channel or frequency within a Tuning Space.
A component refers to an elementary stream within the MPEG-2 program stream, for example video, audio 1, audio 2, audio 3, data, Program Service Information (PSI) and so on. These values are filled in by the Network Provider after it has tuned to the new frequency.
Each component is associated with a component type object that contains information about the component, such as which language is being spoken on an audio elementary stream. An application will maintain a list of preferred Component Types for each user. The current user's list should be submitted to the Network Provider via ITuner. If no such list is provided, then the Network Provider will use the Default Preferred ComponentTypes list in the Tuning Space. Third parties can define new preferred component types. By maintaining a list of preferred component types for each user, the app should never have to deal directly with Components, except in exceptional circumstances. Exceptional circumstances would include: the preferred language is English, but the viewer decides they want to hear the German audio instead; the preferred audio track is AC-3, but the viewer wants to switch to a mono track.When the Network Provider receives a Tune Request, and tunes to a particular channel or frequency, it fills in the Tune Request's Component list based on PSI information acquired by the Transport Information Filter. The Network Provider then compares that information to the preferred components types for the current user, and tunes to the appropriate elementary streams if any are available that match the user's preferences. After this initial Tune Request has been submitted, the application may obtain the current active Tune Request, and access the newly populated Components list. This Tune Request can be re-submitted with an updated Components list as user preferences dictate. An example of this would be changing the audio track to a different language than the default preference. The Preferred Components are only used if the Tune Request's Components list is empty or invalid. This is necessary because the Tune Request can be resubmitted multiple times with different Components activated or disabled.