A vehicle machine audio link system and a vehicle machine platform audio processing method

Abstract

This application discloses a vehicle-mounted audio link system and a platform-based audio processing method for vehicle-mounted systems, relating to the field of vehicle-mounted audio control. The system includes: Step T1, receiving audio data from the instrument cluster module and Android module, and forwarding it to the DSP module; Step T2, the DSP module integrating and processing the audio data from the instrument cluster module, Android module, and MCU module; Step T3, dynamically setting the audio type, mixing strategy, and channel configuration through a configuration file; Step T4, obtaining the audio output format requirements of the vehicle-mounted platform; Step T5, generating a parameter set for calling the configuration file based on the audio output format requirements of the vehicle-mounted platform; and Step T6, achieving platform-based reuse based on the parameter set of the configuration file. Through this solution, a unified configuration file is used to uniformly plan all audio strategies, channels, and priorities, enabling independent configuration of audio strategies, eliminating hardware dependence, requiring no code modification, and facilitating rapid adaptation between high and low configurations.

Description

Technical Field

[0001] This application relates to the field of vehicle audio control, and in particular to vehicle audio link systems, vehicle platform-based audio processing methods, electronic devices, storage media, and vehicle platform-based audio processing systems. Background Technology

[0002] The current state of in-vehicle audio control platforms is characterized by: multiple audio paths and complex routing (Bluetooth, navigation, voice, media, telephone, alarm tones, OTA sound effects, etc.), and unclear mixing strategies. The logic for multiple audio sources competing for content is ambiguous: for example, which source has priority, how to fade in / out, and the recovery logic is not closed-loop. Audio services are deeply coupled with the in-vehicle system, MCU, amplifier, and cockpit domain; a change in one area affects the entire chain.

[0003] Therefore, a design for the vehicle audio link is needed to achieve planning and control by setting different modules, reverse the current situation of deep coupling in the audio link, and break through the predicament that the audio sound system is difficult to modify after a vehicle product design is completed. Summary of the Invention

[0004] The purpose of this invention is to provide a vehicle audio link system, a vehicle platform-based audio processing method, an electronic device, a storage medium, and a vehicle platform-based audio processing system, thereby solving at least one of a number of technical problems.

[0005] Core technical issues:

[0006] To address the problem of deep coupling and inability to independently configure various domains in existing in-vehicle audio systems: In existing technologies, the audio links of the instrument panel, Android, and MCU are interdependent, and any change in one part requires adjustments to the entire link, making expansion and maintenance difficult.

[0007] To address the issue of fixed audio channel priorities and the inability to dynamically adapt to different vehicle models: Traditional solutions involve hard-coding channels and priorities, requiring repeated development for different models, resulting in long development cycles and high costs.

[0008] Solve the problems of multiple audio sources mixing, mutual interference, and inability to achieve physical isolation and safe output: audio from different sources sharing the same path is prone to preemption, noise, and abnormal mutual interference, which affects the reliability of driving safety prompts.

[0009] To address the issue of audio strategies being tightly bound to hardware platforms and unable to be quickly ported and reused: audio logic is deeply tied to chips, platforms, and vehicle models, resulting in high costs for cross-platform reuse.

[0010] This invention provides the following solution:

[0011] According to a first aspect of the present invention, a vehicle audio link system is provided, comprising:

[0012] Instrumentation module, Android module, MCU module, SOC module, and DSP module;

[0013] The instrument module, Android module, and MCU module are each used to output independent types of audio.

[0014] The SOC module is used to receive audio data from the instrument module and Android module, and forward it to the DSP module;

[0015] The DSP module is used to integrate and process audio data from the instrument module, Android module, and MCU module.

[0016] The audio type, mixing strategy, and channel configuration of the vehicle's audio link system are all dynamically set through configuration files to achieve platform reuse.

[0017] The audio data is transmitted through independent channels, with different modules corresponding to different independent channels.

[0018] It also includes that each independent channel is configured independently and does not interfere with each other.

[0019] Furthermore, the instrument module is used to output alarm audio and perform priority judgment and concurrency control on alarm audio.

[0020] Furthermore, the Android module is used for mixing, adjusting volume, and fading in / out of media audio, navigation audio, voice audio, and system prompt audio.

[0021] The Android module is also used to perform echo cancellation and noise reduction processing on the audio data captured by the microphone.

[0022] Furthermore, the MCU module is used to output backup alarm audio and to perform fallback alarm sounding when the main audio link fails.

[0023] The MCU module is also used to perform audio link initialization, including the initialization configuration of the A2B bus, power amplifier, and ADC.

[0024] Furthermore, the SOC module is used to forward user configuration parameters from the Android module to the MCU module and DSP module.

[0025] Furthermore, the DSP module is used to execute differentiated audio processing flows based on the configuration of the built-in or external power amplifier.

[0026] Furthermore, mixing strategies, volume strategies, concurrency strategies, and alarm strategies can all be configured independently, without relying on the hardware platform.

[0027] Furthermore, the vehicle audio link system is compatible with both built-in and external amplifier hardware architectures and can automatically switch between them through configuration files.

[0028] Furthermore, the vehicle audio link system is a platform-based audio system that can be reused across different vehicle models, requiring only modifications to the configuration file for adaptation.

[0029] According to a second aspect of the present invention, a vehicle-mounted audio processing method is provided, comprising:

[0030] It receives audio data from the instrument module and Android module, and forwards it to the DSP module;

[0031] The DSP module integrates and processes audio data from the instrument module, Android module, and MCU module.

[0032] Among them, the audio type, mixing strategy, and channel configuration can be dynamically set through configuration files;

[0033] Obtain the audio output format requirements of the vehicle infotainment platform;

[0034] Based on the audio output format requirements of the vehicle infotainment platform, generate a set of parameters for calling the configuration file;

[0035] Platform-wide reuse is achieved by calling the parameter set of the configuration file.

[0036] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0037] The memory stores computer programs, which, when executed by the processor, cause the processor to perform steps such as the vehicle-mounted audio processing method.

[0038] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs steps such as a vehicle-mounted platform-based audio processing method.

[0039] According to a fifth aspect of the present invention, a vehicle-mounted platform-based audio processing system is provided, comprising:

[0040] Electronic devices, used to implement steps such as in-vehicle infotainment platform-based audio processing methods;

[0041] The processor runs programs, and when the programs are running, they execute steps such as the audio processing method of the vehicle system platform based on the data output from the electronic device.

[0042] Storage medium used to store programs that, when running, perform steps such as vehicle-mounted audio processing methods on data output from electronic devices.

[0043] The above solution achieves the following beneficial technical effects:

[0044] This application achieves independent audio management and prevents interference between the instrument domain, Android domain, and MCU domain by isolating them, thereby reducing coupling and improving stability.

[0045] This application uses a unified configuration file to plan all audio strategies, channels, and priorities, enabling audio strategies to be configured independently, without hardware dependence or code modification, and allowing for rapid adaptation to high and low configurations.

[0046] This application enables backup audio output in case of abnormal situations through the MCU domain, ensuring that critical prompts (such as warning sounds and alert sounds) are not lost and are highly reliable, meeting automotive safety requirements.

[0047] This application enables a single design to be reused across multiple vehicle models by using independent audio channels, fixed priorities, and configurable strategies, thereby significantly shortening the development cycle and reducing project costs.

[0048] This application achieves stable basic audio output through a fixed channel division and fixed priority strategy.

[0049] This application ensures that alarm, notification, and media audio messages are executed according to preset rules, and that basic functions are available and reproducible. Attached Figure Description

[0050] Figure 1 This is a structural diagram of a vehicle audio link system provided by one or more embodiments of the present invention.

[0051] Figure 2 This is a flowchart of a vehicle-mounted audio processing method provided by one or more embodiments of the present invention.

[0052] Figure 3 This is a schematic diagram of a vehicle audio architecture provided in a specific embodiment of the present invention.

[0053] Figure 4 This is a block diagram of an electronic device structure for a vehicle-mounted audio processing method provided in one or more embodiments of the present invention. Detailed Implementation

[0054] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] Figure 1This is a structural diagram of a vehicle audio link system provided by one or more embodiments of the present invention.

[0056] like Figure 1 The in-vehicle audio link system shown includes:

[0057] Instrumentation module, Android module, MCU module, SOC module, and DSP module;

[0058] The instrument module, Android module, and MCU module are each used to output independent types of audio.

[0059] The SOC module is used to receive audio data from the instrument module and Android module, and forward it to the DSP module;

[0060] The DSP module is used to integrate and process audio data from the instrument module, Android module, and MCU module.

[0061] The audio type, mixing strategy, and channel configuration of the vehicle's audio link system are all dynamically set through configuration files to achieve platform reuse.

[0062] The audio data is transmitted through independent channels, with different modules corresponding to different independent channels.

[0063] It also includes that each independent channel is configured independently and does not interfere with each other.

[0064] In this embodiment, an instrument module is included, which is used to output alarm audio and perform priority judgment and concurrency control on alarm audio.

[0065] In this embodiment, an Android module is included, which is used to mix media audio, navigation audio, voice audio, and system prompt audio, adjust volume, and perform fade-in / fade-out processing.

[0066] The Android module is also used to perform echo cancellation and noise reduction processing on the audio data captured by the microphone.

[0067] In this embodiment, it includes: an MCU module, used to output backup alarm audio and perform fallback sounding when the main audio link is abnormal;

[0068] The MCU module is also used to perform audio link initialization, including the initialization configuration of the A2B bus, power amplifier, and ADC.

[0069] In this embodiment, a SOC module is included, which forwards user configuration parameters from the Android module to the MCU module and the DSP module.

[0070] In this embodiment, a DSP module is included, which is used to execute differentiated audio processing flows according to the configuration of the built-in power amplifier or the external power amplifier.

[0071] In this embodiment, the mixing strategy, volume strategy, concurrency strategy, and alarm strategy can all be configured independently without relying on the hardware platform.

[0072] In this embodiment, the vehicle audio link system is compatible with both built-in and external power amplifier hardware architectures and can automatically switch between them through a configuration file.

[0073] In this embodiment, the in-vehicle audio link system is a platform-based audio system that can be reused across different vehicle models, and adaptation can be achieved simply by modifying the configuration file.

[0074] Specifically, this application mainly involves an instrument panel, an Android device, an MCU, a SOC, and a DSP. The instrument panel, Android device, and MCU are independent audio control modules. The instrument panel, Android device, and MCU process different types of audio data respectively. The Android device and MCU only transmit volume and sound effect settings information, and do not directly transmit audio data. The SOC is used to forward audio data from the Android device and instrument panel to the DSP. The DSP is used to integrate audio data from the Android device, instrument panel, MCU, and T-BOX and output it to the corresponding power amplifier according to the power amplifier configuration. The audio type, mixing strategy, and channel configuration can all be dynamically configured and modified.

[0075] The instrument terminal is used to output instrument alarm sounds, determine the priority and concurrency strategy of instrument alarm sounds, and send the processed audio data to the SOC terminal.

[0076] The Android side includes an audio processing unit, which is used to: process the data collected by the microphone and insert the voice broadcast data into the Android-side audio channel slot; perform ECNR echo cancellation and noise reduction processing on the audio data input from the Bluetooth module and insert it into the Android-side audio channel slot; perform mixing, volume reduction, and fade-in / fade-out processing on navigation broadcasts, media audio, intelligent driving alarm sounds, and system sounds and insert them into the corresponding Android-side audio channel slots; and send the user-set volume and sound effect parameters to the MCU side.

[0077] Media audio includes USB music, Bluetooth music, online media audio, and mobile phone interconnection audio; only one media audio stream is allowed at a time.

[0078] The MCU is used to: initialize the A2B automotive audio bus, DSP / amplifier, and external ADC; send instrument alarm sound backup data and intelligent driving alarm sound backup data to the DSP; and, depending on the vehicle configuration, send volume and sound effect control commands to the external amplifier via CAN signal, or to the built-in amplifier via internal interface.

[0079] The MCU provides backup sound output for instrument alarm sounds and intelligent driving alarm sounds, and outputs backup alarm audio when the main audio link is abnormal.

[0080] The SOC is used to: transmit microphone data to the upper-level voice module; and forward audio data from the Bluetooth module, Android device, and instrument panel to the DSP.

[0081] When configured with a built-in amplifier, the DSP performs sound effect processing on the integrated audio data; when configured with an external amplifier, the DSP sends the integrated audio data directly to the external amplifier, which then performs sound effect processing.

[0082] The system supports compatible switching between high-end models with external amplifiers and low-end models with built-in amplifiers, allowing users to select the audio output path through configuration.

[0083] All audio channels are divided into slots, with different slots corresponding to audio from different sources. Each channel is configured and transmitted independently.

[0084] On Android, AudioHal and AudioControl are used to manage audio channels, control mixing strategies, and manage volume and sound effects.

[0085] The alarm sounds from the instrument panel, the navigation / voice / media / intelligent driving / system sounds from the Android device, and the backup alarm sounds from the MCU are all mixed and integrated into different bus channels of the DSP.

[0086] The system supports adding new audio sources. Simply configure the new audio source to the corresponding audio module and channel; no changes to the entire link architecture are required.

[0087] Mixing strategies, fade-in / fade-out strategies, volume attenuation strategies, and concurrency control strategies are all implemented in a configurable manner, independent of hardware platform and chip model.

[0088] The system is a platform-based audio link system that can be reused on different vehicle models and hardware architectures, and can be quickly adapted to mass production by modifying the configuration.

[0089] This embodiment also includes a layered decoupled architecture for the audio link, with independent audio interfaces configured for the instrument cluster, entertainment system, and vehicle body, and the domains do not share hardware resources or depend on each other.

[0090] The instrumentation domain is only responsible for alarm and notification audio outputs and does not participate in media audio mixing, ensuring that alarm audio is output first and is not preempted.

[0091] The entertainment domain is responsible for media and navigation audio output, and automatically avoids alarm audio based on preset priorities, automatically reducing the volume rather than cutting it off during the avoidance process.

[0092] The vehicle body domain is responsible for providing backup alarm audio output. It can still independently output alarm prompts when the entertainment domain malfunctions, freezes, or fails to start up completely.

[0093] Audio priority adopts a fixed hierarchical strategy, with alarm audio having the highest priority, navigation audio the next highest, and media audio the lowest priority. The priority cannot be changed dynamically.

[0094] The audio mixing uses a fixed attenuation strategy. When a high-priority audio signal is introduced, the low-priority audio signal is attenuated by a preset ratio. The attenuation ratio can be configured but cannot be canceled.

[0095] The audio link supports hardware-independent configuration, distinguishing between built-in and external amplifiers through configuration files. Changing the amplifier type does not modify the audio link architecture.

[0096] The audio link supports vehicle-independent configurations, which distinguish different vehicle models and different cabin hardware through configuration files. When the vehicle model changes, only the configuration file needs to be updated.

[0097] When the entertainment domain malfunctions, the audio link automatically enters degrade mode. In degrade mode, only the instrument cluster and body domain audio outputs are retained, and media audio is not output.

[0098] When the entertainment domain has not been fully started, the audio link allows the alarm tone to be output in advance without waiting for the entertainment domain to be initialized, ensuring that the alarm is triggered immediately upon power-on.

[0099] The audio link supports independent configuration of mixing parameters, including attenuation ratio, cut-in delay, cut-out delay, and volume compensation, all of which can be set independently through configuration files.

[0100] The audio link supports automatic fault identification. When any link experiences silence, noise, audio dropout, or mixing abnormalities, it will automatically switch to degrade mode.

[0101] The audio link supports version management. The audio link architecture, priority strategy, and mixing strategy all support independent version upgrades and are not dependent on hardware versions.

[0102] The audio link supports independent maintenance. An audio anomaly in any domain will not affect other domains. Fault location only requires checking the configuration of the corresponding domain and will not affect the overall link.

[0103] The audio link adopts a deterministic output architecture. Under the same input, configuration, and vehicle model, the output results are completely consistent, with no random anomalies or random noise.

[0104] In another embodiment, the audio link further includes a scene adaptation module for automatically adjusting the output gain of each audio channel based on the ambient noise, vehicle speed, and number of occupants.

[0105] The audio link also includes a user preference learning module, which records and reuses users' historical volume, sound effects, and mute habits to form personalized audio strategies.

[0106] The audio link supports intelligent mixing of multiple audio sources, assigning independent weights to alarm tones, navigation tones, media tones, and prompt tones, and supporting real-time dynamic mixing.

[0107] The audio link also includes an anomaly detection module, which monitors in real time whether there are audio interruptions, noise, delays, or preemption in each audio channel, and automatically triggers repair strategies.

[0108] The audio link supports independent audio output in multiple areas of the cabin, with independent volume, independent audio source, and independent sound effects for the driver, passenger, and rear seats respectively.

[0109] The audio link also includes an audio event log module, which records the timing of audio triggering, channel status, and abnormal information, supporting post-event traceability and problem localization.

[0110] The audio link supports OTA online updates, which can distribute new audio strategies, priority rules, and mixing parameters through the cloud without the need for hardware upgrades.

[0111] The audio link also includes a vehicle control linkage module, which is used to automatically switch the corresponding audio prompt mode according to the vehicle status such as door position, seat belt position, gear position, and lights.

[0112] The audio link supports a low-power mode, retaining the minimum power output capability for critical alarm audio even when the vehicle is in sleep, standby, or powered-off states.

[0113] The audio link supports multi-vehicle compatible configurations, automatically adapting to different cabin hardware, amplifier models, and speaker layouts through configuration files.

[0114] The audio link also includes a voice linkage module, which is used to adjust the audio channel, volume, sound effects, and mute strategy in real time according to voice commands.

[0115] The audio link supports automatic fault isolation. When one audio channel is abnormal, it will not affect the normal output of other channels, thus ensuring the overall stability of the system.

[0116] This embodiment specifically emphasizes resolving issues such as the inability of audio to adapt to different scenarios, lack of personalization, and inability to control multiple regions independently. It also addresses scalability issues such as the inability to perform over-the-air (OTA) updates, incompatibility with multiple vehicle models, and the inability to learn user habits.

[0117] This embodiment achieves scene adaptation, user habit adaptation, and independent output in multiple regions, significantly improving the user experience. It enables configurability, OTA updates, and compatibility with multiple hardware platforms, greatly enhancing scalability and reusability. It forms a complete audio system capability, from fixed strategies to intelligent strategies, and finally, full platform scalability.

[0118] In another embodiment, the audio outputs of the instrument module, Android module, and MCU module are independent of each other and do not depend on each other.

[0119] When the Android module malfunctions or restarts, it does not affect the audio output of the instrument module and MCU module.

[0120] The MCU module is an independently powered and independently started backup audio module, unaffected by the power-on or power-off status of the Android module.

[0121] The audio channels include media channels, navigation channels, voice channels, and alarm channels. Each channel has a fixed priority and cannot be preempted by other channels.

[0122] The alarm channel has the highest priority, and the media channel has the lowest priority.

[0123] The Android module is used to send volume configuration, sound effect configuration, and channel enable configuration to the MCU module.

[0124] The SOC module is only used for audio data forwarding and routing, and does not participate in audio mixing or priority determination.

[0125] The DSP module supports automatic recognition and switching between built-in power amplifier mode and external power amplifier mode.

[0126] The system supports dynamically loading configuration files to adapt to different vehicle models and different amplifier hardware.

[0127] Before the Android module has finished starting up, the system allows the instrument module and MCU module to output audio first.

[0128] Mixing processes include fade-in / fade-out, volume attenuation, channel balancing, and delay compensation.

[0129] When the MCU module detects an audio anomaly, it automatically switches to pure alarm output mode.

[0130] All audio data is transmitted via digital channels without being converted by analog circuitry.

[0131] The system supports multi-source mixing, but only one highest priority source is allowed to output completely at a time.

[0132] The configuration file supports online upgrades and updates without altering the hardware structure.

[0133] This embodiment emphasizes anomaly handling, channel protection, degradation mechanisms, fault isolation, and the controllability of channel preemption, silence, noise, and delay.

[0134] This embodiment achieves automatic isolation of channel anomalies, ensuring that a failure in one channel does not affect the entire system. It enables monitoring and traceability of audio status, improving system robustness. It guarantees that critical audio is not lost or interrupted under any circumstances.

[0135] Figure 2 This is a flowchart of a vehicle-mounted audio processing method provided by one or more embodiments of the present invention.

[0136] like Figure 2 The in-vehicle infotainment platform-based audio processing method shown includes:

[0137] Step T1: Receive audio data from the instrument module and Android module, and forward it to the DSP module;

[0138] In step T2, the DSP module integrates and processes the audio data from the instrument module, Android module, and MCU module.

[0139] Step T3: Dynamically set the audio type, mixing strategy, and channel configuration through the configuration file;

[0140] Step T4: Obtain the audio output format requirements of the vehicle infotainment platform;

[0141] Step T5: Generate the parameter set for calling the configuration file according to the audio output format requirements of the vehicle infotainment platform;

[0142] Step T6: Based on the parameter set of the calling configuration file, platform-based reuse is achieved.

[0143] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0144] In one specific embodiment, an audio link design is disclosed. Given that the current audio link is deeply coupled and difficult to modify after the design is completed, a compatible design is implemented, and different modules are used for control.

[0145] The entire audio output is divided into three parts:

[0146] 1. Instrument Terminal: Issue alarm sounds from various instruments.

[0147] 2. Android: Voice commands, navigation, media, intelligent driving, system sounds

[0148] 3. MCU side: Relaying the instrument panel alarm sound and the intelligent driving backup sound.

[0149] Audio type, mixing strategy, and other settings can all be dynamically configured and modified.

[0150] In this embodiment, the audio link is controlled in several parts simultaneously:

[0151] In this embodiment, the instrument terminal determines the priority and concurrency strategy of the instrument alarm tone and sends the audio data to the SOC.

[0152] In this embodiment, on the Android side: 1. Process the data received from several microphones, and then insert the voice broadcast data into the Android-side audio channel slot after processing. 2. Process the audio data sent from the Bluetooth module through the microphones using ECNR, and then insert the data into the Android-side audio channel slot. Mix, reduce the volume, and fade in / out the data of navigation broadcasts, media (including USB, Bluetooth music, online media sounds, etc., only one of which can be emitted at a time), intelligent driving alarm sounds, system sounds (key tones, keyboard dial tones), etc., and then insert them into the corresponding audio channel slot on the Android side. 4. Send the user-set volume, sound effects, and other settings to the MCU.

[0153] In this embodiment, on the MCU side: 1. Initialize A2B, DSP / AMP, and external ADC. 2. Send the backed-up instrument alarm tone and intelligent driving alarm tone to the DSP. 3. For vehicles with external power amplifiers, send volume and sound effect control commands to the external power amplifier via CAN signal; for vehicles with built-in power amplifiers, send control commands to the built-in power amplifier via internal interface.

[0154] In this embodiment, on the SOC side: 1. It transmits microphone data to the upper-layer voice module. 2. It transmits audio data from the Bluetooth module, Android device, and instrument panel to the DSP.

[0155] In this embodiment, the DSP: 1. Integrates audio data from the Android device, instrument panel, MCU, and t-box. 2. If configured with a built-in amplifier, performs sound effect processing; if configured with an external amplifier, sends the data to the external amplifier.

[0156] In another specific embodiment, when project timelines are tight, using this platform-based host can enable the entire audio system to be put into mass production as quickly as possible.

[0157] Case 1: After the project went into mass production, the NetEase Cloud Music function was added due to subsequent optimizations: simply add the NetEase Cloud Music source to the fixed media module as media audio, and no further adjustments are needed to the entire process.

[0158] Case 2: After the vehicle was launched, users felt that the media music volume was too loud during navigation broadcasts. This issue could be resolved simply by adjusting the mixing strategy volume in AudioHal.

[0159] This embodiment is compatible with most in-vehicle infotainment systems on the market, whether it is an external power amplifier or a built-in attack and defense system. It can quickly formulate the system and channel configuration of the audio link and provide users with a similar experience.

[0160] This standard can be used to quickly develop the vehicle audio link.

[0161] Figure 4 This is a block diagram of an electronic device structure for a vehicle-mounted audio processing method provided in one or more embodiments of the present invention.

[0162] like Figure 4 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0163] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of a vehicle-mounted audio processing method.

[0164] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle-mounted platform-based audio processing method.

[0165] This application also provides a vehicle infotainment platform-based audio processing system, including:

[0166] Electronic devices, steps for implementing a platform-based audio processing method for in-vehicle systems;

[0167] The processor runs a program, and when the program runs, it executes the steps of the vehicle-mounted audio processing method based on data output from electronic devices.

[0168] Storage medium for storing programs that, when running, execute the steps of the vehicle-mounted audio processing method on data output from electronic devices.

[0169] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0170] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0171] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0172] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0173] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0174] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0175] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0176] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0177] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0178] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A car kit audio link system, characterized by, The vehicle audio link system includes: Instrumentation module, Android module, MCU module, SOC module, and DSP module; The instrument module, Android module, and MCU module are each used to output independent types of audio. The SOC module is used to receive audio data from the instrument module and the Android module, and forward it to the DSP module; The DSP module is used to integrate and process audio data from the instrument module, Android module, and MCU module. The audio type, mixing strategy, and channel configuration of the vehicle audio link system are all dynamically set through configuration files to achieve platform reuse. The audio data is transmitted through independent channels, with different modules corresponding to different independent channels; It also includes that each independent channel is configured independently and does not interfere with each other.

2. The vehicle audio link system according to claim 1, characterized in that, include: The instrument module is used to output alarm audio and perform priority judgment and concurrent control on alarm audio.

3. The vehicle audio link system according to claim 1, characterized in that, include: The Android module is used to mix, adjust volume, and fade in / out of media audio, navigation audio, voice audio, and system prompt audio. The Android module is also used to perform echo cancellation and noise reduction processing on the audio data collected by the microphone.

4. The vehicle audio link system according to claim 1, characterized in that, include: The MCU module is used to output backup alarm audio and to perform fallback alarm sounding when the main audio link is abnormal; The MCU module is also used to perform audio link initialization, including the initialization configuration of the A2B bus, power amplifier, and ADC.

5. The vehicle audio link system according to claim 1, characterized in that, include: The SOC module is used to forward user configuration parameters from the Android module to the MCU module and the DSP module.

6. The vehicle audio link system according to claim 1, characterized in that, include: The DSP module is used to execute differentiated audio processing flows based on the configuration of the built-in or external power amplifier.

7. A vehicle-mounted audio processing method, characterized in that, The platform-based audio processing methods for in-vehicle infotainment systems include: It receives audio data from the instrument module and the Android module, and forwards it to the DSP module; The DSP module integrates and processes audio data from the instrument module, Android module, and MCU module. Among them, the audio type, mixing strategy, and channel configuration can be dynamically set through configuration files; Obtain the audio output format requirements of the vehicle infotainment platform; Based on the audio output format requirements of the vehicle infotainment platform, generate a set of parameters for calling the configuration file; Platform-wide reuse is achieved by calling the parameter set of the configuration file.

8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the vehicle-mounted audio processing method as described in claim 7.

9. A computer-readable storage medium, characterized in that, include: The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle-mounted platform audio processing method as described in claim 7.

10. A vehicle-mounted audio processing system, characterized in that, include: An electronic device for implementing the steps of the vehicle-mounted platform-based audio processing method as described in claim 7; The processor runs a program, and when the program runs, it executes the steps of the vehicle-mounted platform audio processing method as described in claim 7 from data output by the electronic device. A storage medium for storing a program that, when running, performs the steps of the vehicle-mounted audio processing method as described in claim 7 on data output from an electronic device.

Images