Vehicle audio hibernation control method, system, device and storage medium
Through the coordinated control of the Audio-Hal and Audio-Framework framework layers, the in-vehicle audio system achieves seamless sleep and wake-up, solving the problems of long startup time and high current consumption, and improving system security and user experience.
Patent Information
- Application Number
- CN202411403025.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-09
- Publication Date
- 2025-12-12
- Estimated Expiration
- 2044-10-09
AI Technical Summary
In existing technologies, in-vehicle audio systems suffer from long startup times and high current consumption during sleep and wake-up processes. This is especially problematic when apps in app stores are not adapted to sleep signals, leading to sleep issues and security risks.
By listening for sleep messages in the Audio-Hal layer of the in-vehicle audio system and feeding them back to the Audio-Framework layer, and controlling the audio thread and the App's audio thread through AudioFlinger, sleep control can be achieved without App adaptation, and the sleep and wake-up processes can be managed in a unified manner.
It effectively avoids hibernation issues, improves the safety and startup speed of the in-vehicle audio system, and reduces the complexity of App adaptation and the risk of power consumption.
Smart Images
Figure CN119292682B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of vehicle audio, and particularly relates to a hibernation control method, system and device of vehicle audio and a storage medium. BACKGROUND
[0002] On a vehicle audio system, cold start is slow (about 20 seconds), but under a hibernation wake-up mechanism, the start time can be completed in one or two seconds, as long as the current during hibernation is low enough, the battery can support such hibernation after locking the vehicle, and then quickly wake up when unlocking.
[0003] In the related art, an audio application (App) itself generally listens to a hibernation signal and performs a corresponding action. For example, the hibernation signal can be a signal when entering hibernation, and then the audio device is turned off during hibernation; or the hibernation signal can be a signal for exiting hibernation, and then the state before hibernation is restored when exiting hibernation. However, such a mechanism has a large disadvantage, all Apps need to adapt to this signal, and some application store Apps do not have corresponding adaptation processing, which will have some hibernation problems. SUMMARY
[0004] The embodiments of the present application provide a hibernation control method, system, device and storage medium of vehicle audio, which can effectively control hibernation without App adaptation processing, can effectively avoid hibernation problems, and improve safety.
[0005] In a first aspect, the embodiments of the present application provide a hibernation control method of vehicle audio, comprising:
[0006] If the car service listens to a hibernation message of the vehicle, the audio device is controlled to hibernate through an audio hardware abstraction layer (Audio-Hal); wherein the hibernation message includes a message for starting hibernation or a message for exiting hibernation;
[0007] The Audio-Hal feeds back the hibernation information to an Audio-Framework framework layer;
[0008] A preset function inside the Audio-Framework framework layer controls an audio thread of an audio manager (AudioFlinger) inside the Audio-Framework framework layer and the Audio-Hal based on the hibernation information;
[0009] The AudioFlinger controls an audio thread of an application (App) based on the hibernation message; wherein the audio thread includes a recording thread and / or a playing thread.
[0010] In a second aspect, the embodiments of the present application provide a sleep control system for vehicle audio, comprising:
[0011] an audio device sleep control module, configured to control sleep of the audio device through an audio hardware abstraction layer (Audio-Hal) if the car service listens to a sleep message of the vehicle; wherein the sleep message comprises a message for starting sleep or a message for exiting sleep;
[0012] a feedback module, configured to feed back the sleep message to an Audio-Framework framework layer through the Audio-Hal;
[0013] a first control module, configured to control an audio thread for interaction between an audio manager (AudioFlinger) in the Audio-Framework framework layer and the Audio-Hal based on the sleep message through a preset function in the Audio-Framework framework layer;
[0014] a second control module, configured to control an audio thread of an application (App) based on the sleep message through the AudioFlinger; wherein the audio thread comprises a recording thread and / or a playing thread.
[0015] In a third aspect, the embodiments of the present application provide an electronic device, comprising:
[0016] a memory, configured to store a computer program;
[0017] a processor, configured to execute the computer program stored in the memory, and when the computer program is executed, a method provided in the embodiments of the present application is implemented.
[0018] In a fourth aspect, the embodiments of the present application provide a computer readable storage medium, which stores a computer program, and when the computer program is executed by a processor, a method provided in the embodiments of the present application is implemented.
[0019] The technical scheme provided in the present application controls sleep of the audio device through the Audio-Hal, controls the audio thread for interaction between the AudioFlinger in the Audio-Framework framework layer and the Audio-Hal through the preset function in the Audio-Framework framework layer, and controls the audio thread of the App through the AudioFlinger based on the sleep message.
[0020] The audio manager AudioFlinger in the Audio-Framework framework layer interacts with the audio thread of Audio-Hal, and the audio thread of Audio-Hal is controlled by AudioFlinger, that is, the audio of the vehicle is controlled from three aspects by the system, one is to control the underlying audio device, one is to control the audio thread in the App, and one is to control the audio thread of AudioFlinger interacting with Audio-Hal, through the system to control the sleep of the vehicle audio, without the App adaptation processing, the sleep can be effectively controlled without the App awareness, effectively avoiding the sleep problem, and the safety is improved in the case of the App adaptation insecurity of the application store. BRIEF DESCRIPTION OF DRAWINGS
[0021] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the application.
[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, those skilled in the art can obtain other drawings from these drawings without creative labor.
[0023] One or more embodiments are exemplarily illustrated by pictures in the drawings corresponding to the embodiments, and these exemplary illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, unless otherwise specified. The drawings in the drawings do not constitute a proportional limitation.
[0024] Figure 1 It is an architecture diagram of a vehicle audio control system;
[0025] Figure 2 It is a sleep control method flowchart of a vehicle audio provided by the embodiments of the present application;
[0026] Figure 3 It is an architecture diagram of Audio-Framework framework layer;
[0027] Figure 4 It is a sleep control method flowchart of a vehicle audio provided by the embodiments of the present application;
[0028] Figure 5 It is a sleep control system structure block diagram of a vehicle audio provided by the embodiments of the present application;
[0029] Figure 6 It is a structure schematic diagram of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION
[0030] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.
[0031] The following disclosure provides many different embodiments, or examples, for implementing different structures of the present application. For the purpose of simplifying the present application, the components and arrangements of the specific examples are described. Of course, they are only examples and are not intended to limit the present application. In addition, the present application can repeatedly refer to reference numerals and / or letters in different examples. Such repetition is for the purpose of simplification and clarity, and does not indicate the relationship between the various embodiments and / or arrangements discussed.
[0032] The general idea of the technical solutions provided by the present application is as follows: the two states of entering hibernation and exiting hibernation are uniformly processed by the audio system, specifically, the two states of entering hibernation and exiting hibernation are processed by each layer in the audio system, without App listening to signals, hibernation is controlled without App awareness, effectively avoiding hibernation problems and solving the problem of App incompatibility. The technical solutions provided by the present application are as follows:
[0033] The technical solutions provided by the present application are based on a hibernation control system of vehicle-mounted audio, which can also be called a hibernation wake-up system of vehicle-mounted audio. The system can be based on an Android system, and the architecture diagram of the system can refer to Figure 1 . For example Figure 1As shown, App is in the uppermost layer, and voice or multimedia interaction is in this layer, and an AudioRecord (recording) object and an AudioTrack (playing) object are created; the Audio-Framework framework layer includes corresponding objects, through which the AudioRecord object and the AudioTrack object of the App are managed, and for each different audio device type (one bus for each type of multimedia, navigation), each bus creates a playing thread or a recording thread to the Audio-Hal (Audio-Hardware Abstraction Layer); the bus can be understood as an address, through which the specific audio device in the Audio-Hal can be determined, and the Audio-Kernel (Audio-Kernel) is used to mount the corresponding audio device according to the device tree during boot initialization; the Audio-Hal writes data to the playing device, and then the Audio-Kernel writes the data to the Digital Signal Processor (DSP), and the audio device is controlled by the DSP to perform real playing, and recording is opposite to playing, that is, recording is realized by reading data from the recording device.
[0034] Figure 2 It is a kind of vehicle audio sleep control method flow chart provided by the embodiment of the application, the method can be executed by the sleep control system of vehicle audio, the system can be realized by software and / or hardware, and the system can be configured in electronic devices such as vehicle-mounted devices.
[0035] As Figure 2 shown, the technical scheme provided by the embodiment of the application comprises:
[0036] S110: if the car service listens to the sleep message of the vehicle, the audio hardware abstraction layer Audio-Hal is used to control the sleep of the audio device; wherein the sleep message comprises a message for starting sleep or a message for exiting sleep.
[0037] In this embodiment, referring to Figure 1 and Figure 2 , the car service can belong to the hardware abstraction layer (Hal layer) of the whole Android. If the car service listens to the sleep message of the vehicle, the Audio-Hal in the same Hal layer is notified, and the sleep control from top to bottom is completed through the Audio-Hal, wherein in this step, the sleep control of the lower layer audio device is performed through the Audio-Hal. Wherein, the sleep message can be the power state information of the whole vehicle.
[0038] S120: feedback the sleep message to the Audio-Framework framework layer through the Audio-Hal.
[0039] In the embodiment, the Audio-Framework framework layer can receive the sleep message through the sleep state interface, so as to receive the change of the sleep state. Specifically, the Audio-Hal notifies the Audio-Framework framework layer to start entering the sleep or exiting the sleep by feeding back the sleep message.
[0040] In one implementation of the embodiment, optionally, the sleep state interface can be added in the hw_module_t handle interacting with the Audio-Framework framework layer. The Audio-Framework framework layer can receive the sleep message through the sleep state interface. When the Audio-Hal receives the sleep message sent by the car service, the sleep message can be synchronously forwarded to the Audio-Framework framework layer. This is also a way of adding the sleep wake-up mechanism in the Audio-Hal.
[0041] In the embodiment, the sleep message needs to be fed back to the Audio-Framework framework layer because
[0042] The Audio-Framework framework layer, only ensuring the passage in the Audio-Hal is often not enough. The App cannot perceive the opening or closing of the passage. It is good for recording. If it is playing, the progress of the App playing data needs to be saved, so that the audio can continue to play at the same progress after the vehicle is unlocked next time. Therefore, the sleep message needs to be fed back to the Audio-Framework framework layer, which is processed by the Audio-Framework framework layer to make the App passive pause. Thus, by feeding back the sleep message to the Audio-Framework framework layer, the Audio-Hal feeds back the sleep message to the Audio-Framework framework layer, which can facilitate the Audio-Framework framework layer to control the App and complete the upper-layer sleep control of the Audio-Hal.
[0043] S130: Control the audio thread of the AudioFlinger interacting with the Audio-Hal in the Audio-Framework framework layer based on the sleep message through a preset function in the Audio-Framework framework layer.
[0044] In the embodiment, the architecture of the Audio-Framework framework layer can refer to Figure 3 For example, Figure 3As shown, the interaction of AudioFlinger and Audio-Hal can be through an audio thread, wherein the audio thread can include a playback thread (PlaybackThread) and a recording thread (RecordThread).
[0045] In the embodiment, the preset function can include a notify all playback thread function (notifyPlaybackStrStateChange) and a notify all recording thread function (notifyRecordStrStateChange). If the sleep control message includes a start sleep message, the audio thread of AudioFlinger and Audio-Hal can be blocked through the preset function, and if the sleep control message includes an exit sleep message, the audio thread of AudioFlinger and Audio-Hal can be recovered through the preset function.
[0046] S140: Controlling the audio thread of the application App based on the sleep message through the AudioFlinger; wherein the audio thread includes a recording thread and / or a playback thread.
[0047] In the embodiment, if the sleep message is a start sleep message, the audio thread of the App is blocked through the AudioFlinger, and if the sleep message is an exit sleep message, the audio thread of the App is recovered through the AudioFlinger.
[0048] The technical scheme provided in the application controls the sleep of the audio device through Audio-Hal, controls the sleep of the audio device through the preset function in the Audio-Framework framework layer, and controls the sleep of the audio device through the AudioFlinger.
[0049] The audio manager AudioFlinger in the Audio-Framework framework layer interacts with the audio thread of Audio-Hal, controls the audio thread of the application App through the AudioFlinger, controls the sleep of the in-vehicle audio through the system, does not need to be adapted by the App, can effectively control the sleep without the awareness of the App, effectively avoids the sleep problem, improves the security in the case of the insecurity of the application store App adaptation, and improves the security.
[0050] For step S110:
[0051] In an optional implementation, the sleep message includes a message for starting sleep, and the sleep control of the audio device by the Audio-Hal includes: calling a start sleep interface by the Audio-Hal, obtaining parameters stored in a created cache map through the start sleep interface; if there are target parameters corresponding to opened paths in the cache map, closing the opened audio device corresponding to the target parameters by the Audio-Hal, so that the audio device enters an idle state.
[0052] In an optional implementation, the message includes a message for exiting sleep, and the sleep control of the audio device by the Audio-Hal includes: calling an exit sleep interface by the Audio-Hal, obtaining parameters in a created map through the exit sleep interface; if there are parameters in the sleep state in the map, opening the audio device corresponding to the parameters in the sleep state, so that the audio device returns to a state before sleep.
[0053] In this embodiment, a sleep wake-up mechanism can be added in the Audio-Hal. Specifically, a cache map (openedPathMap) can be created by the Audio-Hal to manage the opened audio device, and the parameters corresponding to the path are saved to the cache map when the path is opened (in the case of normal operation of the audio device), and the parameters corresponding to the path are removed (except for the audio device in the sleep state) when the path is closed. The parameters when the path is opened include the sampling rate, sampling format, and channel number of the audio device.
[0054] In this embodiment, a start sleep interface is added in the Audio-Hal, the target parameters corresponding to the opened path stored in the map are obtained by calling the start sleep interface, and the corresponding path is closed by the parameters, and the corresponding audio device is closed by the parameters. In the Audio-Hal, an exit sleep interface and a completely enter sleep interface are also added; optionally, the data in the map is obtained by calling the completely enter sleep interface, and the opened path corresponding to the parameters is forcibly closed if the parameters exist in the map, and the audio device corresponding to the parameters is forcibly closed. For the case of exiting sleep, the exit sleep interface can be called. The parameters in the map are obtained by the exit sleep interface; if there are parameters in the sleep state in the map, the audio device corresponding to the parameters in the sleep state is opened, so that the audio device returns to a state before sleep.
[0055] For step S130:
[0056] In an alternative embodiment, the audio manager AudioFlinger within the Audio- Framework framework layer interacts with the Audio-Hal based on the sleep message through a preset function within the Audio-Framework framework layer, including: if the message is a start sleep message, the preset function blocks the audio thread of the AudioFlinger interacting with the Audio-Hal by using a thread mutual exclusion variable, so that the audio thread is in a waiting state; the preset function includes a notify all playback thread function and a notify all recording thread function.
[0057] In an alternative embodiment, the audio manager AudioFlinger within the Audio- Framework framework layer interacts with the Audio-Hal based on the sleep message through a preset function within the Audio-Framework framework layer, including: the preset function controls the audio thread of the AudioFlinger interacting with the Audio-Hal to be unlocked, so that the audio thread resumes reading and / or writing data to the Audio-Hal.
[0058] In this embodiment, the Audio-Framework framework layer receives the sleep information fed back by the Audio-Hal through a sleep state interface, and creates a notify all playback thread function (notifyPlaybackStrStateChange) and a notify all recording thread function (notifyRecordStrStateChange) in the AudioFlinger within it. If the sleep message is a start sleep message, the AudioFlinger interacting with the Audio-Hal is notified to stop through the notifyPlaybackStrStateChange, so that the playback thread waits; correspondingly, the AudioFlinger interacting with the Audio-Hal is notified to stop through the notifyRecordStrStateChange, so that the recording thread waits. The operation of starting sleep can be processed in the playback thread (PlaybackThread) and the recording thread (RecordThread). For example, in the playback thread, the judgment through the sleep message is processed in the loop of the playback logic, when it is judged to start sleep, the playback thread waits until the notifyPlaybackStrStateChange notifies to stop waiting.
[0059]
[0060] Optionally, if the sleep message is a message for exiting sleep, the audio thread for AudioFlinger and Audio-Hal interaction is unlocked by the created notifyPlaybackStrStateChange and notifyPlaybackStrStateChange, and after the unlocking, data can be read and / or written to Audio-Hal, so that Audio-Hal controls the lower layer audio device to recover. Optionally, notifyPlaybackStrStateChange and
[0061] In the notifyPlaybackStrStateChange function, the method in the mStrCond.notify_all() statement can be used to exit sleep, so that the audio thread for AudioFlinger and Audio-Hal interaction is unlocked and recovered. Optionally, the threadLoop() function can be used for the execution of the playback thread or the recording thread, and the internal loop is performed. If the audio thread for AudioFlinger and Audio-Hal interaction is unlocked, the method of the threadLoop() function can be used to continue the execution of the playback thread or the recording thread. Thus, the preset function created is used to unlock the audio thread, and the unlocking efficiency can be improved.
[0062] For step S140:
[0063] In an optional embodiment, the method further includes: if the message is a start sleep message, controlling, by the AudioFlinger, an audio object in the App to enter a sleep state; and blocking, by a read / write function in the audio object, an audio thread in the App, wherein the audio object includes an AudioTrack object and an AudioRecord object.
[0064] In an optional embodiment, the method further includes: if the sleep message is an exit sleep message, controlling, by the AudioFlinger, an audio object in the App to exit a sleep state, and recovering the audio thread in the App.
[0065] Specifically, AudioTrack and AudioRecord are objects in the App, and the AudioFlinger is in the system, and inter-process communication is required between the two, wherein binder is a communication mechanism; for example, the binder is a communication mechanism between the AudioFlinger and the App. Figure 1 and Figure 3As shown, the Audio-Framework framework layer includes TrackHandle, AudioTrack object, AudioRecord object, hw_module_t_, RecordThreads and PlaybackThreads. Among them, AudioFlinger includes TrackHandle, hw_module_t_, RecordThreads and PlaybackThreads. The structure of AudioFlinger not only includes Figure 3 The part shown can also include other parts. Among them, in AudioFlinger, when TrackHandle receives a call from RecordThreads or PlaybackThreads, the sleep information is transmitted to the AudioTrack object and the AudioRecord object in the client through the AudioTrack object and the AudioRecord object inside AudioFlinger. Based on the sleep message, the current power state is determined through the method in the read function of the AudioRecord object and the write function of the AudioTrack object. If the sleep message is a start sleep message, the recording thread and the playback thread of the App are automatically blocked, and the App can be stuck at a specific playback and recording progress, without affecting the specific business of the App.
[0066] Among them, during sleep, if there is a thread that meets the conditions of the read function and the write function, the thread is blocked in the function through the two functions, and the recording thread and the playback thread are blocked through the method in the function. If the sleep message is an exit sleep message, the AudioTrack object and the AudioRecord object in the client are notified to exit sleep, which can be understood as suspending memory (exit STR, Suspend to Disk), unlocking the thread mutex variable, and if there is a thread stuck in the read / write function, the thread is restored, and the playback or recording is automatically restored. The specific method flow can be referred to Figure 4 .
[0067] In related technologies, if the peripheral devices (such as microphones, speakers, cameras, etc.) are not closed when the vehicle-mounted audio is in sleep state, they will be repeatedly awakened after sleep, the sleep current will be high, and problems such as power feeding will occur. If there is no remote control function, the device may be completely shut down after the number of sleep times reaches the upper limit, so there is no fast experience after unlocking, which affects the user experience. Therefore, the sleep of the peripheral device is very important.
[0068] In the related art, an App needs to listen to a sleep signal, so the App needs to adapt to the signal, and no corresponding adaptation processing is performed on the App of an application store, and some sleep problems exist. The application suspends an audio device through a sleep signal by system listening to the sleep signal, and each App does not need to listen to the signal, reducing code duplication, and the system uniformly controls sleep, and no exception is thrown to the App, only being stuck in a method in the read and writer functions, and if an application downloaded by the application store is not adapted, a power feeding risk may exist. The application completes sleep control through the system, and can effectively avoid the power feeding risk caused by the audio device not being closed.
[0069] Figure 5 is a sleep control system structure block diagram of a vehicle-mounted audio provided by an embodiment of the application, wherein the system comprises:
[0070] The audio device sleep control module 510 is configured to perform sleep control on the audio device through an audio hardware abstraction layer Audio-Hal if the car service listens to a sleep message of the vehicle; wherein the sleep message comprises a message of starting sleep or a message of exiting sleep.
[0071] The feedback module 520 is configured to feed back the sleep message to an Audio-Framework framework layer through the Audio-Hal.
[0072] The first control module 530 is configured to control an audio thread of an audio manager AudioFlinger in the Audio-Framework framework layer and the Audio-Hal based on the sleep message through a preset function inside the Audio-Framework framework layer.
[0073] The second control module 540 is configured to control an audio thread of an application program App based on the sleep message through the AudioFlinger; wherein the audio thread comprises a recording thread and / or a playing thread.
[0074] Optionally, the sleep message comprises a message of starting sleep, and the sleep control on the audio device through the audio hardware abstraction layer Audio-Hal comprises:
[0075] An interface of starting sleep is called through the Audio-Hal, and parameters stored in a created cache map are acquired through the interface of starting sleep.
[0076] If target parameters corresponding to an opened path exist in the cache map, an opened audio device corresponding to the target parameters is closed through the Audio-Hal, so that the audio device enters an idle state.
[0077] Optionally, the preset function inside the Audio-Framework framework layer controls an audio thread of an audio manager AudioFlinger inside the Audio-Framework framework layer and Audio-Hal based on the sleep message, including:
[0078] The preset function adopts a thread mutex variable to block the audio thread of the AudioFlinger and Audio-Hal, so that the audio thread is in a waiting state; wherein the preset function includes a notify all playing thread function and a notify all recording thread function.
[0079] Optionally, the AudioFlinger controls an audio thread of an application App based on the sleep message, including:
[0080] The AudioFlinger controls an audio object in the App to enter a sleep state;
[0081] The audio object includes an AudioTrack object and an AudioRecord object.
[0082] Optionally, the message includes a message of exiting sleep, and the Audio-Hal controls an audio device to sleep, including:
[0083] The Audio-Hal calls an exit sleep interface, and obtains parameters in a created map through the exit sleep interface;
[0084] If the map has parameters in a sleep state, the audio device corresponding to the parameters in the sleep state is opened, so that the audio device returns to a state before sleep.
[0085] Optionally, the preset function inside the Audio-Framework framework layer controls an audio thread of an audio manager AudioFlinger inside the Audio-Framework framework layer and Audio-Hal based on the sleep message, including:
[0086] The preset function controls the audio thread of the AudioFlinger and Audio-Hal to be unlocked, so that the audio thread reads and / or writes data to Audio-Hal.
[0087] Optionally, the AudioFlinger controls an audio thread of an application App based on the sleep message, including:
[0088] The AudioFlinger controls the audio objects in the App to exit the dormant state and resume the audio thread in the App.
[0089] It should be noted that, Figure 5 The system provided by the embodiments of the present application is only an example, and the structure division of the system is not limited to Figure 5 The system shown in the figure, for example, can be Figure 1 The structure of the system shown, wherein the architecture of the Audio-Framework framework layer can refer to Figure 3 .
[0090] As Figure 6 The embodiments of the present application provide an electronic device, which comprises a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112 and the memory 113 complete mutual communication through the communication bus 114,
[0091] The memory 113 is used for storing a computer program.
[0092] In an embodiment of the present application, the processor 111 is used for executing the program stored in the memory 113, and realizes the method provided by any one of the preceding method embodiments.
[0093] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to realize the method steps provided by any one of the preceding method embodiments.
[0094] The system embodiments described above are only schematic, wherein the units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., they can be located in one place, or can be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments.
[0095] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be realized by means of software plus a general hardware platform, and of course can also be realized by hardware. Based on such understanding, the above technical solutions essentially or say the part that contributes to the related art can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.
[0096] It is to be understood that the terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "includes", "including" and "has" are inclusive and therefore specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order
[0097] The above description is merely that of certain embodiments of the present application and is not intended to limit the application to the specific embodiments. Various modifications to these embodiments can be apparent to those with skill in the art from the description and drawings herein, with the generic principles described herein being applicable to other embodiments and applications. Therefore, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A sleep control method of in-vehicle audio, characterized by, The application comprises the following technical solutions: If the car service listens to the sleep message of the vehicle, the audio device is controlled to sleep through the audio hardware abstraction layer Audio-Hal; wherein the sleep message comprises a message of starting sleep or a message of exiting sleep; A sleep wake-up mechanism is added in the Audio-Hal, a cache map is created, and the opened audio device is managed; each time the path is opened, the parameters corresponding to the path are saved in the cache map, and when the path is closed, the parameters corresponding to the path are removed from the cache map; In the case that the sleep message comprises a message of starting sleep, a start sleep interface is called through the Audio-Hal, and the parameters stored in the created cache map are obtained through the start sleep interface; if there are target parameters corresponding to the opened path in the cache map, the opened audio device corresponding to the target parameters is closed through the Audio-Hal, so that the audio device enters an idle state; In the case that the sleep message comprises a message of exiting sleep, an exit sleep interface is called through the Audio-Hal, and the parameters in the created map are obtained through the exit sleep interface; if there are parameters in the sleep state in the map, the audio device corresponding to the parameters in the sleep state is opened, so that the audio device recovers to the state before sleep; In the Audio-Hal, a completely enter sleep interface is added, the completely enter sleep interface is called through the Audio-Hal, the parameters stored in the created cache map are obtained through the completely enter sleep interface, and if there are target parameters corresponding to the opened path in the cache map, the path corresponding to the target parameters is forcibly closed through the Audio-Hal; The Audio-Hal feeds back the sleep message to the Audio-Framework framework layer; The audio manager AudioFlinger in the Audio-Framework framework layer and the audio thread interacting with the Audio-Hal are controlled based on the sleep message through a preset function in the Audio-Framework framework layer; wherein the preset function comprises a notify all playback thread function and a notify all recording thread function; The audio thread of the application program App is controlled based on the sleep message through the AudioFlinger; wherein the audio thread comprises a recording thread and / or a playback thread.
2. The method of claim 1, wherein, The audio manager AudioFlinger in the Audio-Framework framework layer and the audio thread interacting with the Audio-Hal are controlled based on the sleep message through a preset function in the Audio-Framework framework layer, comprising: The audio thread interacting with the Audio-Hal is blocked by the AudioFlinger through the preset function, so that the audio thread is in a waiting state.
3. The method of claim 1, wherein, The audio thread of the application App is controlled by the AudioFlinger based on the sleep message, including: The audio object in the App is controlled by the AudioFlinger to enter a sleep state; The audio thread in the App is blocked by a read / write function in the audio object; wherein the audio object includes an AudioTrack object and an AudioRecord object.
4. The method of claim 1, wherein, The audio thread of the AudioFlinger interacting with the Audio-Hal is controlled by a preset function inside the Audio-Framework framework layer based on the sleep message, including: The audio thread of the AudioFlinger interacting with the Audio-Hal is controlled by the preset function to be unlocked, so as to restore reading and / or writing data to the Audio-Hal through the audio thread.
5. The method of claim 1, wherein, The audio thread of the application App is controlled by the AudioFlinger based on the sleep message, including: The audio object in the App is controlled by the AudioFlinger to exit the sleep state and restore the audio thread in the App.
6. A sleep control system for in-vehicle audio, characterized by comprising: Including: An audio device sleep control module is configured to control the audio device to sleep through the Audio-Hal if the car service listens to the sleep message of the vehicle; wherein the sleep message includes a message for starting sleep or a message for exiting sleep; A sleep wake-up mechanism is added in the Audio-Hal to create a cache map and manage the audio device that has been opened; each time the path is opened, the parameters corresponding to the path are saved to the cache map, and when the path is closed, the parameters corresponding to the path are removed from the cache map; In the case that the sleep message includes a message for starting sleep, a start sleep interface is called through the Audio-Hal to obtain the parameters stored in the created cache map through the start sleep interface; if the target parameters corresponding to the opened path exist in the cache map, the opened audio device corresponding to the target parameters is closed through the Audio-Hal, so that the audio device enters an idle state; In the case that the sleep message includes a message for exiting sleep, an exit sleep interface is called through the Audio-Hal to obtain the parameters in the created map through the exit sleep interface; if the parameters in the sleep state exist in the map, the audio device corresponding to the parameters in the sleep state is opened, so that the audio device returns to the state before sleep; The Audio-Hal is added with a thorough sleep-in interface, the thorough sleep-in interface is called through the Audio-Hal, parameters stored in a created cache map are acquired through the thorough sleep-in interface, if there are target parameters corresponding to an open channel in the cache map, the channel corresponding to the target parameters is forced to be closed through the Audio-Hal; A feedback module is configured to feed back the sleep message to an Audio-Framework framework layer through the Audio-Hal; A first control module is configured to control, based on the sleep message, an audio thread of an audio manager AudioFlinger in the Audio-Framework framework layer and the Audio-Hal through a preset function in the Audio-Framework framework layer; the preset function includes a notify all play thread function and a notify all record thread function; A second control module is configured to control, based on the sleep message, an audio thread of an application App through the AudioFlinger; the audio thread includes a record thread and / or a play thread.
7. An electronic device, comprising: The computer program is executed by the processor to implement the method in any one of claims 1-5. The computer program is executed by the processor to implement the method in any one of claims 1-5. 8. A computer-readable storage medium having stored thereon a computer program, characterized in that,