Surround Sound in Car Audio Systems

Abstract

A method for adapting an automotive audio system to support surround sound comprises: configuring an application program for creation of an audio track object that specifies a pass-through mode as a playback mode, where the application program is installed to run under an operating system that is not configured for surround sound; configuring the operating system framework with a bypass past a mixer of the operating system, where the bypass allows surround sound data of the audio track object to bypass the mixer; and configuring a hardware abstraction layer with a separate channel for the surround sound data received from the operating system, where the hardware abstraction layer processes the surround sound data before providing the processed surround sound data to a decoder.

Description

[Technical field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims priority to U.S. patent application Ser. No. 63 / 265,451, filed on December 15, 2021, and entitled “SURROUND SOUND IN AUTOMOTIVE AUDIO SYSTEM,” the disclosure of which is incorporated by reference herein in its entirety.

[0002] The present disclosure relates to providing surround sound in automotive audio systems. [Background technology]

[0003] Vehicles have had audio systems for decades, but they generally have not been able to provide a listening experience approaching the most sophisticated systems used in public venues, such as movie theaters, or in the rapidly developing field of high-end home surround sound systems. However, the development and sophistication of vehicle technology has changed the competitive landscape in this regard. First, today's vehicles are provided with significantly more powerful computer processing resources that may raise the owner's or other passengers' expectations of what the experience of riding in a modern vehicle should be like. Second, due to the proliferation of electric powertrains and developments in aerodynamic design, vehicles are becoming significantly quieter while traveling, which increases the opportunities for occupants to enjoy first-class audio performance. Summary of the Invention

[0004] In a first aspect, a method of adapting an automotive audio system to support surround sound comprises: configuring an application program for creation of an audio track object that specifies a pass-through mode as a playback mode, where the application program is installed to run under an operating system that is not configured for surround sound; configuring a framework of the operating system with a bypass past a mixer of the operating system, where the bypass allows surround sound data of the audio track object to bypass the mixer; and configuring a hardware abstraction layer with a separate channel for the surround sound data received from the operating system, where the hardware abstraction layer processes the surround sound data before providing the processed surround sound data to a decoder.

[0005] Implementations may include any or all of the following features: Configuring the application program includes adding support for specifying the pass-through mode as the playback mode; The application program includes a condition for providing surround sound output that the framework of the operating system supports surround sound playback, and configuring the framework with the bypass causes the framework to satisfy the condition; The separate channel facilitates buffer management; The separate channel facilitates timestamp calculation; At least the processing of the surround sound data is performed using a first hardware board and at least the decoding is performed using a second hardware board separate from the first hardware board, and the hardware abstraction layer provides frame estimates to the application program using the timestamp calculation.

[0006] In a second aspect, a method of playing surround sound on an automotive audio system of a vehicle includes: creating an audio track object using an application program of the automotive audio system that specifies a pass-through mode as a playback mode, where the application program is installed to operate under an operating system that is not configured for surround sound; within the framework of the operating system, the surround sound data of the audio track object bypasses the mixer of the operating system; processing the surround sound data at a hardware abstraction layer of the automotive audio system; providing the processed surround sound data to a decoder to generate a decoded surround sound signal; and providing the decoded surround sound signal to at least one of a plurality of speakers of the vehicle.

[0007] Implementations may include any or all of the following features: The creating of the audio track object, the bypassing of the mixer, and the processing of the surround sound data are performed using a first hardware board, and the decoding and providing of the decoded surround sound signal are performed using a second hardware board separate from the first hardware board. The application program has a condition for providing surround sound output that the framework of the operating system supports surround sound playback, and the bypassing of the mixer causes the framework to satisfy the condition. The processing of the surround sound data includes buffer management. The processing of the surround sound data includes timestamp calculation. At least the processing of the surround sound data is performed using a first hardware board, and at least the decoding is performed using a second hardware board separate from the first hardware board, and the method further includes providing a frame estimate to the application program using the timestamp calculation. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram of an example of an audio system that can provide an immersive audio experience in a vehicle.

[0009] [Diagram 2] FIG. 1 is a diagram of an example of an audio system that supports surround sound.

[0010] [Diagram 3] 1 is a flowchart of an exemplary method for adapting an automotive audio system to support surround sound.

[0011] [Figure 4]1 is a flow chart of an exemplary method for playing surround sound over an automotive audio system of a vehicle.

[0012] [Diagram 5] 1 illustrates an example architecture of a computer system.

[0013] Like reference characters or numbers in the various drawings indicate like elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] This disclosure provides example systems and techniques for providing surround sound in an automotive audio system.

[0015] Examples herein refer to vehicles. A vehicle is a machine that transports passengers or cargo, or both. A vehicle may have one or more motors that use at least one type of fuel, or other energy source (e.g., electricity). Examples of vehicles include, but are not limited to, cars, trucks, and buses. The number of wheels may vary among multiple types of vehicles, and one or more (e.g., all) of the wheels may be used for propulsion of the vehicle. A vehicle may include a passenger compartment that accommodates one or more people. At least one vehicle occupant may be considered to be a driver; in this case, various tools, implements, or other devices may be provided to the driver. In examples herein, any human being carried by a vehicle may be referred to as a "driver" or a "passenger" of the vehicle, regardless of whether or to what extent the human is driving the vehicle, whether the human has access to all or only some of the controls to drive the vehicle, or whether the human lacks the controls to drive the vehicle.

[0016] 1 shows a block diagram of one example of an audio system 100 that can provide an immersive audio experience in a vehicle. The audio system 100 can be used with one or more other examples described elsewhere herein. The audio system 100 can be implemented using some or all of the examples described below with reference to FIG.

[0017] The audio system 100 may be implemented using one or more hardware boards. In some implementations, the audio system 100 includes a hardware board 102 and a hardware board 104 that are separate from each other. The hardware board 102 may be referred to as a communication control center (CCC). The hardware board 102 may include a user interface (UI) (e.g., as part of a human-machine interface in a vehicle) or a partition of memory of an operating system (e.g., for one or more types of files or folders); steering control; seat control; and / or a display unit to control system settings, to name a few. The hardware boards 102 and 104 may interface with each other using at least one bus 106. The bus 106 may be a standard bus for the transfer of streaming multimedia content.

[0018] In some implementations, the hardware board 104 may be connected to and interact with speakers, controls, vehicle sensors, and / or display vehicle information about speed or other information provided by the vehicle sensors. For example, the hardware board 104 may be referred to as an interactive control center (ICC). The hardware board 104 may run an audio mixer for the vehicle to determine which audio to prioritize, which audio to duck, and which audio to play out loud. For example, lane departure warnings may be generated by the hardware board 104. The hardware board 104 may be a LINUX console, to name just one example.

[0019] The audio system 100 may include an application layer 108. In some implementations, the application layer 108 may include a media application and optionally one or more other system applications. For example, the application layer 108 may include one or more of: a SPOTIFY application 110, a TIDAL application 112, an AMAZON ALEXA application 114, a navigation application 116, or a radio UI application 118.

[0020] The audio system 100 may include an operating system framework 120. Any of a number of operating systems may be used. In some implementations, the operating system is the ANDROID operating system. The framework 120 may include a mixer 122. In some implementations, the mixer 122 is provided by the operating system. For example, the mixer 122 may be provided using the ANDROID AUDIOFLINGER functionality. In some implementations, the application in the application layer 108 is running under the ANDROID operating system. For example, the application in the application layer 108 may be referred to as exoplayer for the ANDROID operating system.

[0021] The audio system 100 may include a real time protocol (RTP) component 124. In some implementations, the RTP component 124 may provide media streams over Internet Protocol to one or more applications in the application layer 108. For example, a radio tuner module 126 may generate the streams that the RTP component 124 provides to the radio UI application 118.

[0022] The audio system 100 may include a hardware abstraction layer (HAL) 128 coupled to at least the framework 120. The HAL 128 may be implemented using a partition in memory managed by the operating system of the framework 120. The HAL 128 may include one or more open bus pipelines 130 for providing at least one data stream to the processing components. For example, the processing components may provide stream processing and / or buffer management for the open bus pipelines 130. The HAL 128 may have one or more other components, including, but not limited to, components for BLUETOOTH (BT) call and media processing, components for audio policy configuration, components for generating triggers to the hardware board 104, and / or components for providing a transmission control protocol (TCP) communication channel.

[0023] The hardware board 104 may include a processing component 131 that receives one or more streams via the bus 106. In some implementations, the processing component 131 may provide decoding of data in the streams. For example, a DOLBY ATMOS decoder may be included within the processing component 131.

[0024] The audio system 100 may be adapted to support surround sound signal processing to provide an immersive audio experience to the listener. One or more of the applications in the application layer 108 may support surround sound encoded audio. In some implementations, the TIDAL application 112 may provide surround sound encoded data including a height dimension. For example, DOLBY ATMOS data may be provided. One or more other applications, in contrast (e.g., the SPOTIFY application 110 and the AMAZON ALEXA application 114), may not support DOLBY ATMOS audio data.

[0025] Applications that support surround sound encoded audio may be configured with the condition that the associated platform must support the corresponding playback capabilities. For example, the TIDAL application 112 may provide a DOLBY ATMOS data stream (e.g., a digital container of audio data) only if this is supported by the associated platform. Here, for example, the ANDROID operating system may not have native support for handling DOLBY ATMOS data streams.

[0026] One or more customizations may be provided in the audio system 100 to provide support for an immersive audio experience in which surround sound may be provided (e.g., using DOLBY ATMOS audio streams). If an application for surround sound encoded audio has the above-mentioned condition of support for corresponding playback capability, the condition may be satisfied by providing a bypass. Here, the customization 132 may be provided in the application layer 108. In some implementations, the customization 132 may modify the exoplayer library to add support for a pass-through playback mode in the framework 120. The audio track for java is a base class. There is also a default audio sync, and both the default audio sync and the audio sync may be part of the existing exoplayer. At least one of the default audio sync and the audio sync may create an audio track object through the audio track application programming interface and configure it into a playback mode. Examples of playback modes that may be provided using the customization 132 include, but are not limited to, an output pass-through mode and an output non-pass-through mode. In some implementations, audio track objects for surround sound playback (e.g., DOLBY ATMOS streams) may be configured into output pass-through mode. In some implementations, specific classes may be added to the exoplayer in customization 132 to support pass-through by audio track objects for surround sound data (e.g., DOLBY ATMOS streams).

[0027] Other customizations may also be made to facilitate configuration for pass-through mode. In some implementations, a utility class may be customized to calculate the number of channels the system can support. A system may have, for example, 6 channels with an output size of 768 bytes, so customization 132 may specify that 6 x 768 bytes may be sent by exoplayer.

[0028] In some implementations, customization 132 may specify audio capabilities. This may be done to expose to an application in application layer 108 what formatting capabilities exist within audio system 100. Such capabilities may include, but are not limited to, AC-3 (audio compression sometimes referred to as DOLBY AC-3), enhanced AC-3 (EAC-3), or joint object coding (JOC) formats (e.g., EAC3-JOC).

[0029] In some implementations, load control functionality may be provided or extended by customization 132. If more data is needed or requested, or if data is being fed, load control may be used for appropriate control or communication. In some implementations, a lower watermark and an upper watermark may be used. If the data load falls from or is below the lower watermark, the data mode may be up or otherwise increased to request more data from the application (e.g., exoplayer). If the data load reaches the upper watermark, more data is not requested.

[0030] Here, customizations 134 may be provided within the operating system framework 120. Customizations 134 may provide a bypass of a mixer that may be implemented within framework 120. Customizations 134 may facilitate surround sound streams from applications in application layer 108 not being mixed using any operating system features of framework 120, but rather being passed directly (e.g., by using output pass-through mode as the playback mode) to a specific partition (e.g., which may be referred to as a vendor partition) for processing by audio HAL 128.

[0031] In the audio HAL 128, the customization 136 may encourage bypass streams not to be run through a mixer in the framework 120; rather, encoded data from an application (e.g., a DOLBY ATMOS stream from the TIDAL application 112) may be received as raw data by the HAL 128. When the audio HAL 128 receives content from the framework 120, it may ascertain whether the content is a surround sound encoded stream or another stream (e.g., a stereo stream). Accordingly, these streams may be processed differently from each other within the audio system 100. For example, a stream from the SPOTIFY application 110 may be sent through the framework 120, and the mixer 122 (e.g., an ANDROID AUDIOFLINGER component) may perform mixing, and then the mixed data stream may be provided to the audio HAL 128. On the other hand, a surround sound stream (e.g., from the TIDAL application 112) may support at least two types of streams, including, but not limited to, a stereo stream and a DOLBY ATMOS stream. When a stereo stream from the TIDAL application 112 is received within the framework 120, it may follow the same path as the stream from the SPOTIFY application 110. In contrast, the ATMOS stream may bypass the mixer 122. In the audio HAL 128, the open bus pipeline 130 and certain other components (e.g., the BT call and media processing component, the audio policy configuration component, the trigger component, or the TCP communication channel component) may not receive or otherwise process the ATMOS data stream.

[0032] In the audio HAL 128, the customization 138 may facilitate mixer bypass and / or one or more other functions directed to supporting the provision of surround sound data streams to appropriate decoders. During surround sound playback, a driver may be opened or otherwise created within the audio HAL that performs buffer management. In some implementations, of the available channels, two channels may be used for a media studio, another channel may be used for a phone call, another channel may be used for a digital assistant (e.g., ALEXA Assistant), another channel may be used for navigation, and another channel may be used for the surround sound data stream. Interfacing between boards (e.g., hardware boards 102 and 104) may be associated with deadlines for time restrictions. That is, the audio HAL 128 may continuously receive data from an application and may not block data for more than a certain limit of time (e.g., a fraction of a second, including but not limited to, a few milliseconds). For example, if the audio HAL 128 does not receive more data in a timely manner, an underrun situation may occur. The buffers may be managed so that the UI (e.g., an ANDROID operating system) is not blocked while frames are processed in a timely manner. When data is dumped into a buffer of a particular size, a balance of how many bytes were received and how many were returned downstream in the audio system 100 may be incremented or otherwise updated. The audio HAL 128 may provide a report to an application (e.g., the TIDAL application 112) of how many frames were returned.

[0033] In some implementations, rendering may be performed on separate hardware (e.g., on hardware board 104 as opposed to hardware board 102) rather than processing by audio HAL 128. Thus, audio HAL 128 may not know exactly how much time has been played or how many frames have been processed (e.g., decoded) as part of rendering. A timestamp calculation may be performed (e.g., as part of customization 138) on the encoded bytes rendered for the surround sound stream. In some implementations, an estimate of the number of frames may be provided to an application using or based on the timestamp calculation. For example, the estimate may be based on the number of bytes sent by audio HAL 128.

[0034] In some existing approaches not corresponding to the present subject matter, the component corresponding to the audio HAL 128 may have a way of guessing or otherwise knowing what external device is connected to the hardware board 104. If connected by a High-Definition Multimedia Content Interface (HDMI®) cable, the component may detect a callback event on the HDMI and thus know that an HDMI is connected and that streams can be passed through the HDMI. The operating system (e.g., the ANDROID operating system) may provide such functionality. In the present subject matter, in contrast, HDMI communication may not be available. Rather, an application (e.g., the TIDAL application 112) may simply send a stream and the audio HAL 128 may need to manage the stream so that it can be played back on the device. Furthermore, the audio HAL 128 may not inherently or natively have a runtime mechanism to know whether an HDMI device or other consumer electronic device will receive the data. Thus, in the present subject matter, whenever surround sound data (e.g., an ATMOS stream) is received, a channel may be opened at run time (e.g., using or based on one or more of customizations 132, 134, 136 or 138), in which case a driver for that channel may be opened in audio HAL 128, processing may be performed, and the system may send the stream via that channel to a decoder (e.g., in hardware board 104).

[0035] 2 shows one example of an audio system 200 that supports surround sound. Audio system 200 may be used with one or more other examples described elsewhere herein. Audio system 200 may be implemented using some or all of the examples described below with reference to FIG.

[0036] The audio system 200 includes at least one audio source 202. The audio source 202 may be local to the vehicle (e.g., a local hard drive, memory, or other audio storage device) or remote (e.g., a network connection to one or more remotely located servers that provide audio content in one or more coding formats). Here, the audio content 204 from the audio source 202 may represent either a non-surround sound data stream (e.g., from any of the SPOTIFY application 110, the AMAZON ALEXA application 114, the navigation application 116, or the radio UI application 118 in FIG. 1, or a stereo stream from the TIDAL application 112) or a surround sound data stream (e.g., an ATMOS stream from the TIDAL application 112). Other approaches may be used.

[0037] The audio system 200 may include an audio processor 206 that may receive or obtain audio content 204 from an audio source 202. The audio processor 206 includes an operating system (OS) framework mixer 208. In some implementations, the OS includes an ANDROID OS. For example, the OS framework mixer 208 may be included within an ANDROID AUDIOFLINGER component. A non-surround sound data stream of the audio content 204 may be provided to the OS framework mixer 208 for mixing.

[0038] The audio processor 206 includes a framework mixer bypass 210. A surround sound data stream of the audio content 204 may be provided to the framework mixer bypass 210. For example, this may be done using or based on one or more of the customizations 132, 134, 136, or 138 in FIG.

[0039] At least the audio processor 206 may be implemented within a vehicle 212 as shown diagrammatically. The vehicle 212 includes speakers for playing audio, including but not limited to non-surround sound data streams or surround sound data streams. One or more types of speaker types may be used, including but not limited to tweeter speakers, mid-range speakers, full-range speakers, and / or woofers. Each speaker (type) may include one or more transducers (e.g., voice coils) for converting electrical input into sound waves. The vehicle 212 may include n tweeter speakers 214 that may have any of a number of arrangements within the vehicle 212. The vehicle 212 may include m mid-range speakers 216 that may have any of a number of arrangements within the vehicle 212. The vehicle 212 may include p full-range speakers 218 (sometimes referred to as twiddler speakers) that may have any of a number of arrangements within the vehicle 212. The vehicle 212 may include q woofers 220 (eg, subwoofers) that may have any of a number of arrangements within the vehicle 212. Other approaches may be used.

[0040] 3 is a flow chart of an example method 300 of adapting an automotive audio system to support surround sound. FIG 4 is a flow chart of an example method 400 of playing surround sound on an automotive audio system of a vehicle. More or fewer operations may be performed. Unless otherwise specified, two or more operations may be performed in different orders.

[0041] In operation 302, the application program may be configured for creation of an audio track object that specifies pass-through mode as the playback mode. The application program may be installed to operate under an operating system that is not configured for surround sound. In some implementations, the TIDAL application 112 may be installed to operate under an ANDROID operating system and may create an audio track object for an ATMOS stream. For example, the TIDAL application 112 may be provided with customization 132.

[0042] At operation 304, the operating system framework may be configured with a bypass past the operating system's mixer. The bypass allows surround sound data of the audio track object to bypass the mixer. In some implementations, the framework 120 may be provided with customizations 134. For example, the customizations 134 may enable an output pass-through mode to bypass the mixer 122.

[0043] In operation 306, the hardware abstraction layer may be configured with a separate channel for the surround sound data received from the operating system. The hardware abstraction layer may process the surround sound data before providing the processed surround sound data to a decoder. In some implementations, the audio HAL 128 may be provided with customizations 136 and / or 138.

[0044] Turning now to method 400, operation 402 may involve using an application program for the automobile audio system to create an audio track object that specifies the pass-through mode as the playback mode. The application program may be installed to operate under an operating system that is not configured for surround sound. In some implementations, the TIDAL application 112 may operate under an ANDROID operating system and may use customization 132 to create an audio track object for the ATMOS stream.

[0045] The operation 404 may involve, within the framework of the operating system, the surround sound data of the audio track object bypassing the mixer of the operating system. In some implementations, the customizations 134 within the framework 120 may provide an output pass-through mode that bypasses the mixer 122.

[0046] Operation 406 may involve processing the surround sound data at a hardware abstraction layer of the automotive audio system. In some implementations, audio HAL 128 with customizations 136 and 138 may perform buffer management and / or timestamp calculations.

[0047] Operation 408 may involve providing the processed surround sound data to a decoder to generate a decoded surround sound signal. In some implementations, the audio HAL 128 may provide the processed data to the hardware board 104 using the bus 106.

[0048] Operation 410 may involve providing the decoded surround sound signal to at least one of a plurality of speakers in the vehicle. In some implementations, the hardware board 104 may provide the audio signal to one or more of the speakers of the audio system 200.

[0049] FIG. 5 illustrates an example architecture of a computing device 500 that may be used to implement aspects of the disclosure, including any of the systems, devices, and / or techniques described herein, or any other systems, devices, and / or techniques that may be utilized in various possible embodiments.

[0050] The computing device illustrated in FIG. 5 may be used to execute the operating system, application programs and / or software modules (including software engines) described herein.

[0051] In some embodiments, the computing device 500 includes at least one processing device 502 (e.g., processor), such as a central processing unit (CPU). A variety of processing devices are available from a variety of manufacturers, such as Intel or Advanced Micro Devices. In this example, the computing device 500 also includes a system memory 504 and a system bus 506 that couples various system components including the system memory 504 to the processing device 502. The system bus 506 is one of any number of types of bus structures that may be used, including, but not limited to, a memory bus or memory controller; a peripheral bus; and a local bus, using any of a variety of bus architectures.

[0052] Examples of computing devices that may be implemented using computing device 500 include a desktop computer, a laptop computer, a tablet computer, a mobile computing device (e.g., a smartphone, a touchpad mobile digital device or other mobile device), or other device configured to process digital instructions.

[0053] The system memory 504 includes a read-only memory 508 and a random access memory 510. A basic input / output system 512, containing the basic routines that function to transfer information within the computing device 500, such as during start-up, may be stored in the read-only memory 508.

[0054] In some embodiments, computing device 500 also includes a secondary storage device 514, such as a hard disk drive, for storing digital data. The secondary storage device 514 is connected to the system bus 506 by a secondary storage interface 516. The secondary storage device 514 and its associated computer-readable media provide non-volatile and non-transitory storage of computer-readable instructions (including application programs and program modules), data structures and other data for computing device 500.

[0055] Although the exemplary environment described herein uses a hard disk drive as a secondary storage device, other embodiments use other types of computer-readable storage media. Examples of these other types of computer-readable storage media include magnetic cassettes, flash memory cards, solid-state drives (SSDs), digital video disks, Bernoulli cartridges, compact disk read-only memories, digital versatile disk read-only memories, random access memories, or read-only memories. Some embodiments include non-transitory media. For example, a computer program product may be tangibly embodied in a non-transitory storage medium. Additionally, such computer-readable storage media may include local storage or cloud-based storage.

[0056] A number of program modules may be stored on the secondary storage device 514 and / or in the system memory 504, including an operating system 518, one or more application programs 520, other program modules 522 (e.g., a software engine as described herein) and program data 524. The computing device 500 may utilize any suitable operating system.

[0057] In some embodiments, a user provides input to the computing device 500 through one or more input devices 526. Examples of input devices 526 include a keyboard 528, a mouse 530, a microphone 532 (e.g., for voice and / or other audio input), a touch sensor 534 (e.g., a touchpad or touch-sensitive display), and a gesture sensor 535 (e.g., for gesture input). In some implementations, the input devices 526 provide presence, proximity, and / or motion-based detection. Other embodiments include other input devices 526. The input devices may be connected to the processing device 502 through an input / output interface 536 coupled to the system bus 506. These input devices 526 may be connected by any number of input / output interfaces, such as a parallel port, a serial port, a game port, or a universal serial bus. In some possible embodiments, wireless communication between the input device 526 and the input / output interface 536 is also possible, including infrared, BLUETOOTH® wireless technology, 802.11a / b / g / n, cellular, ultra-wideband (UWB), ZigBee®, or other radio frequency communication systems, to name just a few.

[0058] In this exemplary embodiment, a display device 538, such as a monitor, liquid crystal display device, light emitting diode display device, projector, or touch-sensitive display device, is also connected to the system bus 506 via an interface, such as a video adapter 540. In addition to the display device 538, computing device 500 may also include various other peripheral devices (not shown), such as speakers or a printer.

[0059] Computing device 500 may be connected to one or more networks through network interface 542. Network interface 542 can provide wired and / or wireless communication. In some implementations, network interface 542 may include one or more antennas for transmitting and / or receiving wireless signals. When used in a local area networking environment or a wide area networking environment (e.g., the Internet), network interface 542 may include an Ethernet interface. Other possible embodiments use other communication devices. For example, some embodiments of computing device 500 include a modem for communicating across a network.

[0060] Computing device 500 may include at least some form of computer-readable media. Computer-readable media includes any available media that can be accessed by computing device 500. By way of example, computer-readable media include computer-readable storage media and computer-readable communication media.

[0061] Computer readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any device configured to store information, such as computer readable instructions, data structures, program modules, or other data. Computer readable storage media includes, but is not limited to, random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technology, compact disc read-only memory, digital versatile disk or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing device 500.

[0062] Computer-readable communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, computer-readable communication media includes wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, radio frequency, infrared and other wireless media. Combinations of any of the above are also included within the scope of computer-readable media.

[0063] The computing device illustrated in FIG. 5 is also one example of a programmable electronic device that may include one or more such computing devices, where multiple computing devices are coupled together to a suitable data communications network and capable of collectively performing various functions, methods or operations disclosed herein.

[0064] In some implementations, the computing device 500 may be characterized as an ADAS computer. For example, the computing device 500 may include one or more components that may be used to process tasks arising in the field of artificial intelligence (AI). The computing device 500 then includes sufficient running power and the necessary support architecture for the demands of ADAS or AI in general. For example, the processing device 502 may include a multi-core architecture. As another example, the computing device 500 may include one or more co-processors in addition to or as part of the processing device 502. In some implementations, at least one hardware accelerator may be coupled to the system bus 506. For example, a graphics processing unit may be used. In some implementations, the computing device 500 may implement neural network specific hardware to process one or more ADAS tasks.

[0065] The terms "substantially" and "about" used throughout this specification are used to describe and report small variations, for example due to processing variations. For example, they can refer to less than or equal to ±5%, for example less than or equal to ±2%, for example less than or equal to ±1%, for example less than or equal to ±0.5%, for example less than or equal to ±0.2%, for example less than or equal to ±0.1%, for example less than or equal to ±0.05%. Also, as used herein, indefinite articles, for example "a" or "an" mean "at least one".

[0066] It will be understood that all combinations of the above concepts, and additional concepts discussed in more detail below (provided that such concepts are not mutually inconsistent), are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein.

[0067] Although several implementations have been described, it will be understood that various modifications can be made without departing from the spirit and scope of the specification.

[0068] Additionally, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. Additionally, other operations may be provided or operations may be eliminated from the described flows, and other components may be added to or removed from the described systems. Accordingly, other implementations are within the scope of the following claims.

[0069] While certain features of the described implementations have been shown as described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It should therefore be understood that the appended claims are intended to cover all such modifications and changes that fall within the scope of these implementations. It should be understood that they have been presented merely as examples and not as limitations, and that various changes in form and details may be made. Any part of the apparatus and / or method described herein may be combined in any combination, except for mutually exclusive combinations. The implementations described herein may include various combinations and / or subcombinations of the functions, components, and / or features of the different implementations described.

Claims

1. 1. A method of adapting an automotive audio system to support surround sound, the method comprising: configuring an application program for creation of an audio track object that specifies pass-through mode as a playback mode, where the application program is installed to operate under an operating system that is not configured for surround sound; configuring the operating system framework with a bypass past a mixer of the operating system, the bypass allowing surround sound data of the audio track object to bypass the mixer; and configuring a hardware abstraction layer with a separate channel for the surround sound data received from the operating system, where the hardware abstraction layer processes the surround sound data before providing the processed surround sound data to a decoder. A method comprising:

2. 2. The method of claim 1, wherein configuring the application program comprises adding support for specifying the pass-through mode as the playback mode.

3. 3. The method of claim 1 or 2, wherein the application program has a condition for providing surround sound output that the framework of the operating system supports surround sound playback, and configuring the framework with the bypass causes the framework to satisfy the condition.

4. The method of claim 1 or 2, wherein the separate channels facilitate buffer management.

5. The method of claim 1 or 2, wherein the separate channel facilitates time stamp calculation.

6. 6. The method of claim 5, wherein at least the processing of the surround sound data is performed using a first hardware board and at least the decoding is performed using a second hardware board separate from the first hardware board, and the hardware abstraction layer uses the timestamp calculations to provide frame estimates to the application program.

7. 1. A method for reproducing surround sound on an automotive audio system of a vehicle, the method comprising: creating an audio track object using an application program for the automobile audio system that specifies pass-through mode as a playback mode, where the application program is installed to operate under an operating system that is not configured for surround sound; within the framework of said operating system, surround sound data of said audio track object bypassing a mixer of said operating system; processing the surround sound data at a hardware abstraction layer of the automotive audio system; providing the processed surround sound data to a decoder to generate a decoded surround sound signal; and providing the decoded surround sound signal to at least one of a plurality of speakers of the vehicle. A method comprising:

8. 8. The method of claim 7, wherein the steps of creating an audio track object, bypassing the mixer, and processing the surround sound data are performed using a first hardware board, and the steps of decoding and providing the decoded surround sound signal are performed using a second hardware board separate from the first hardware board.

9. 9. The method of claim 7 or 8, wherein the application program has a condition for providing surround sound output that the framework of the operating system supports surround sound playback, and the step of bypassing the mixer causes the framework to satisfy the condition.

10. The method according to claim 7 or 8, wherein the step of processing the surround sound data comprises buffer management.

11. The method according to claim 7 or 8, wherein the step of processing the surround sound data comprises a time stamp calculation.

12. 12. The method of claim 11, wherein at least the step of processing the surround sound data is performed using a first hardware board and at least the decoding is performed using a second hardware board separate from the first hardware board, the method further comprising the step of providing a frame estimate to the application program using the timestamp calculation.

Images