Dormancy control method, system and equipment for vehicle-mounted audio and storage medium

Abstract

The embodiment of the invention provides a vehicle-mounted audio sleep control method, system and device and a storage medium, and relates to the technical field of vehicle-mounted audios, and the method comprises the steps: carrying out the sleep control of an audio device through an audio hardware abstraction layer Audio-Hal if a car service monitors a sleep message of a vehicle; wherein the dormancy message comprises a message for starting dormancy or a message for quitting dormancy; the dormancy information is fed back to an Audio-Framework framework layer through the Audio-Hal; according to a preset function in an Audio-Framework framework layer, on the basis of the dormancy information, controlling an audio thread of interaction between an audio manager (Audio Flinger) in the Audio-Framework framework layer and the Audio-Hal, wherein the audio thread of interaction between the audio manager (Audio Flinger) and the Audio-Hal is located in the Audio-Framework framework layer, and the audio thread of interaction between the audio manager (Audio Flinger) and the Audio-Hal is located in the Audio-Framework framework layer; an audio thread of an application App is controlled based on the dormancy message through the Audio Flinger; wherein the audio thread comprises a recording thread and / or a playing thread, the App does not need to carry out adaptation processing, dormancy can be effectively controlled under the condition that the App does not perceive, the dormancy problem is effectively avoided, and the safety is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle audio technology, and in particular to a sleep control method, system, device and storage medium for vehicle audio. Background Art

[0002] On the car audio system, cold starts are slow (20 seconds or so), but with the sleep-wake mechanism, the start time can be completed in one or two seconds, as long as the current during sleep is low enough that the battery can support this sleep after locking the car, and then wake up quickly when unlocking.

[0003] In the related technology, the application (Application, App) that uses audio usually monitors the sleep signal and performs corresponding actions. For example, the sleep signal can be a signal for entering sleep mode, and then the audio device is turned off during sleep mode; or the sleep signal can be a signal for exiting sleep mode, and then the state before sleep mode is restored when exiting sleep mode. However, this mechanism has a big disadvantage. All apps need to adapt to this signal. For some apps in some app stores, there is no corresponding adaptation processing, which may cause some sleep problems. Summary of the invention

[0004] The embodiments of the present application provide a sleep control method, system, device and storage medium for in-vehicle audio, which can effectively control sleep without the need for App adaptation processing, effectively avoid sleep problems and improve safety.

[0005] In a first aspect, an embodiment of the present application provides a sleep control method for an in-vehicle audio system, comprising:

[0006] If the car service monitors the vehicle's sleep message, the audio device is controlled to sleep through the audio hardware abstraction layer Audio-Hal; wherein the sleep message includes a sleep start message or a sleep exit message;

[0007] Feedback the sleep information to the Audio-Framework framework layer through Audio-Hal;

[0008] Controlling the audio thread of the audio manager AudioFlinger in the Audio-Framework layer interacting with the Audio-Hal based on the sleep information through a preset function in the Audio-Framework layer;

[0009] The audio thread of the application App is controlled by the AudioFlinger based on the dormant message; wherein the audio thread includes a recording thread and / or a playing thread.

[0010] In a second aspect, an embodiment of the present application provides a dormancy control system for an in-vehicle audio system, including:

[0011] The audio device sleep control module is used to control the sleep of the audio device through the audio hardware abstraction layer Audio-Hal if the car service monitors the sleep message of the vehicle; the sleep message includes a sleep start message or a sleep exit message;

[0012] A feedback module, used for feeding back the sleep message to the Audio-Framework framework layer through Audio-Hal;

[0013] A first control module, configured to control the audio thread of the audio manager AudioFlinger in the Audio-Framework layer interacting with the Audio-Hal based on the sleep message through a preset function in the Audio-Framework layer;

[0014] The second control module is used to control the audio thread of the application App based on the dormant message through the AudioFlinger; wherein the audio thread includes a recording thread and / or a playing thread.

[0015] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0016] Memory for storing computer programs;

[0017] The processor is used to execute the computer program stored in the memory, and when the computer program is executed, the method provided in the embodiment of the present application is implemented.

[0018] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the method provided in the embodiment of the present application is implemented.

[0019] The technical solution provided by this application controls the sleep state of audio devices through Audio-Hal and controls the sleep state of audio devices through the preset functions in the Audio-Framework framework layer.

[0020] The audio thread that AudioFlinger, the audio manager inside the Audio-Framework framework layer, interacts with Audio-Hal. AudioFlinger controls the audio thread of the application App, that is, the system controls the dormancy of the in-vehicle audio from three aspects: 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 that AudioFlinger interacts with Audio-Hal. The dormancy of the in-vehicle audio is controlled by the system without the need for App adaptation processing. It can effectively control dormancy without App perception, effectively avoiding dormancy problems, and also improves security in the case of insecure App adaptation in the App Store. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0022] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0023] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0024] Figure 1 It is an architectural diagram of a car audio control system;

[0025] Figure 2 This is a flow chart of a sleep control method for an in-vehicle audio system provided in an embodiment of the present application;

[0026] Figure 3 This is the architecture diagram of the Audio-Framework layer;

[0027] Figure 4 This is a flow chart of a sleep control method for an in-vehicle audio system provided in an embodiment of the present application;

[0028] Figure 5 This is a structural block diagram of a dormant control system for an in-vehicle audio system provided in an embodiment of the present application;

[0029] Figure 6 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0031] The disclosure below provides many different embodiments or examples to implement different structures of the present invention. In order to simplify the disclosure of the present invention, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present invention. In addition, the present invention can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0032] The overall idea of ​​the technical solution provided by this application is as follows: the two states of entering sleep and exiting sleep are uniformly processed by the audio system, and the two states of entering sleep and exiting sleep are specifically processed by each layer in the audio system, without the need for the App to monitor the signal, and the sleep state is controlled without the App's perception, effectively avoiding the sleep problem and solving the problem of App incompatibility. The technical solution provided by this application is as follows:

[0033] The technical solution provided in this application is based on a dormancy control system for vehicle audio, which can also be called a dormancy wake-up system for vehicle audio. The system can be based on an Android system, and the architecture diagram of the system can be referred to as Figure 1 .like Figure 1As shown in the figure, App is at the top layer, where voice or multimedia interaction takes place, and AudioRecord (recording) objects and AudioTrack (playing) objects are created; the Audio-Framework framework layer includes corresponding objects, which manage the AudioRecord objects and AudioTrack objects of App through its internal objects, and for each different audio device type (multimedia, navigation, and one bus each), each bus creates a playing thread or a recording thread to the audio hardware abstraction layer (Audio-Hal); wherein, bus can be understood as an address, through which the specific audio device used in Audio-Hal can be determined, and the audio core layer (Audio-Kernel) is used to mount the corresponding audio device according to the device tree during startup initialization; Audio-Hal writes data to the playback device, and then Audio-Kernel writes this data to the digital signal processor (DSP), and controls the audio device through the DSP to perform actual playback, while recording is the opposite of playback, and is achieved by reading data from the recording device.

[0034] Figure 2 This is a flow chart of a sleep control method for in-vehicle audio provided in an embodiment of the present application. The method can be executed by a sleep control system for in-vehicle audio. The system can be implemented by software and / or hardware. The system can be configured in electronic devices such as in-vehicle devices.

[0035] like Figure 2 As shown, the technical solution provided by the embodiment of the present application includes:

[0036] S110: If the car service monitors 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 includes a sleep start message or a sleep exit message.

[0037] In this embodiment, reference Figure 1 and Figure 2 The car service may belong to the entire Android hardware abstraction layer (Hal layer). If the car service monitors the vehicle's sleep message, it notifies the Audio-Hal of the same Hal layer, and completes the top-down sleep control through Audio-Hal. In this step, the sleep control of the lower-layer audio device is performed through Audio-Hal. The sleep message may be the power status information of the entire vehicle.

[0038] S120: Feedback the sleep message to the Audio-Framework framework layer through Audio-Hal.

[0039] In this embodiment, the Audio-Framework framework layer can receive the sleep message through the sleep state interface, thereby receiving the change of the sleep state. Specifically, by feeding back the sleep message, the Audio-Hal notifies the Audio-Framework framework layer to start entering sleep or exiting sleep.

[0040] In one implementation of an embodiment of the present application, optionally, a sleep state interface can be added in the hw_module_t handle that interacts with the Audio-Framework framework layer. The Audio-Framework framework layer can receive a sleep message through the sleep state interface. When Audio-Hal receives a sleep message sent by the car service, it can synchronously forward the sleep message to the Audio-Framework framework layer. This method is also a method of adding a sleep wake-up mechanism in Audio-Hal.

[0041] In the embodiment of the present application, the sleep message needs to be fed back to

[0042] Audio-Framework framework layer, because it is often not enough to only protect the channel in Audio-Hal, the App cannot sense whether the channel is opened or closed. Recording is fine, but 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, this sleep message needs to be passed back to the Audio-Framework framework layer, and the Audio-Framework framework layer will process it to make the App passively paused. Therefore, by feeding back the sleep message to the Audio-Framework framework layer, and feeding back the sleep message to the Audio-Framework framework layer through Audio-Hal, it is convenient for the Audio-Framework framework layer to control the App and complete the upper-level sleep control of Audio-Hal.

[0043] S130: Controlling the audio thread of the audio manager AudioFlinger in the Audio-Framework layer interacting with the Audio-Hal based on the sleep message through a preset function in the Audio-Framework layer.

[0044] In this embodiment, the architecture of the Audio-Framework layer can refer to Figure 3 ,like Figure 3As shown, the interaction between AudioFlinger and Audio-Hal can be through the audio thread, wherein the audio thread can include a playback thread (PlaybackThread) and a recording thread (RecordThread).

[0045] In this embodiment, optionally, the preset function includes a function for notifying all playback threads (notifyPlaybackStrStateChange) and a function for notifying all recording threads (notifyRecordStrStateChange). If the sleep control message includes a start sleep message, the audio thread for the interaction between AudioFlinger and Audio-Hal can be blocked by the preset function; if the sleep control message includes a message for exiting sleep, the audio thread for the interaction between AudioFlinger and Audio-Hal can be restored by 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 playing thread.

[0047] In this embodiment, if the sleep message is a start sleep message, the audio thread of the App is blocked by AudioFlinger, and if the sleep message is an exit sleep message, the audio thread of the App is restored by AudioFlinger.

[0048] The technical solution provided by this application controls the sleep state of audio devices through Audio-Hal and controls the sleep state of audio devices through the preset functions in the Audio-Framework framework layer.

[0049] The audio thread of the audio manager AudioFlinger inside the Audio-Framework framework layer interacts with Audio-Hal. It controls the audio thread of the application App through AudioFlinger, that is, the dormancy of the in-vehicle audio is controlled by the system without the need for App adaptation processing. It can effectively control dormancy without App perception, effectively avoiding dormancy problems, and also improves security for situations where App adaptation in the App Store is insecure.

[0050] For step S110:

[0051] In an optional embodiment, optionally, the sleep message includes a sleep start message, and the sleep control of the audio device through the audio hardware abstraction layer Audio-Hal includes: calling a sleep start interface through the Audio-Hal, and obtaining parameters stored in the created cache map through the sleep start interface; if there is a target parameter corresponding to an open path in the cache map, closing the opened audio device corresponding to the target parameter through the Audio-Hal, so that the audio device enters an idle state.

[0052] In an optional implementation, optionally, the message includes an exit-hibernation message, and the audio device is controlled to hibernate through the audio hardware abstraction layer Audio-Hal, including: calling an exit-hibernation interface through the Audio-Hal, and obtaining parameters in the created map through the exit-hibernation interface; if there are parameters in the hibernation state in the map, turning on the audio device corresponding to the parameters in the hibernation state to restore the audio device to the state before hibernation.

[0053] In this embodiment, a sleep wake-up mechanism can be added to Audio-Hal. Specifically, a cache map (openedPathMap) can be created through Audio-Hal to manage the audio devices that have been opened. Each time a path is opened (when the audio device is operating normally), the parameters corresponding to the path are saved in the cache map. When the path is closed (when the audio device is closed normally), the parameters corresponding to the path are removed (except when the audio device in the sleep state is closed). The parameters when opening the path include the sampling rate, sampling format, number of channels and other data of the audio device.

[0054] In this embodiment, an interface for starting sleep is added in Audio-Hal, and the target parameters corresponding to the open channels stored in the map are obtained by calling the interface for starting sleep. The corresponding channels can be controlled to be closed by the parameters, wherein the corresponding audio devices are closed by the parameters. Among them, an interface for exiting sleep and an interface for completely entering sleep are also added to Audio-Hal; optionally, the data in the map is obtained by calling the interface for completely entering sleep, and if the parameters corresponding to the open channels still exist in the map, the channels corresponding to the parameters are forcibly closed, which includes forcibly closing the audio devices corresponding to the parameters. Among them, in the case of exiting sleep, the interface for exiting sleep can be called. The parameters in the map are obtained through the interface for exiting sleep; if the parameters in the sleep state exist in the map, the audio devices corresponding to the parameters in the sleep state are turned on to restore the audio devices to the state before sleep.

[0055] For step S130:

[0056] In an optional implementation, optionally, the audio thread of the audio manager AudioFlinger interacting with Audio-Hal inside the Audio-Framework framework layer is controlled based on the sleep message through a preset function inside the Audio-Framework framework layer, including: if the message is a start sleep message, the audio thread of the audio manager AudioFlinger interacting with Audio-Hal is blocked by a thread mutex variable through the preset function to put the audio thread in a waiting state; the preset function includes a function of notifying all playback threads and a function of notifying all recording threads.

[0057] In an optional embodiment, optionally, the audio thread of the audio manager AudioFlinger inside the Audio-Framework framework layer interacting with Audio-Hal is controlled based on the sleep message through a preset function inside the Audio-Framework framework layer, including: controlling the audio thread of the audio manager AudioFlinger interacting with Audio-Hal to be unlocked through the preset function, so as to resume reading and / or writing data to Audio-Hal through the audio thread.

[0058] In this embodiment, the Audio-Framework framework layer receives the sleep information fed back by Audio-Hal through the sleep state interface, and creates a function to notify all playback threads (notifyPlaybackStrStateChange) and a function to notify all recording threads (notifyRecordStrStateChange) in the internal AudioFlinger. If the sleep message is a start sleep message, notifyPlaybackStrStateChange is used to notify AudioFlinger to stop the playback thread that interacts with Audio-Hal, so that the playback thread waits; correspondingly, notifyRecordStrStateChange is used to notify AudioFlinger to stop the recording thread that interacts with Audio-Hal, so that the recording thread waits. Among them, 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 sleep message is used to make a judgment in the playback logic in the loop processing. When it is judged that the sleep starts, the playback thread is made to wait until it is determined that the sleep starts.

[0059] NotifyPlaybackStrStateChange until the waiting stops.

[0060] Optionally, if the sleep message is a message to exit sleep, the created notifyPlaybackStrStateChange and notifyPlaybackStrStateChange are used to control the unlocking of the audio thread for the interaction between AudioFlinger and Audio-Hal. After unlocking, data can be read and / or written to Audio-Hal, so that Audio-Hal controls the recovery of the underlying audio device.

[0061] In the notifyPlaybackStrStateChange function, the method in the "mStrCond.notify_all()" statement can be used to exit hibernation and restore the unlocking of the audio thread for the interaction between AudioFlinger and Audio-Hal. Optionally, the threadLoop() function can be used to execute the playback thread or the recording thread for internal looping. If the audio thread for the interaction between AudioFlinger and Audio-Hal is unlocked, the threadLoop() function method can be used to continue executing the playback thread or the recording thread. Therefore, by creating a preset function to unlock the audio thread, the unlocking efficiency can be improved.

[0062] For step S140:

[0063] In an optional implementation, optionally, controlling the audio thread of the application App based on the sleep message through the AudioFlinger includes: if the message is a start sleep message, controlling the audio object in the App to enter a sleep state through the AudioFlinger; blocking the audio thread in the App through the read / write function in the audio object; wherein the audio object includes an AudioTrack object and an AudioRecord object.

[0064] In an optional implementation, controlling the audio thread of the application App based on the sleep message through the AudioFlinger includes: if the sleep message is an exit sleep message, controlling the audio object in the App to exit the sleep state through the AudioFlinger, and resuming the audio thread in the App.

[0065] Specifically, AudioTrack and AudioRecord are objects in the App, while AudioFlinger is in the system. The two need inter-process communication via Binder, where binder is a communication mechanism. Figure 1 and Figure 3As shown in the figure, the Audio-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. Among them, the structure of AudioFlinger not only includes Figure 3 The part shown may also include other parts. Among them, in AudioFlinger, when TrackHandle receives a call from RecordThreads or PlaybackThreads, it transmits the sleep information to the AudioTrack object and AudioRecord object in the client through the AudioTrack object and AudioRecord object inside AudioFlinger. The current power state is determined based on the sleep message through the methods 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, so that the applied App can be stuck in the specific playback and recording progress without affecting the specific App business.

[0066] Among them, when sleeping, through the thread mutex variable, if there is a thread that meets the conditions of the read function and the write function, the thread will be stuck in the function through the two functions, and the recording thread and the playback thread will be blocked through the method in the function. If the sleep message is an exit sleep message, the AudioTrack object and 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, if there is a thread stuck in the read (read) / write (write) function, the thread is restored, and the playback or recording can be automatically resumed. For the specific method flow, please refer to Figure 4 .

[0067] In the related art, when the car audio is in sleep mode, if there are peripheral devices (such as microphones, speakers, cameras, etc.) that are not turned off, they will be repeatedly awakened after sleep mode, and the sleep current will be very high, causing problems such as power supply. If there is no remote control function, the car may be completely shut down after the sleep times reach the upper limit, so there will be no fast experience after unlocking, affecting the user experience. It is precisely because of this that the sleep mode of peripheral devices is very important.

[0068] In the related technology, the App needs to monitor the sleep signal, so the App needs to adapt the signal. For the App in the App Store, there is no corresponding adaptation processing, and there will be some sleep problems. This application monitors the sleep signal through the system and pauses the audio device through the sleep signal. There is no need for each App to monitor the signal, which reduces the duplication of code. The sleep is uniformly controlled by the system. For the App, no exception is thrown, but it is stuck in the method in the read and writer functions. If the application downloaded from the App Store is not adapted, there may be a risk of power supply. This application completes the sleep control through the system, which can effectively avoid the risk of power supply caused by the audio device not being turned off.

[0069] Figure 5 This is a structural block diagram of a dormant control system for an in-vehicle audio system provided in an embodiment of the present application, wherein the system includes:

[0070] The audio device sleep control module 510 is used to control the audio device to sleep through the audio hardware abstraction layer Audio-Hal if the car service monitors the sleep message of the vehicle; wherein the sleep message includes a sleep start message or a sleep exit message;

[0071] Feedback module 520, used for feeding back the sleep message to the Audio-Framework framework layer through Audio-Hal;

[0072] A first control module 530 is used to control the audio thread of the audio manager AudioFlinger in the Audio-Framework framework layer interacting with the Audio-Hal based on the sleep message through a preset function in the Audio-Framework framework layer;

[0073] The second control module 540 is used to control 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 playing thread.

[0074] Optionally, the sleep message includes a sleep start message, and the sleep control of the audio device through the audio hardware abstraction layer Audio-Hal includes:

[0075] Calling a start sleep interface through the Audio-Hal, and obtaining parameters stored in the created cache map through the start sleep interface;

[0076] If there is a target parameter corresponding to an open path in the cache map, the opened audio device corresponding to the target parameter is closed through the Audio-Hal, so that the audio device enters an idle state.

[0077] Optionally, controlling the audio thread of the audio manager AudioFlinger in the Audio-Framework framework layer interacting with Audio-Hal based on the sleep message through a preset function in the Audio-Framework framework layer, including:

[0078] The preset function uses a thread mutex variable to block the audio thread of the AudioFlinger interacting with Audio-Hal, so that the audio thread is in a waiting state; wherein the preset function includes a function of notifying all playback threads and a function of notifying all recording threads.

[0079] Optionally, controlling the audio thread of the application App based on the dormant message through the AudioFlinger includes:

[0080] Control the audio object in the App to enter a dormant state through the AudioFlinger;

[0081] 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.

[0082] Optionally, the message includes a message for exiting sleep mode, and the sleep mode of the audio device is controlled through the audio hardware abstraction layer Audio-Hal, including:

[0083] Calling the exit-sleep interface through the Audio-Hal, and obtaining the parameters in the created map through the exit-sleep interface;

[0084] If the map contains parameters in the sleep state, the audio device corresponding to the parameters in the sleep state is turned on to restore the audio device to a state before the sleep state.

[0085] Optionally, controlling the audio thread of the audio manager AudioFlinger in the Audio-Framework framework layer interacting with Audio-Hal based on the sleep message through a preset function in the Audio-Framework framework layer, including:

[0086] The preset function is used to control the audio thread for AudioFlinger to interact with Audio-Hal to unlock, so as to resume reading and / or writing data to Audio-Hal through the audio thread.

[0087] Optionally, controlling the audio thread of the application App based on the dormant message through the AudioFlinger includes:

[0088] The AudioFlinger is used to control the audio object in the App to exit the dormant state and to resume the audio thread in the App.

[0089] It should be noted that Figure 5 This is only an example of the system provided in the embodiment of the present application. The structural division of the system is not limited to Figure 5 The situation shown, for example, could be Figure 1 The structure of the system shown in the figure, where the architecture of the Audio-Framework layer can be referenced Figure 3 .

[0090] like Figure 6 As shown, an embodiment of the present application provides an electronic device, including 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 communicate with each other through the communication bus 114.

[0091] Memory 113, used for storing computer programs;

[0092] In one embodiment of the present application, the processor 111 is used to implement the method provided by any one of the aforementioned method embodiments when executing the program stored in the memory 113.

[0093] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the method steps provided in any of the aforementioned method embodiments are implemented.

[0094] The system embodiment described above is merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0095] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0096] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0097] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A sleep control method for an in-vehicle audio system, characterized in that: include: If the car service monitors the vehicle's sleep message, the audio device is controlled to sleep through the audio hardware abstraction layer Audio-Hal; wherein the sleep message includes a sleep start message or a sleep exit message; Feedback the sleep information to the Audio-Framework framework layer through Audio-Hal; Controlling the audio thread of the audio manager AudioFlinger in the Audio-Framework layer interacting with the Audio-Hal based on the sleep information through a preset function in the Audio-Framework layer; The audio thread of the application App is controlled by the AudioFlinger based on the dormant message; wherein the audio thread includes a recording thread and / or a playing thread.

2. The method according to claim 1, characterized in that In the case where the sleep message includes a sleep start message, the sleep control of the audio device through the audio hardware abstraction layer Audio-Hal includes: Calling a sleep start interface through the Audio-Hal, and obtaining parameters stored in the created cache map through the sleep start interface; If there is a target parameter corresponding to an open path in the cache map, the opened audio device corresponding to the target parameter is closed through the Audio-Hal, so that the audio device enters an idle state.

3. The method according to claim 2, characterized in that The audio thread of the interaction between the audio manager AudioFlinger and Audio-Hal in the Audio-Framework framework layer is controlled based on the sleep message through the preset function in the Audio-Framework framework layer, including: The preset function uses a thread mutex variable to block the audio thread that interacts between the AudioFlinger and the Audio-Hal, so that the audio thread is in a waiting state; wherein the preset function includes a function of notifying all playback threads and a function of notifying all recording threads.

4. The method according to claim 2, characterized in that: The controlling the audio thread of the application App based on the dormant message through the AudioFlinger includes: Control the audio object in the App to enter a dormant state through the AudioFlinger; 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.

5. The method according to claim 1, characterized in that In the case where the message includes a message for exiting sleep, the audio device is controlled to sleep through the audio hardware abstraction layer Audio-Hal, including: Calling the exit-sleep interface through the Audio-Hal, and obtaining the parameters in the created map through the exit-sleep interface; If the map contains parameters in the sleep state, the audio device corresponding to the parameters in the sleep state is turned on to restore the audio device to a state before the sleep state.

6. The method according to claim 5, characterized in that The method of controlling the audio thread of the audio manager AudioFlinger in the Audio-Framework framework layer interacting with Audio-Hal based on the sleep message through the preset function in the Audio-Framework framework layer includes: The audio thread for interacting between the AudioFlinger and the Audio-Hal is unlocked by controlling the preset function, so as to resume reading and / or writing data to the Audio-Hal through the audio thread.

7. The method according to claim 5, characterized in that The controlling the audio thread of the application App based on the dormant message through the AudioFlinger includes: The AudioFlinger is used to control the audio object in the App to exit the dormant state and to resume the audio thread in the App.

8. A dormancy control system for an in-vehicle audio system, characterized in that: include: The audio device sleep control module is used to control the sleep of the audio device through the audio hardware abstraction layer Audio-Hal if the car service monitors the sleep message of the vehicle; the sleep message includes a sleep start message or a sleep exit message; A feedback module, used for feeding back the sleep message to the Audio-Framework framework layer through Audio-Hal; A first control module, configured to control the audio thread of the audio manager AudioFlinger in the Audio-Framework layer interacting with the Audio-Hal based on the sleep message through a preset function in the Audio-Framework layer; The second control module is used to control the audio thread of the application App based on the dormant message through the AudioFlinger; wherein the audio thread includes a recording thread and / or a playing thread.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to execute a computer program stored in the memory, and when the computer program is executed, implement the method described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method described in any one of claims 1 to 7 is implemented.

Images