Windows Embedded Automotive 7 Deep Dive: Phone and Media Cores Abstract Windows Embedded Automotive 7―based on the newest generation of embedded operating systems from Microsoft, and combining the award-winning Windows Automotive and Microsoft Auto platforms―is designed specifically for developing state-of-the-art, in-vehicle infotainment systems. It offers a standardized, industry-proven platform for building communication, entertainment, and service-enabled location-based solutions.
Table of Contents INTRODUCTION .....................................................................................................................4 WINDOWS EMBEDDED AUTOMOTIVE IN USE TODAY ..............................................................4 SIMPLIFIED UI DEVELOPMENT WITH SILVERLIGHT FOR WINDOWS EMBEDDED ........................5 DISPLAY .......................................................................................................................................... 8 Display Driver ...
GSM SMS AT Command Support ............................................................................................ 44 SMS Stack and MAP Service ................................................................................................... 44 BLUETOOTH AUDIO/VIDEO (BTAV) SERVICE ...................................................................................... 45 CALENDAR.............................................................................................................................
Introduction With Windows Embedded Automotive 7 application software developers and automotive electronics engineers gain a rich environment from which they can add their own functionality to create a broad range of advanced, in-vehicle solutions that meet the growing needs of consumers while setting the products apart from the rest of the field. The flexible Windows Embedded Automotive 7 platform targets a wide range of devices, including connectivity gateways, connected radios, and multimedia devices.
stations, make or answer phone calls, and more. By supporting complex grammar, UVO needs only short voice commands to connect drivers and passengers with their desired functions. An interactive system, UVO responds to inquiries such as “What’s playing?” and provides audible responses and related functions, allowing drivers to stay safely focused on the road.
1. Design the user experience in Microsoft Expression Blend. 2. Develop the business logic in Microsoft Visual Studio with Silverlight for Windows Embedded. 3. Run the HMI on the embedded device. This is a significantly easier process. Figure 1 compares current HMI design with that possible with Silverlight for Windows Embedded.
Figure 2 shows the Silverlight for Windows Embedded workflow. Figure 2: Silverlight for Windows Embedded workflow Silverlight for Windows Embedded provides a subset of the overall Microsoft Silverlight functionality for embedded devices. Unlike other versions of Silverlight, there is no managed application programming interface (API) and no browser plug-in.
OpenVG1.1-based sample render plug-in is provided, and customers can modify it to use any vector graphic APIs (see Figure 3). Figure 3: Detail of Silverlight for Windows Embedded The automotive version of Microsoft Silverlight for Windows Embedded has extra elements that use XAML to compose additional, out-of-process graphics, such as maps and browsers, into an HMI.
When the system starts up, the display driver determines what type of vehicle display it needs to adapt to on the basis of a CAN message broadcast by the display head unit. Until that message is received, any requests for display write operations fail. Based on the received information the display driver chooses the appropriate character-set translation map, the supported display layouts, and a display-specific CAN signal assembly.
Projekt 2 Sample Application Microsoft provides the Projekt 2 sample UX application to help jumpstart OEM UX development. This application provides a sample framework that designers and application developers can use to design their own UIs. This speeds up the design and development process while providing an example of a safe and robust UI. Projekt 2 demonstrates the types of interactions that are supported by Microsoft Silverlight for Windows Embedded.
Projekt 2 UI Description The incoming call UI displays as a pop-up dialog over the currently selected UI. When a call is received, the application matches the caller ID information against contacts in the phonebook. If a match is found, the contact information is displayed, including name, phone number, and image. The UI provides options for controlling the call, including accept, ignore, and decline. The contacts UI provides the user access to the phonebook synchronized with the phone.
• SMS: The SMS supports access to SMS messages that are received by a connected Bluetooth phone and supports sending of SMS messages by a connected Bluetooth phone. SMS messages can be retrieved via AT commands or the Message Access Profile (MAP) service. Automotive 7 also supports MAP email from any Message Access Service (MAS) instance. Email can be retrieved from the Bluetooth-connected device and then handled by an appropriate application or service.
Figure 4: Phone Core architecture Phone Connection Management Windows Embedded Automotive 7 provides features to connect to a previously paired Bluetooth-enabled phone, as well as features to handle phone disconnects and phone availability. Only one Bluetooth-enabled phone can be connected at a time, and any additional attempts from other phones to connect to the Windows Embedded Automotive device are rejected.
Automatic Connection Windows Embedded Automotive 7 can automatically connect to a previously-paired phone, based on events initiated from applications or phone-related functions initiated by the user, such as pressing the Send button on the phone. Automotive 7 supports connection to a phone with an active call. If a call is in-progress at connection time, Windows Embedded Automotive queries the phone for the phone number and contact information if this feature is supported by the Bluetooth phone.
The Phone Core registry keys are: • • HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\PhoneCore HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\PhonebookOptions Table 2 details the Phone Core registry values. Table 3 details the PhonebookOptions registry key values. Table 2: Phone Core registry values HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\PhoneCore Key Value Type Description AutoConnectAttempt DWORD Specifies the number of loops through the paired phone list to attempt auto connect.
HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\PhoneCore Key Value Type Description RingtoneOption DWORD Specifies the ringtone configuration options: • 0—no ringtone • 1—ringtone temporarily silent • 2—in-band ringtone (SCO audio connection) • 3—default local ringtone • 4—local ringtone number 1 • 5—local ringtone number 2 • 6—local ringtone number 3 The default value is 0. HQRTOption DWORD Enables or disables high-quality ringtones (HQRT).
Message Description WM_PHONE_CALL_CONNECTED Posted when a phone call is connected. WM_PHONE_CALLACTIVATED Posted when a connected call becomes the active call. WM_PHONE_CALLERID Posted to indicate the caller ID. WM_PHONE_CALLINFO_UPDATE Posted when the connected call information is updated. WM_PHONE_CALLONHOLD Posted when a single call is on hold. WM_PHONE_CALLSTATE_CHANGE Posted when a call changes state. WM_PHONE_CALLWAITING Posted when an incoming call is waiting.
Message Description WM_PHONE_RING Posted when the phone is ringing. WM_PHONE_SENDDTMFCOMPLETE Posted when the user dials a digit, which generates a dualtone multi-frequency (DTMF) audio signal, during an active phone call. WM_PHONE_SERVICESTATE Posted to indicate the carrier and service state of the phone. WM_PHONE_SIGNALSTRENGTH Posted to indicate the signal strength. WM_PHONECORE_START Posted when the Phone Core component is initialized.
Figure 5 shows the components and relationships in the Phone Core Bluetooth stack. Figure 5: The Phone Core Bluetooth stack Table 5 lists the additional layers that provide the core of the Bluetooth stack. Table 5: Bluetooth stack layers Layer Function Baseband The physical radio layer. LMP Handles Bluetooth link establishment, authentication, and encryption.
Layer Function eL2CAP Provides enhanced error detection and flow control. SDP Gives devices the ability to discover what services other Bluetooth devices support and what parameters to use to connect to them. RFCOMM Provides RS-232 serial port emulation, up to 60 simultaneous connections. AVDTP Applies point-to-point signaling over a connection-oriented L2CAP channel, which enables Advanced Audio Distribution Profile (A2DP) streaming.
bit mask for 16 tunable settings. Microsoft does not recommend changing the settings, as this typically results in degraded audio quality. Two additional registry keys hold AEC/NS configuration settings: • • HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\HFP\SendNRECSetting HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\HFP\NoiseSuppressSetting Table 6 lists the key values that can be configured for each registry key.
• • • • • • • • • • • • • • Serial Port Profile (SPP) 1.1 Phone Book Access Profile (PBAP)-Phonebook Client Equipment (PCE) 1.1 A2DP-SNK 1.2 AVRCP-Controller 1.4 HFP-HFP 1.5 (backward compatible to HFP 1.0) Dial-Up Networking Profile (DUN)-DT and GW 1.1 MAP 1.0 SyncML 1.1.2 Bluetooth SYNCH IrMC-Client 1.1. SIM access profile (SAP) Client 1.1 Device ID profile 1.3 Human Interface Device (HID) Profile 1.0 Personal Area Network (PAN) Profile 1.
Several Automotive 7 applications rely on the Bluetooth Pairing Core, including the phone application, the media player, Windows Embedded Automotive shell, and the SMS application. Other applications can also use the Bluetooth Pairing Core API to pair and communicate with Bluetooth-enabled devices via the Bluetooth Pairing Service. The Bluetooth Pairing Core consists of two parts: the service component, which is loaded by Services.
Figure 6 shows the components and data flow of the Bluetooth Pairing Core and Bluetooth Pairing Service architecture. Figure 6: Bluetooth Pairing Core and Bluetooth Pairing Service architecture Bluetooth Pairing Service The Bluetooth Pairing Service manages the Bluetooth service discovery process and the device pairing process. It provides an interface to control the discovery and pairing process and to manage the list of paired Bluetooth-enabled devices.
Automotive 7 phone application currently supports up to five paired phones. Up to 12 configurable media devices can be simultaneously connected through A2DP, in addition to a single phone.
Appendix 2: Bluetooth Pairing Service Registry Key Values for the key values. Discovery Mode and Discoverable Mode Discovery mode allows an Automotive 7 device to search for a nearby Bluetooth-enabled device to pair with. Discoverable mode allows an Automotive 7–based device to be found by a nearby Bluetooth-enabled device so that the Bluetooth-enabled device may establish a pairing relationship to the Automotive 7–based device.
fast access to the phone’s phonebook data through the Automotive 7 device’s UI. See the Sync Manager and Phonebook sections for more information about this capability. Hands-free Profile Service HFP support is provided by the Hands-free Phone Core (HFPCore) service and the Bluetooth Pairing Service, which provide support for the Bluetooth SIG Hands-free Profile v1.5. The hands-free profile (HFP) service provides users with hands-free access to their mobile phone.
Figure 7: HFPCore service architecture Windows Embedded Automotive 7 Deep Dive: Phone Core and Media Core 28
The HFPCore provides the following capabilities: • • • • • • • • • • • • • • • • • • • • Handle Bluetooth HFP port connected/disconnected status Place calls by number Report whether a call is connected or disconnected Report call privacy status Notify an application of an incoming call Enable/disable in-band ringing Provide ring type, such as local ringtone (WAV), SCO, and A2DP Report various phone status items, such as caller ID, signal strength, and battery level Notify an application when caller ID is r
Multiple Simultaneous Calls A user can accept or place a second call while on an active call. When the user makes or accepts a second call—for example, a call waiting call—the active call is placed on hold, and the second call becomes the active call. The user can then either switch the calls or join them into a conference call. The application alerts the user through the UI that the first call is on hold. Table 7 shows the multiple call behaviors supported by Windows Embedded Automotive 7.
Status Action Behavior +CLCC Support Conference call Regular terminate No calls N/A One call active Second call incoming Regular terminate One call active Second call rejected N/A One call active Second call on hold Regular terminate Second call active N/A One call on hold Regular Terminate No calls N/A Conference call with x and y number of calls Terminate call y Call x active Call y terminated +CLCC required One call active Second call on hold Terminate second call First call act
• • • Pressing “END” while on a single active call terminates the call. Pressing “END” while in a conference call terminates both active calls. Pressing “END” during a dual-call state causes the active call to be terminated. The on hold call is then made active. Dialing Feature Support Automotive 7 provides the following dialing capabilities: • • • • • Handset keypad dialing Speed dial Redial Digit Dialing DTMF Handset Keypad Dialing Automotive 7 lets a user dial using a connected handset.
Table 8: Phone feature support Feature Description Signal Strength On phones which support signal strength reporting over Bluetooth, Windows Embedded Automotive 7 reports this value to the user. Roaming Report On phones which have a roaming indicator available via Bluetooth, Windows Embedded Automotive reports this value to the user when paired with a platform having the appropriate display.
occur before defaulting back to the local ringtone. When this registry setting is not present, the default value is 3. See Table 2 for more information about these settings. Table 10 and Table 11 show the Windows Embedded Automotive 7 settings and the relationship between phone behavior and the resulting ring.
The interface for GetLastError is located in HFPAPI.h. The WM_HFPERRORLOG message is raised when a new error is logged by the HFPCore service. The buffer that contains the errors is configurable through the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\HFP The ErrorLogMaxEntries key value determines the number of error messages that are stored in the buffer. The default value is 5. The log is cleared when the HFP connection to the phone is closed.
Class Code in wParam CMS Errors (phone response included) 0x00002000 Standard error values, as defined in the GSM specification, are appended to the wParam value. HFP Port Failures 0x00004000 Sync Manager and Phonebook Windows Embedded Automotive 7 provides users with the ability to access their phone’s contact information through the UI.
Figure 8 shows the phonebook architecture. Figure 8: Phonebook architecture Phonebooks are stored on a per-phone basis. Automotive 7 provides the following high-level phonebook storage functions: • • • • When a phone is first paired the phonebook is downloaded from the phone and stored locally. When a paired phone is reconnected, Automotive 7 refreshes the stored phonebook. When a paired phone is disconnected, Automotive 7 does not delete the phonebook, but keeps it in storage.
The enhanced POOM contains the following features: • • • The AUTOPOOM schema, with support for Bluetooth addresses and the Bluetooth SyncIndex Support for image files (for example, images of email recipients) Significantly increased contact search speed Applications can access the contacts database and read and write to it when using POOM storage. However, the Sync Manager service assumes that other applications will only read from the contacts database.
• database because several entries might exist with the same first name and last name combinations. When designing a UI, assume that multiples of all fields in POOM may be returned for any given first name and last name combination. Include the ability to display multiple numbers under a single location tag (for example, HOME: 2065551212, 4255551212,). The APIs provide parsing of multiple POOM fields when contact names and phone numbers are retrieved.
Phonebook Implementations Automotive 7 provides modern phonebook implementation types while remaining compatible with prior Microsoft Auto phonebook types. All elements of pre-Microsoft Auto 4.0 phonebook types are statically built into the HFP service. Microsoft recommends using the Sync Manager because it can manage multiple download types, it is extensible to providing new services and it can handle phonebook, calendar, and email synchronizations.
Note: OBEX contacts are downloaded using the HFPAPI, not through the Phone Core API. Figure 9 shows the various components and relationships of the OBEX stores. Figure 9: OBEX phonebook stores Sync Manager Architecture The Sync Manager architecture provides interoperability between the various phonebook features, such as POOM, image storage, multiple location, and other key features that are only available when using POOM.
Figure 10 illustrates the Sync Manager architecture. Figure 10: Sync Manager architecture SMS Support and Email Windows Embedded Automotive 7 supports access to and sending of SMS messages using a connected Bluetooth phone. SMS messages can be retrieved via GSM AT commands or the MAP service. Automotive 7 also supports MAP email from any MAS instance. Email can be retrieved from the Bluetooth-connected device and then handled by an appropriate application or service.
Figure 11 shows the SMS support architecture. Figure 11: SMS support architecture The SMS architecture contains both the SMS drivers and the subscriber identity module (SIM) drivers. The SMS drivers provide the standard Windows Embedded Compact device driver interface for SMS.dll. The SMS drivers also contain the SMS router and SMS store components. The Bluetooth Text Provider handles text messages sent using a paired Bluetooth phone. The SMS store caches SMS messages in the CellCore message queues.
An SMS application that is provided by an OEM should use the SMS router API to subscribe to messages. This method lets messages be filtered and even targeted for specific applications through the SMS router. Message filtering, parsing, and targeting are all configurable. GSM SMS AT Command Support A phone must support MAP or GSM SMS AT commands to operate with Windows Embedded Automotive 7. Phones must be able to send, receive, notify, and download all unread messages.
Bluetooth Audio/Video (BTAV) Service The BTAV service supports both A2DP 1.2 and AVRCP 1.4. This service manages the A2DP and AVRCP profiles and interfaces to Phone Core and Media Core. For A2DP, Media Core controls the connection management, media streaming, and player control. Figure 13 illustrates the BTAV service architecture. Figure 13: BTAV service architecture The following tables list the registry settings for the BTAV service.
HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\BTAV All keys and values under the BTAV key are optional. The BTAV service will use default values if a value is missing or outside of the appropriate range. This key includes one subkey for each supported codec. Name Type Description ConnectionStepWait DWORD The sleep time between each step (Discovery, GetCapabilities, SetCapabilities, OpenStream) while connecting to the device. The default value is 150.
HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\BTAV All keys and values under the BTAV key are optional. The BTAV service will use default values if a value is missing or outside of the appropriate range. This key includes one subkey for each supported codec. Name Type Description WaveOutDevice DWORD The device Line Out ID for the wave driver that is assigned to A2DP when the wave driver has multiple line outs. The default value is WAVE_MAPPER.
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT \BTAV\SBC The Sub-Band Coding (SBC) codec is the only required codec for the A2DP. This registry key is used to store default information for the SBC codec. Name Type Description MinBitpool DWORD The minimum bit pool value supported. This value must be between 2 and 25. The default value is used when data is outside the range of 2 to 250, or if MaxBitpool is smaller than MinBitpool. The default value is 18. MaxBitpool DWORD The maximum bit pool value supported.
By default, notifications are turned on. You can also configure POOM notifications to download calendar and task information and to alert users of upcoming appointments. New to Automotive 7 is full appointment recursion support. Users can set up recurring appointments on their mobile device. The recurring appointments are downloaded and handled as recurrences in Automotive 7.
HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\HFP\PhoneSpecificMasks\\ Key Description SKIPCERTAINPBSTORE Allows the HFP service to ignore certain AT PB phone stores during AT phonebook download. SKIP_AT+NREC Does not send the AT+NREC=0 command on the opening of the HFP port. Can be overridden by HFPSetNRECOption. TIMEOUT_AT_CPBS Addresses some phones timing out on the AT+CPBS. TIMEOUT_AT_CPBS_2 Provides second chance for phones that time out on AT+CPBS.
HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\HFP\PhoneSpecificMasks\\ Key Description MAPSMS_SKIPUPDATESTATUS Does not update the read status for MAP. SEND_NREC_ON_SCO Sends an NREC command when using SCO. Windows Embedded Automotive 7 reports compatible behaviors for each paired device via the HFPPHONECAPS API as determined by the phone services. These values are saved in the device pairing key in the registry and can be modified by advanced users on a per-pairing basis.
Key Value Description eCallerIDSupport Phone supports AT+CLIP. eSMSCmdSupport This setting can have three values: • • • 2 – unknown 1 – supported 0 – not supported This value is initially it is set to 2. At the first connection, this value gets set to either 0 or 1 depending on whether or not the phone passes the SMS scan. In some application designs, if this value is 0, users cannot enter the SMS application. A value of 0 should not get changed to 1 via the API unless the phone passes SMS scan.
Figure 14: Connection Manager The Connection Manager supports the following CSPs: • • • • RAS CSP provides General Packet Radio Services (GPRS) and dial-up connection support. When used with a Bluetooth phone, RAS CSP relies on the setup menu HMI for configuration of the dial strings. Voice CSP helps with the coordination of circuit switched data (CSD) and voice calls on an embedded phone. The HFP service calls into the voice CSP for operations that are related to voice calls on an embedded phone.
The Bluetooth DUN profile defines two roles: Gateway (GW) and Data Terminal (DT). Automotive 7 devices operate in the DT role, whereas Bluetooth-enabled phones with internet access operate in the Gateway role. Applications use the Connection Manager to establish a dial-up networking connection. The Automotive 7 device first calls ActivateBTDevice to establish a Bluetooth DUN connection to the Bluetooth-enabled phone.
service is a miniport network driver that creates network connectivity between two Bluetooth devices. PAN can be configured via the PAN registry keys and key values, shown in Table 19 and Table 20. Table 19: PAN registry key values HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\pan Key Description ActivateOnBoot Determines whether Bluetooth PAN is automatically activated when the device starts up. Note that when PAN is activated, an SDP record is registered and the application needs to stay loaded.
HKEY_LOCAL_MACHINE\Comm\BTPAN1\Parms Key Description ServiceID Specifies the global service identifier as a standard globally unique identifier (GUID) string. SIM Access Profile Windows Embedded Automotive 7 provides support for SAP, a Bluetooth profile that makes the account information on a Bluetooth-enabled phone available for use by the phone module integrated into the Automotive 7–based device.
Media Core Deep Dive With Windows Embedded Automotive 7 Media Core, users can use intuitive user interfaces to enjoy their media—whether stored locally on the Automotive 7 device or through connected media players or Bluetooth-enabled phones. Media Core provides OEMs a robust set of APIs and services that access and control stored media and media metadata.
Figure 17: Media Core APIs Another layer, the Media Core API, is delivered as part of the Windows Embedded Automotive 7 platform. Developers can configure and plug into it, but cannot change it because it is a binary. The Media Core API layer comprises three parts: Playback, Browse, and Index Access APIs. The Playback API set offers device-agnostic command and control.
Finally, the device services layer of the Media Core architecture contains service modules for devices that are supported out of the box. As with the source plug-ins layer, OEMs can access the Windows Embedded Automotive 7 platform to extend or add functionality to the device services layer.
Each metadata parser is a COM object associated with a registered file name extension and a registered class identifier (CLSID). On startup, the mass storage class MSC plug-in reads the registry and generates a list of known file name extensions. When an MSD or a direct mass storage device (DMSD) source plug-in reads a file, the plug-in creates a metadata parser on demand. Playlist parsers work in much the same way.
• • • • Digital Living Network Alliance (DLNA): DLNA defines a standard for transferring movies, photos, music, and other media from one device to another. DLNA servers can store media in one location and stream the media to DLNA-compliant players without any setup or configuration. Media Core acts as a Digital Media Player (DMP) attached to a Digital Media Server (DMS) or Mobile Digital Media Server (M-DMS) to consume audio content.
Building a Media Application Media applications use Media Core to abstract and manage device-specific interactions, such as indexing and playing. Automotive 7 includes a sample media player that OEMs can use as a foundation for creating a media application.
Playback You can use the following control functions to automate stop, resume or fast forward for your media application: • • • MediaPlayControl: Pass commands to this function. MediaGetCurrentStatus: Retrieves the structure that has the current status and the position of the current track. If you want to display the artist and title, use this function to display metadata.
• • • Browsing by categories on iPod devices is not supported when the selection order is lower to higher (for example, album, artist, and genre). There is no workaround for this. Other types of devices have a file/folder hierarchy model. Therefore, you must wait until indexing is complete before calling browse API commands. If you issue a browse command before the connected device is indexed, the media player will generate an error message.
Appendix 3: Media Core Registry Settings. Media Core Windows Messages Media Core features a full set of messages it can send to registered applications. The messages include SOURCEID, which is an important element that comes with many of the messages in the lParam argument. SOURCEID allows the application to accurately map the message to the source.
Table 21 lists the messages provided by Media Core. Table 21: Media Core messages Message Description WM_INDEXING_DONE Posted when all indexing has been completed. WM_MEDIA_COMMAND_ERROR Posted when a MediaPlayControl command is not implemented by the receiving source class type, or when the command failed to execute. WM_MEDIA_COMMAND_NOTIMPLEMENTED Posted when a MediaPlayControl command is not implemented by the receiving source class type, or when the command failed to execute.
Message Description WM_STORAGE_LOST Posted when an index is lost because the media source for the index was removed, and the original index was overwritten by another index from a recently inserted device. WM_STORAGE_LOW_POWER Posted when a media source is no longer available because of a low power state. WM_STORAGE_REMOVED Posted when a storage card is removed. WM_TRACK_COMPLETE Posted when each audio track in a playlist is finished.
Custom Media Device Class The custom media device class in Windows Embedded Automotive gives additional sources the ability to plug into Media Core by providing standard interfaces to expose indexing and playback to Media Core. Additional sources that take advantage of this capability might include DLNAcertified devices and devices based on future or proprietary protocols. This feature provides the ability to developers to create optional extensions for applications.
to call a parse function that takes the file path as an input parameter. If both parse functions fail, Media Core tries the next parser of the file extension, if there is any. Each metadata file parser must implement at least one of IMediacoreMetadataBufferParser and IMediacoreMetadataFileParser. These interfaces are defined in public\automedia\oak\inc\mediacoremetadataparser.h. Playlist Parser The playlist parser interprets playlist format.
4. As soon as track metadata is updated, the WM_UPDATE_METADATA_COMPLETE message is sent to the application. The COM object must implement and expose the IMediametadataProvider interface. This interface is defined in public\automedia\oak\inc\mediametadataprovider.h. These interfaces provide Media Core the ability to interface with the COM object. In addition, the COM object uses some public Media Core APIs to complete the metadata process.
subscribed for notifications for a specific protocol. To unsubscribe, the application must call IPSUnregisterForNotifications. After an application requests a session with Windows Embedded Automotive 7, the subscribed application receives an IPM_OPENSESSION message with wParam set to SessionID and lParam set to ProtocolIndex. The application can then open an application-to-accessory session by using IPSOpenA2ASession.
Considerations for MTP To control devices that use MTP an application must get a handle to the device and control the device through the MTP service. The service handles are found through the following APIs: • • • MediaGetDeviceHandle MediaBrowseGetItemObjectHandle MediaGetItemObjectHandle These APIs are defined in public\automedia\sdk\inc\automediacoreex.h. Applications can issue commands directly to the device handle using MTP IOCTLs.
Appendix 4: Compatible Deviceslists the compatible devices as of this document’s publication date. During extensive testing in the Device Lab, Microsoft engineers make a reasonable effort to work around device issues. The engineers inform device manufacturers when incompatibility and specification compliance issues are discovered during testing. If problems with compatible devices are discovered, the Microsoft Auto QFE process is used to address them.
Appendix 1: Globalization Features In today’s international business climate, OEMs with multinational product lines require a platform that can be used across the globe. Windows Embedded Automotive 7 is designed with globalization in mind, and supports multiple code pages and encodings for various global languages. This support for a wide range of character sets and languages makes Automotive 7 an ideal platform for creating global solutions.
Feature Code Pages/Encodings Media Playlist Parsing UTF-8 Unicode big-endian Unicode little endian Windows Embedded Automotive 7 Deep Dive: Phone Core and Media Core BIG5 (Taiwanese) GB18030 (Chinese Simplified and Chinese Traditional) 75
Appendix 2: Bluetooth Pairing Service Registry Key Values After a Bluetooth-enabled device has paired successfully to a Windows Embedded Automotive 7 device, information about the paired device is available in the Automotive 7 system registry. Each paired device has a corresponding registry entry under HKEY_LOCAL_MACHINE\Drivers\BuiltIn\BTPairSvc\Devices. This registry key contains subkeys for each Bluetooth profile supported, and a subkey named \Attributes which contains devicespecific information.
Sub–key Value Description [HKEY_LOCAL_MACHINE\Drivers\BuiltIn DWORD Indicates CHLD features. String Indicates manufacturer of the paired device. String Indicates model of the paired device. DWORD AT+CIND command that indicates cell-indicator status for "battery". DWORD AT+CIND command that indicates cell-indicator status for "callheld". DWORD AT+CIND command that indicates cell-indicator status for "signal". DWORD AT+CIND command that indicates cell-indicator status for "call_status".
Sub–key Value Description [HKEY_LOCAL_MACHINE\Drivers\BuiltIn BLOB Indicates phone capabilities. DWORD Indicates whether a new contact has been added. DWORD Indicates exclusive attribute value. DWORD Indicates order in which paired devices are accessed for Bluetooth Audio/Video. DWORD Indicates order in which paired devices are accessed.
Appendix 3: Media Core Registry Settings Table 25: Media Core registry settings HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AutoMediaCore\Config Key Value Type Description MountWaitTimeout DWORD How long the media player waits after an ignition on event before releasing audio focus back to the radio if no media is detected. If this time-out period is longer then there is more quiet time while no media is found. The default value is 0x1f40 (8 seconds).
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AutoMediaCore\Config Key Value Type Description AllowableUsedSpace DWORD The threshold at which Windows Embedded Automotive dumps the old index because it contains too much stale information. This value is used when multiple Quick Scans are performed on the index. The default value is A (10). SpaceDifference DWORD The space difference between two indexes. This is used to determine whether the current index is a possible match for a previously built index.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AutoMediaCore\Config Key Value Type Description PlaybackTimerDelay DWORD The number of milliseconds to wait after a play request before begin rendering media. This is a performance-tuning setting that enables the playback manager to better handle the action of the user quickly pressing a button that corresponds to playback controls such as Play, Next, or Previous. The default value is 0x00C8 (200 milliseconds).
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AutoMediaCore\Config\MSD Key Value Type Description PreScanDuration DWORD The length of time that the media player collects track information before it starts AutoPlay. The collected track information becomes the complete selection of files available for AutoPlay. Increasing this length of time also increases how long you must wait to hear media playback. The default value is 0x0FA0 (4 seconds).
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AutoMediaCore\Config\Fields\ These keys enable new metadata fields to be indexed by Media Core. Each key contains the following values. Key Value Type Description CategoryId DWORD The unique identifier for this metadata field. The value must be greater than 0x100 and cannot exceed 0xFFFF. MediaDataType DWORD The type of data that is expected for the metadata. The value must be of type MEDIA_DATA_TYPE. The default value is MediaTypeUnknown.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AutoMediaCore\Config\LocalSource These keys contain configurations common to all local sources. Key Value Type Description BackupPersist DWORD If set to 1, then a backup of a persisted index is created before trying to create a new persisted index. If the current persisted index is corrupt when initializing the local source then the backup is used. SourcePath STRING Fully qualified path of the local source. For example, \ATAPI Disk\User 1\Local Source.
HKEY_LOCAL_MACHINE\Services\IPDSvc These keys contain general settings for the iPod service. Key Value ComPort Force service to search for iPod device on specified COM port. If this is not set, service will monitor for attachment of USB2SERIAL cable. SamplingRates List of audio sampling rates that hardware audio decoder supports. By default, it is 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000.
HKEY_LOCAL_MACHINE\Services\IPDSvc\AccessoryInfo Accessories are required to send information to the connected iPod device that identifies them. Accessory information is required to get “Works for iPod/Made for iPhone” certification. The iPod service will load the following configurable registry keys and send the required information to the iPod when the iPod device is connected. Key Type Value BundleSeedIDPrefToken String Identifies the application that is set up for EAF with the automotive device.
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IPDSvc Key Type Definition PersistShuffleAndRepeat DWORD Sets the shuffle and repeat persistence when an iPod device is attached. A value of 1 means that the current shuffle and repeat settings of the attached device will be used for playback. HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IPDSvc1 Key Type Definition DLL REG_SZ Name of DLL. The default value is IPDSvc.DLL. Prefix REG_SZ Index DWORD Prefix for registered device name.
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IPDSvc2 Key Type Definition DLL REG_SZ Name of DLL. The default value is IPDSvc.DLL. Prefix REG_SZ Prefix for registered device name. Prefix and Index together are the device name. In this example, "IPD1:" is the registered device name. The default value is IPD. Index DWORD Hex value. Unique index from 1 to 9, inclusive. The default value is 1. Order DWORD Hex value. Boot order: 110. The default value is 6E.
HKEY_LOCAL_MACHINE\Drivers\MtpHostUsbCdd Name Type Description UnsupportedDeviceList Binary The list of devices with unknown interfaces that are not MTP. Will be updated through usage. USB_DEVICE_LIST format. The default value is 0. FuzzFlags DWORD Used by the test MtpHostUsbCddFuzzer.DLL only.
Name Type Definition DLL String DLL for MTP service. The default value is MtpSvc.DLL Prefix String MTP Service name prefix. The default value is MTP. Index DWORD MTP Service name index. The default value is 1. Order DWORD Controls the order in which the MTP service is loaded compared to other services. The default value is 0x6E.
Table 32: MTP song formats registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\MTP\Audio\SongFormats This registry key is used to enumerate the object formats that will be considered songs by the MTP service. Supported song formats are listed under this key by creating a new key with the matching MTP format code in hex. Defaults to WAVE, MP3 and WMA (3008, 3009, B901).
HKEY_LOCAL_MACHINE\Software\Microsoft\Automotive\MTP\Devices\Zune\Indexing Name Type Definition Indexing\MaxPUIDHashSize DWORD Set to 0 to turn off PUID caching. The default value is 50000. Indexing\UseObjectPropertyCache DWORD This is should be set to 0 because PUID caching overlaps with ObjectPropertyCaching. The default value is 0. Audio\UseGetObject DWORD The default value is 1.
Appendix 4: Compatible Devices The following is a list of phones tested and determined to be compatible with Windows Embedded Automotive 7.
Phone Manufacturer Huawei Kyocera LG LG MIO Motorola Model Phone Manufacturer U7300 U7510 E2500 Strobe AX490 AX585 Rhythm CF360 Chocolate (VX8500) CT810 [Incite] CU500 enV Touch VX11000 expo GW820 GC900 GD580 GD910 GM200 GR500 Xenon GW520 HB620T KC910 KC780 KE500 KE850 KE970 KF350 KF700 KF750 KG195 KG800 (Chocolate) KM501 KP500 Cookie KS200 KS500 KU800 KU990 LX160 ME770 Muziq (LX570) Rumor Scoop (AX260) Trax (CU575) Venus (VX8800) Voyager VX 9200 [LG enV3] VX8300 VX8575 Chocolate Touch VX9900 KF600 Lo
Phone Manufacturer Motorola Motorola MWG NEC Nokia Model Phone Manufacturer A1200 Ming ACTV Clutch i465 E770 EM330 Hint QA30 i365 i580 i776 i880 Krave ZN4 KRZR K1m (Verizon) MPX220 Q9C Q9M RAZR Maxx Ve RAZR V3a RAZR V3i/V3r RAZR V3m (Verizon) RAZR V3xx RAZR V8 RAZR2 V8 RAZR2 V9M Rival A455 RIZR Z6TV Sidekick Slide SLVR L7 U9 V525 V635 VA76r Tundra VE538 W377 W490 Z9 L9 Atom V e132 2660B 2680s-2b 2760 3555 5230 5310 Express 5500 5610 XpressMusic 5730 6021 6103 6125 6131 6133 Black 6165 6210 Navigator
Phone Manufacturer Nokia Nokia Palm Pantech Pharos Porsche Samsung Model Phone Manufacturer 6230i 6267 6280 6301 6315i 6500 Slide 6600 6620 6682 6760 6822a 7210 Supernova 7373 7510a-b 7705 Twist 809 8800 9500 E51 E61i E65 E71 E73 Mode E90 N73 N76 N79 N81 N85 N86 N91 N96 Centro (AT&T) Pixi Treo 680 Treo 755p Treo Pro C3B C630 Duo Pro C820 Traveller 117 P'9521 A237 A657 Alias 2 Behold-SGH-T919 C3053 D807 Delve SCH-R800 E250 Eternity F200 Giorgio Armani -SGH-P520 Windows Embedded Automotive 7 Deep Div
Phone Manufacturer Samsung Samsung Sanyo Model Phone Manufacturer GT-B3310 GT-I8000 GTS 5230 GT-S3653 GT-S5600 HIGHNOTE i600 i760 Instinct Intensity SCH-U450 L770s M520 Omnia Player5 Rant Renown S3600 S8300 SCH-A990 SCH-R600 Hue II SCH-U550 Seek SGH-A777 SGH-A837 SGH-A887 SGH-D880 SGH-E380 SGH-F110 SGH-F330 SGH-F480 SGH-G800 SGH-I637 SGH-I900 Omnia SGH-M150 SGH-P180 SGH-T429 SGH-T539 (Beat) SGH-T639 SGH-T819 SGH-U700 SGH-U900 SGH-Z510 SPH-A900 SPH-i350 Intrepid T509 Black T629 T939 U740 Z230 Z510 GT-I
Phone Manufacturer Sharp SoftBank Sony Ericsson Sony Ericsson T-Mobile Toshiba UTStarcom Model Phone Manufacturer Sidekick LX 706SC C902 C905 D750i F305 G705 J105i K510i K630i K700i K770i K810i M600i P1i P990i R306 S312 S710a T280i T610 T637 T700 T715 TM717 U10i W205 W350i W395 W518a W660i W705 W760a W850i W890i W950i W980 X1 Z310a Z600 Z750 Dash (1.
The following is a list of media devices tested and determined to be compatible with Windows Embedded Automotive 7.
Media Device Manufacturer Model Philips RCA RCA Samsung SanDisk SanDisk Sony Toshiba Transcend Zvue Media Device Manufacturer N86 5610 6301 GoGear ViBE SA1VBE08K/17 GoGear-Aria GoGear SA6045 SA1ARA08K/17 Lyra X3030 Opal M4004 Samsung Player 5 SGH-A897 F330 S3600i SGH-i450 GT-S3100 Intensity SCH-U450 Samsung S5 Samsung YP-K5 Samsung YP-S5 Samsung YP-T9 SGH F-480 SGH-A877 YP-T10JAG YP-Z5AB Sansa e250 Sansa Connect Sansa Fuze Sansa View Sansa E140 Walkman NWZ-X1061 Walkman NWZ-E345 NW-A1200 NWZ-A829 N
Glossary A2DP—Advanced Audio Distribution Profile. A2DP defines how high-quality audio (stereo or mono) can be streamed from one device to another over a Bluetooth wireless technology connection. command set consists of a series of short strings that combine together to produce complete commands for operations such as dialing, hanging up, and changing the parameters of the connection. AAC—Advanced Audio Coding.
Codec—A device or a program that is capable of encoding and decoding a digital data stream or signal. Windows Embedded Automotive 7 only provides productionlicensed decoders for Windows Media Audio and a development license for MP3. CSP—Connection Service Provider. A CSP provides connection information to the Connection Manager application, writes provisioning information that is received from the service providers to the registry, and binds connection requests to the NDISUIO (NDIS User-Mode I/O) Driver.
responsible for controller management, link establishment, and maintenance. HFP—Hands-Free Profile. HFP is commonly used to allow automotive hands-free kits to communicate with mobile phones in the car. HMI—Human-Machine Interface. The HMI is the means with which users can interact with the system, including input and output capabilities. IMGFS—Image File System. IMGFS is the main Windows Embedded CE image with the TFAT partitions included. IOCTL—Input/Output Control.
devices. Many PDAs use OBEX to exchange business cards, data, and applications. OPP—Object Push Profile. OPP defines the requirements for the protocols and the procedures to be used by the applications that are involved in the pushing and pulling of data objects between Bluetooth devices. PBAP—Phone Book Access Profile. PBAP enables the exchange of Phone Book Objects between devices. It can be used between a car kit and a mobile phone to let the car kit display the name of the incoming caller.
RTC—Real-Time Clock. A computer clock, usually in the form of an integrated circuit, that keeps track of the current time. SAPI—Speech API. SAPI is an API that was developed by Microsoft for speech recognition (converts spoken words to machine-readable input) and text-to-speech (the artificial production of human speech) within Windows-based applications. SAT―Satellite radio.
that is presenting a Windows® Sockets Specification 1.1 interface. TFAT—Transaction-safe FAT. A TFAT file system is a file system that is designed specifically to provide transaction safety for data that is stored on a disk. TFAT requires a hardware-specific driver that is designed for the type of media on which the TFAT volume resides. TLB—Translation Lookaside Buffer. A TLB is a CPU cache that memory management hardware uses to improve virtual address translation speed. TMC—Traffic Message Channel.
