Dynamic control method and system for audio output path of multi-screen different display equipment
By constructing a dynamic audio output path control method that combines user audio behavior models and task types, the problem of the Android native strategy framework's inability to flexibly switch audio paths in multi-screen display devices is solved, realizing automated audio path switching and improving the device's audio adaptation capabilities and user experience.
Patent Information
- Application Number
- CN202511049677.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-29
- Publication Date
- 2025-11-11
AI Technical Summary
The Android native audio strategy framework cannot flexibly and timely switch or use the audio paths expected by users in multi-screen devices with different displays. This results in the device not being able to fully utilize the multi-channel audio concurrent output capabilities of high-end hardware, and it lacks a weight scheduling and synchronization compensation mechanism for task scenarios and user intentions.
A user audio behavior model is constructed. Audio output preference rules are trained using a lightweight interpretable model based on decision trees or gradient boosting trees. Combined with task type and environmental awareness data, the audio output path is dynamically adjusted, and an online incremental learning mechanism is used to update the rules to achieve automated audio path switching.
It enables automatic switching of audio output paths based on user preferences and task requirements in multi-screen display devices, improving audio adaptation capabilities and user experience, and avoiding erroneous output and frequent manual intervention under the system's fixed priority strategy.
Smart Images
Figure CN120929040A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of audio output technology, and in particular to a method and system for dynamic control of audio output path in a multi-screen display device. Background Technology
[0002] With the diversification of mobile terminal forms, "dual-screen" devices using the Android system (such as conference tablets, all-in-one teaching machines, and portable laptop docks with a main screen and an external secondary screen connected via HDMI) are becoming increasingly popular. These devices often integrate multiple audio output interfaces, including HDMI, Bluetooth headsets, USB headsets, 3.5mm headsets, and built-in speakers. The Android native audio strategy framework was initially designed primarily for single-screen mobile phone scenarios, defaulting to a fixed priority (e.g., wired headsets > Bluetooth > HDMI > speaker) for audio path selection. Once an HDMI interface is detected as active, the system globally routes to HDMI, and in most models, the HDMI path is mutually exclusive with the built-in speaker.
[0003] However, in actual use of dual-screen devices, users' audio output path needs change rapidly depending on the current application task (watching movies, video conferencing, voice assistants, games, etc.) and personal historical preferences. For example, when presenting slides, users may want both video and audio output to the secondary screen and amplified through the conference room speakers; while when answering voice calls, they may want the audio to be played privately only through Bluetooth headphones. Furthermore, while some high-end hardware supports concurrent audio output, Android's default strategy cannot fully utilize this capability—although the device can drive both HDMI and built-in speakers simultaneously, it lacks a weighted scheduling and synchronization compensation mechanism tailored to the task scenario and user intent. Summary of the Invention
[0004] The purpose of this application is to propose a method and system for dynamic control of audio output paths in multi-screen display devices, so as to solve the technical problem that users cannot flexibly and timely switch or use the desired audio paths in parallel.
[0005] To address the aforementioned technical problems, this application provides a method for dynamically controlling the audio output path of a multi-screen display device, employing the following technical solution:
[0006] A method for dynamically controlling the audio output path of a multi-screen display device includes the following steps:
[0007] A user audio behavior model is constructed based on the user's selection behavior of audio output path under different audio device connection states;
[0008] Get the task type of the currently running tasks in the system foreground;
[0009] Based on the user audio behavior model and the task type, determine the target audio output path;
[0010] The audio output path is switched to the target audio output path by controlling the audio policy service module.
[0011] In one possible implementation, the step of constructing a user audio behavior model based on the user's selection behavior of audio output paths under different audio device connection states includes:
[0012] When an audio device experiences a connection, disconnection, or priority change event, the audio output path finally confirmed by the user is recorded. The audio device includes, but is not limited to, HDMI, USB headphones, 3.5mm headphones, Bluetooth headphones, and speakers.
[0013] When recording the audio output path selected by the user, context data related to the selection is collected synchronously, and the context data is concatenated according to the predefined field order to generate a feature vector for training the behavior model. The context data includes the time period in which the current selection occurred, the task type of the running task, the on / off status of the main screen and the secondary screen, and the optional network connection status.
[0014] The feature vectors are used as input samples to train a lightweight interpretable model based on decision trees or gradient boosting trees, and audio output preference rules are generated. Match confidence is calculated for each preference rule.
[0015] In one possible implementation, the update of the audio output preference rule is achieved using an online incremental learning method, and includes:
[0016] When the confidence level of a new sample matching an existing rule is lower than a preset first threshold, a rule update process is triggered to introduce new branch conditions.
[0017] When a user rejects the audio output path automatically selected by the system N times consecutively (N≥1), the confidence of the rule corresponding to the scenario is reduced, and only the decision branch containing the rule is updated locally by incremental learning to correct the prediction result.
[0018] After a rule is updated, a time decay weight is applied to each rule based on its most recent effective time to prevent outdated preferences from dominating new routing decisions.
[0019] In one possible implementation, the step of obtaining the task type of the currently running foreground task specifically includes:
[0020] The detection system runs applications in the foreground and maps them to a preset set of task types, including but not limited to media playback, video conferencing, voice interaction, games, and system prompts;
[0021] For different task types, query the task audio strategy table to obtain the priority sequence of the target audio output path corresponding to that task type.
[0022] In one possible implementation, if multiple available audio devices exist and support concurrent output, then after the step of querying the task audio policy table to obtain the priority sequence of the target audio output path corresponding to the task type for different task types, the method further includes:
[0023] Based on the audio requirements corresponding to the task type, assign initial weights to each candidate output path;
[0024] Based on the bandwidth capacity of each channel, the current system load, and whether it occupies exclusive audio resources, the volume gain, thread priority, and buffer size of each channel are dynamically adjusted.
[0025] Delay compensation parameters are set for each channel and synchronous refresh control is performed to ensure time alignment and stable sound quality of multi-channel output.
[0026] In one possible implementation, the step of determining the target audio output path based on the user audio behavior model and the task type, when the target output path obtained based on the user audio behavior model is inconsistent with the target output path obtained based on the task type priority sequence, further includes:
[0027] Collect environmental perception data, including ambient light intensity, screen folding angle, and the user's recent interaction status;
[0028] The audio output path is finally determined according to the preset conflict resolution rules, which include at least the following: when the ambient light intensity is lower than the threshold L, the headphone output is given priority; when the screen is at the presentation unfolded angle and the HDMI connection is detected to be valid, the HDMI output is given priority; when the user is detected to be still and without interactive operation for a set duration T, the current path is kept unchanged.
[0029] In one possible implementation, the step of controlling the audio output path to switch to the target audio output path via the audio policy service module specifically includes:
[0030] Call the audio policy service interface to bind the audio stream to the target output device node, and put the output devices corresponding to non-target paths into a mute or standby state;
[0031] During the switching process, fade-in / fade-out control is performed according to the buffer structure of the target path to prevent transient pops;
[0032] In concurrent output scenarios, each channel maintains an independent volume control channel, buffer refresh cycle, and synchronization flag to ensure continuous synchronization and distortion-free output of multiple channels after switching.
[0033] To address the aforementioned technical problems, this application also provides a dynamic control system for the audio output path of a multi-screen display device, employing the following technical solution:
[0034] A dynamic control system for the audio output path of a multi-screen display device includes:
[0035] The building module is used to construct a user audio behavior model based on the user's selection behavior of audio output path under different audio device connection states;
[0036] The acquisition module is used to obtain the task type of the currently running foreground tasks in the system.
[0037] The determination module is used to determine the target audio output path based on the user audio behavior model and the task type;
[0038] The switching module is used to control the audio output path to switch to the target audio output path through the audio policy service module.
[0039] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution:
[0040] A computer device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the dynamic control method for the audio output path of a multi-screen display device as described above.
[0041] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below:
[0042] A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the dynamic control method for the audio output path of a multi-screen display device as described above.
[0043] Compared with the prior art, the embodiments of this application have the following main advantages:
[0044] The dynamic audio output path control method for multi-screen display devices disclosed in this application determines the audio output path based on the user's audio output behavior model and the current task type, and dynamically switches the path by the audio strategy service module. This results in a control method that can simultaneously consider the user's long-term preferences and the immediate needs of the task, and achieve automated audio path switching. This avoids erroneous output and frequent manual intervention under the fixed priority strategy of the system, thereby significantly improving the audio adaptation capability and user experience of dual-screen display devices in complex scenarios. Attached Figure Description
[0045] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0046] Figure 1 This is a flowchart of an embodiment of the audio output path dynamic control method for multi-screen display devices according to this application;
[0047] Figure 2 This is a schematic diagram of a structure of an embodiment of the audio output path dynamic control system for a multi-screen display device according to this application;
[0048] Figure 3 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation
[0049] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0050] refer to Figure 1 The diagram illustrates a flowchart of an embodiment of a dynamic audio output path control method for a multi-screen display device according to this application. The dynamic audio output path control method for the multi-screen display device includes the following steps:
[0051] Step S101: Construct a user audio behavior model based on the user's selection behavior of audio output path under different audio device connection states.
[0052] In this embodiment, when the system detects a connection or disconnection event of an audio device (such as HDMI, USB headphones, Bluetooth, 3.5mm headphones, or the device's built-in speaker), it records the user's final selected output path in real time and simultaneously collects contextual information at that moment, such as the current time period, the task type mapped by the foreground application, and the activation status of the main and secondary screens. Each record is encoded into a feature vector with a fixed format, where the feature dimensions correspond to specific context fields, and the label is the audio output path confirmed by the user. In the background, the system uses a lightweight interpretable model (such as a decision tree or gradient boosting tree) to perform online incremental learning on the continuously accumulated training samples, generating several "feature conditions → output path" rules. Simultaneously, it calculates indicators such as coverage, purity, and prediction probability for each rule and converts them into confidence values. This forms the user audio behavior model required for subsequent real-time inference, achieving a dynamic and interpretable abstraction of user preferences.
[0053] Step S102: Obtain the task type of the currently running task in the foreground of the system.
[0054] In this embodiment, once the model has reached a certain scale, the system enters the operational phase. Whenever a user launches or switches a foreground application, the task recognition module reads the package name or Activity information and looks up the task type in a table, such as "media playback," "video conferencing," "voice interaction," or "game." The task type and device concurrency capabilities directly affect the listening experience requirements: for example, meeting tasks prioritize privacy and echo cancellation, tending to use headphones; while screen mirroring typically requires both video and audio to be output to an HDMI secondary screen.
[0055] Step S103: Determine the target audio output path based on the user audio behavior model and the task type.
[0056] In this embodiment, the task identification result is then combined with the aforementioned behavior model: the system first calculates the matching confidence of the current scene with each rule according to the model rules, and then weights it according to the output priority sequence corresponding to the task type to form a comprehensive scoring table. The path with the highest score and meeting hardware availability requirements is determined as the target audio output path; if multiple paths have similar scores and the hardware supports concurrent output, two or more paths are selected simultaneously, and their respective volume gain and buffer delay are automatically allocated according to task weight and device bandwidth.
[0057] Step S104: Control the audio output path to switch to the target audio output path through the audio policy service module.
[0058] In this embodiment, after the decision is made, the audio strategy execution module takes over the switching action. The module first calls system interfaces such as `setPreferredDevice()` or `setDevicePortConfig()` to bind the current audio stream to the target output device node; for non-target channels, it sets them to mute or standby to avoid contention for focus. When concurrent output is required, the module establishes an independent volume control channel, thread priority, and buffer for each channel, and calculates latency compensation parameters to ensure that multiple signals are synchronized at the auditory level. Throughout the switching process, the system performs fade-in / fade-out curves on the output gain to prevent instantaneous popping sounds, and only calls back the switching completion event to the application layer after the audio channel has completely stabilized, thus meeting the seamless switching requirements of real-time interactive services.
[0059] This application proposes a control method that simultaneously considers long-term user preferences and immediate task requirements, and achieves automated audio path switching by jointly deciding the audio output path based on the user's audio output behavior model and the current task type, and dynamically switching the path by the audio strategy service module. This avoids erroneous output and frequent manual intervention under the fixed priority strategy of the system, thereby significantly improving the audio adaptation capability and user experience of dual-screen display devices in complex scenarios.
[0060] In some optional implementations of this embodiment, the steps of constructing a user audio behavior model based on the user's selection behavior of audio output paths under different audio device connection states include:
[0061] When an audio device experiences a connection, disconnection, or priority change event, the audio output path finally confirmed by the user is recorded. The audio device includes, but is not limited to, HDMI, USB headphones, 3.5mm headphones, Bluetooth headphones, and speakers.
[0062] When recording the audio output path selected by the user, context data related to the selection is collected synchronously, and the context data is concatenated according to the predefined field order to generate a feature vector for training the behavior model. The context data includes the time period in which the current selection occurred, the task type of the running task, the on / off status of the main screen and the secondary screen, and the optional network connection status.
[0063] The feature vectors are used as input samples to train a lightweight interpretable model based on decision trees or gradient boosting trees, and audio output preference rules are generated. Match confidence is calculated for each preference rule.
[0064] In this embodiment, after detecting events such as plugging / unplugging of HDMI, USB headphones, 3.5mm headphones, Bluetooth headphones, and speakers, handshake failures, or policy priority changes, the system uses the user's final confirmed output path as a label for supervised learning. Simultaneously, within a millisecond-level time window, it reads multi-dimensional context: the current precise time period (encoded by hour, time period, or weekday / rest day), the foreground task type (business scenario mapped by package name), the on / off or off status of the main and secondary screens, and optional system states such as network connectivity, channel bandwidth, or battery level. The system predefines the field order and type length, concatenating these discrete or continuous features into a vector in sequence. To ensure the model is lightweight and interpretable, one-hot encoding is used for categorical features, and discretization or normalization is performed on numerical features. Subsequently, the background incremental learning thread feeds the newly generated feature vectors and labels into a local lightweight machine learning library (such as LightGBM or an interpretable CART decision tree) for training, obtaining several human-readable rules of "feature combination → output path", and calculating the matching confidence of each rule, which is a combination of coverage, information gain and leaf node prediction probability, laying the data and algorithm foundation for subsequent real-time inference.
[0065] This application records user selection results when the audio device state changes and simultaneously collects multi-dimensional contextual data to generate structured feature vectors. Then, it uses a lightweight interpretable model to train audio output preference rules, resulting in a modeling mechanism that can continuously learn user behavior and mine preference patterns. This enables the system to predict the user's expected output path with higher confidence in subsequent decisions.
[0066] In some optional implementations of this embodiment, the update of the above-mentioned audio output preference rule is implemented using an online incremental learning method, and includes:
[0067] When the confidence level of a new sample matching an existing rule is lower than a preset first threshold, a rule update process is triggered to introduce new branch conditions.
[0068] When a user rejects the audio output path automatically selected by the system N times consecutively (N≥1), the confidence of the rule corresponding to the scenario is reduced, and only the decision branch containing the rule is updated locally by incremental learning to correct the prediction result.
[0069] After a rule is updated, a time decay weight is applied to each rule based on its most recent effective time to prevent outdated preferences from dominating new routing decisions.
[0070] In this embodiment, online incremental learning ensures that the model evolves synchronously with user behavior. The system first sets a "first confidence threshold" to measure the fit of new samples with existing rules. If a new sample falls into a leaf node of a rule but lacks sufficient support, a local re-splitting is triggered, adding new branch conditions to that leaf node to maintain the generalization of the rule tree. When a user actively rejects the system's recommended output path N times consecutively (configurable by system parameters, default is 3 times), the system marks these N samples as "negative feedback," immediately lowers the confidence of the rule, increases the weight of the negative feedback samples, and performs local retraining only within that leaf node and its upstream parent node, equivalent to rapid pruning and growth of the "subtree." The global model structure thus remains stable and will not be retrained as a whole due to a change in a single scenario. Finally, to prevent outdated scenarios from occupying high weights for a long time, the system maintains a "most recent effective time" stamp in the rule base and multiplies it by a time decay factor in the scheduled maintenance task, so that the confidence of less popular rules naturally decreases over time, achieving continuous adaptation to the user's latest preferences.
[0071] This application updates audio output preference rules by adopting an online incremental learning approach and makes local adjustments to the decision branch in scenarios where users reject the data or the confidence level of sample matching is low. Combined with the rule time decay mechanism, a dynamic evolution strategy is obtained that enables the model to continuously self-optimize, adapt to changes in the scenario, and avoid the solidification of historical preferences. This makes the audio path recommendation more in line with the user's current habits and effectively improves the robustness and practicality of the model.
[0072] In some optional implementations of this embodiment, the step of obtaining the task type of the currently running foreground task specifically includes:
[0073] The detection system runs applications in the foreground and maps them to a preset set of task types, including but not limited to media playback, video conferencing, voice interaction, games, and system prompts;
[0074] For different task types, query the task audio strategy table to obtain the priority sequence of the target audio output path corresponding to that task type.
[0075] In this embodiment, the task identification logic provides a second decision dimension besides user preferences. Each time an Activity switches, the system obtains the foreground package name and categorizes it into task types such as "media playback, video conferencing, voice interaction, games, or system prompts" using a static mapping table or machine learning classification model. It then further retrieves the output path priority sequence for that task type from the "task audio strategy table." For example, in a video conferencing scenario, headphones are set to the highest priority to obtain a private and stable echo-suppressed path; media playback prioritizes output to HDMI to achieve audio-visual synchronization. This forms the "expected path sequence" on the task side, which, together with the "preference path and confidence level" output by the user behavior model, participates in the next step of comprehensive scoring.
[0076] This application monitors the foreground application and maps it to a set of task types, then queries the task audio strategy table to obtain the priority output path sequence, thus obtaining a judgment mechanism that can assign different audio device path priorities in real time according to the current task content. This enables the system to accurately output to the device that best suits the business scenario in task-oriented scenarios (such as meetings, media playback, etc.), thereby enhancing the scenario adaptability and task coordination capabilities of path selection.
[0077] In some optional implementations of this embodiment, if multiple available audio devices exist and support concurrent output, then after the step of querying the task audio strategy table to obtain the priority sequence of the target audio output path corresponding to the task type for different task types, the method further includes:
[0078] Based on the audio requirements corresponding to the task type, assign initial weights to each candidate output path;
[0079] Based on the bandwidth capacity of each channel, the current system load, and whether it occupies exclusive audio resources, the volume gain, thread priority, and buffer size of each channel are dynamically adjusted.
[0080] Delay compensation parameters are set for each channel and synchronous refresh control is performed to ensure time alignment and stable sound quality of multi-channel output.
[0081] In this embodiment, when both the hardware and the system support concurrent output (e.g., multi-channel PCM or HDMI+I2S parallel processing in a high-end SoC), the system will enter weighted scheduling after the task policy table step. The scheduler first assigns initial scores to candidate channels based on the priority built into the task type; then it monitors the bandwidth metrics exposed by the audio DSP or APM (Audio Policy Manager) and the CPU power management status, and lowers the gain of channels with low bandwidth or limited thread priority to prevent audio underrun. The system also determines thread priority based on whether the output device is in "exclusive mode" to ensure the real-time performance of critical channels. To avoid "echo" or "ghosting" caused by asynchronous multi-channel output, the scheduler calls the PCM or AudioTrack interface to query the buffer depth of each channel before enabling concurrent output, calculates the time difference interpolation based on the sampling rate and frame length, writes it to the delay compensation register, and adds timestamp refresh logic in subsequent playback loops to achieve channel synchronization from the system's underlying layer.
[0082] This application obtains an advanced audio scheduling mechanism that supports multi-channel concurrency, on-demand scheduling of output resources, and achieves latency compensation and synchronous control by assigning output weights to concurrent audio devices and dynamically adjusting the volume, thread priority, and buffering strategy of each channel in combination with factors such as task importance, channel bandwidth, and system load. This fully utilizes the multi-channel capabilities of high-performance devices and improves the concurrent output sound quality and response speed of the system.
[0083] In some optional implementations of this embodiment, the step of determining the target audio output path based on the user audio behavior model and the task type, when the target output path obtained based on the user audio behavior model is inconsistent with the target output path obtained based on the task type priority sequence, further includes:
[0084] Collect environmental perception data, including ambient light intensity, screen folding angle, and the user's recent interaction status;
[0085] The audio output path is finally determined according to the preset conflict resolution rules, which include at least the following: when the ambient light intensity is lower than the threshold L, the headphone output is given priority; when the screen is at the presentation unfolded angle and the HDMI connection is detected to be valid, the HDMI output is given priority; when the user is detected to be still and without interactive operation for a set duration T, the current path is kept unchanged.
[0086] In this embodiment, a conflict resolution mechanism is used to balance the inconsistency between "long-term preferences" and "immediate tasks." When the behavioral model suggests using HDMI but the meeting task requires headphones, or vice versa, the system calls the HAL sensor to read the ambient light. If insufficient brightness is detected, such as in a dark room after the projector is turned off, the system determines that the meeting has ended and prioritizes headphone output. If the distance / gravity sensor indicates that the terminal is at a presentation tilt angle and the HDMI physical link is still outputting EDID signals, the system tends to continue along the HDMI path. Static detection is achieved by statistically analyzing the intervals of touch and button events. If the user leaves the room, the system maintains the current route to avoid frequent switching. The above rules are backward compatible with different hardware and service requirements through configurable thresholds such as L and T.
[0087] This application introduces environmental perception data when conflicts arise between behavior models and task recommendations, and applies adjudication rules based on dimensions such as lighting, screen status, and user inactivity to obtain a multi-factor conflict resolution mechanism that integrates perception intelligence. This enables the system to make reasonable judgments even when user intentions are ambiguous or preferences are unstable, effectively improving decision-making accuracy and automation, and enhancing the system's practical stability in complex human-computer interaction environments.
[0088] In some optional implementations of this embodiment, the step of controlling the audio output path to switch to the target audio output path through the audio policy service module specifically includes:
[0089] Call the audio policy service interface to bind the audio stream to the target output device node, and put the output devices corresponding to non-target paths into a mute or standby state;
[0090] During the switching process, fade-in / fade-out control is performed according to the buffer structure of the target path to prevent transient pops;
[0091] In concurrent output scenarios, each channel maintains an independent volume control channel, buffer refresh cycle, and synchronization flag to ensure continuous synchronization and distortion-free output of multiple channels after switching.
[0092] In this embodiment, the routing execution phase focuses on "accurate, stable, and seamless switching." The system first calls the AudioPolicy API to bind the stream to the target port, then marks the data stream to the non-target port as inactive and triggers a mute. Subsequently, it sets the fade-in / fade-out curve (e.g., a 30ms linear ramp) according to the target device's loop buffer parameters to avoid popping sounds or sudden volume changes during transitions. If concurrency is used, the system maintains the channel-level volume, independent AudioTrack buffer refresh cycle, and synchronization flags separately, and calibrates the time base in each frame rendering cycle of the playback thread to ensure that the dual-channel audio is always within an audible synchronization error of ±5ms. After execution, the system calls back the "routechanged" event to the upper layer, allowing applications to refresh the UI or execute subsequent business processes.
[0093] This application controls audio stream rebinding by calling the audio strategy interface, and combines fade-in / fade-out anti-pop sound, independent channel control and synchronous refresh mechanism to obtain an audio channel switching method with high precision execution capability. It can realize a smooth, low-latency and distortion-free audio channel switching process in single-channel or concurrent scenarios, effectively improving the system audio response quality and user perception continuity.
[0094] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).
[0095] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0096] Further reference Figure 2 As a response to the above Figure 1The implementation of the method shown in this application provides an embodiment of a dynamic control system for the audio output path of a multi-screen display device. This system embodiment is similar to... Figure 1 Corresponding to the method embodiments shown, the system can be specifically applied to various electronic devices.
[0097] like Figure 2 As shown, the audio output path dynamic control system 200 for multi-screen display devices described in this embodiment includes: a construction module 201, an acquisition module 202, a determination module 203, and a switching module 204. Wherein:
[0098] Module 201 is used to build a user audio behavior model based on the user's selection behavior of audio output path under different audio device connection states;
[0099] Module 202 is used to obtain the task type of the currently running foreground task in the system;
[0100] The determining module 203 is used to determine the target audio output path based on the user audio behavior model and the task type;
[0101] The switching module 204 is used to control the audio output path to switch to the target audio output path through the audio policy service module.
[0102] The audio output path dynamic control system for multi-screen display devices provided in this embodiment of the invention can realize all the processes of the audio output path dynamic control method for multi-screen display devices in the above embodiments. The functions and technical effects of each module in the device are the same as the functions and technical effects of the audio output path dynamic control method for multi-screen display devices in the above embodiments, and will not be repeated here.
[0103] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 3 , Figure 3 This is a basic structural block diagram of the computer device in this embodiment.
[0104] The computer device 3 includes a memory 31, a processor 32, and a network interface 33 that are interconnected via a system bus. It should be noted that only the computer device 3 with components 31-33 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.
[0105] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.
[0106] The memory 31 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 31 may be an internal storage unit of the computer device 3, such as the hard disk or memory of the computer device 3. In other embodiments, the memory 31 may also be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Of course, the memory 31 may also include both the internal storage unit and its external storage device of the computer device 3. In this embodiment, the memory 31 is typically used to store the operating system and various application software installed on the computer device 3, such as computer-readable instructions for a dynamic control method of audio output path of a multi-screen display device. In addition, the memory 31 can also be used to temporarily store various types of data that have been output or will be output.
[0107] In some embodiments, the processor 32 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 32 is typically used to control the overall operation of the computer device 3. In this embodiment, the processor 32 is used to execute computer-readable instructions stored in the memory 31 or to process data, such as executing computer-readable instructions for the dynamic control method of the audio output path of the multi-screen display device.
[0108] The network interface 33 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 3 and other electronic devices.
[0109] The computer device provided in this application determines the audio output path based on the user's audio output behavior model and the current task type, and the audio policy service module dynamically switches the path. This results in a control method that can simultaneously consider the user's long-term preferences and the immediate needs of the task, and achieve automated audio path switching. This avoids erroneous output and frequent manual intervention under the system's fixed priority strategy, thereby significantly improving the audio adaptation capability and user experience of dual-screen display devices in complex scenarios.
[0110] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the above-described dynamic control method for the audio output path of a multi-screen display device.
[0111] The computer-readable storage medium provided in this application determines the audio output path based on the user's audio output behavior model and the current task type, and the audio policy service module dynamically switches the path. This results in a control method that can simultaneously consider the user's long-term preferences and the immediate needs of the task, and achieve automated audio path switching. This avoids erroneous output and frequent manual intervention under the system's fixed priority strategy, thereby significantly improving the audio adaptation capability and user experience of dual-screen display devices in complex scenarios.
[0112] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. 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 is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0113] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A method for dynamically controlling the audio output path of a multi-screen display device, characterized in that, Includes the following steps: A user audio behavior model is constructed based on the user's selection behavior of audio output path under different audio device connection states; Get the task type of the currently running tasks in the system foreground; Based on the user audio behavior model and the task type, determine the target audio output path; The audio output path is switched to the target audio output path by controlling the audio policy service module.
2. The method for dynamic control of audio output path in a multi-screen display device according to claim 1, characterized in that, The steps for constructing a user audio behavior model based on the user's selection behavior of audio output paths under different audio device connection states include: When an audio device experiences a connection, disconnection, or priority change event, the audio output path finally confirmed by the user is recorded. The audio device includes, but is not limited to, HDMI, USB headphones, 3.5mm headphones, Bluetooth headphones, and speakers. When recording the audio output path selected by the user, context data related to the selection is collected synchronously, and the context data is concatenated according to the predefined field order to generate a feature vector for training the behavior model. The context data includes the time period in which the current selection occurred, the task type of the running task, the on / off status of the main screen and the secondary screen, and the optional network connection status. The feature vectors are used as input samples to train a lightweight interpretable model based on decision trees or gradient boosting trees, and audio output preference rules are generated. Match confidence is calculated for each preference rule.
3. The method for dynamic control of audio output path in a multi-screen display device according to claim 2, characterized in that, The update of the audio output preference rules is achieved through online incremental learning, and includes: When the confidence level of a new sample matching an existing rule is lower than a preset first threshold, a rule update process is triggered to introduce new branch conditions. When a user rejects the audio output path automatically selected by the system N times consecutively (N≥1), the confidence of the rule corresponding to the scenario is reduced, and only the decision branch containing the rule is updated locally by incremental learning to correct the prediction result. After a rule is updated, a time decay weight is applied to each rule based on its most recent effective time to prevent outdated preferences from dominating new routing decisions.
4. The method for dynamic control of audio output path in a multi-screen display device according to claim 1, characterized in that, The step of obtaining the task type of the currently running foreground task specifically includes: The detection system runs applications in the foreground and maps them to a preset set of task types, including but not limited to media playback, video conferencing, voice interaction, games, and system prompts; For different task types, query the task audio strategy table to obtain the priority sequence of the target audio output path corresponding to that task type.
5. The method for dynamic control of audio output path in a multi-screen display device according to claim 4, characterized in that, If multiple available audio devices exist and support concurrent output, then after the step of querying the task audio strategy table to obtain the priority sequence of the target audio output path corresponding to the task type for different task types, the method further includes: Based on the audio requirements corresponding to the task type, assign initial weights to each candidate output path; Based on the bandwidth capacity of each channel, the current system load, and whether it occupies exclusive audio resources, the volume gain, thread priority, and buffer size of each channel are dynamically adjusted. Delay compensation parameters are set for each channel and synchronous refresh control is performed to ensure time alignment and stable sound quality of multi-channel output.
6. The method for dynamic control of audio output path in a multi-screen display device according to claim 1, characterized in that, In the step of determining the target audio output path based on the user audio behavior model and the task type, when the target output path obtained based on the user audio behavior model is inconsistent with the target output path obtained based on the task type priority sequence, the method further includes: Collect environmental perception data, including ambient light intensity, screen folding angle, and the user's recent interaction status; The audio output path is finally determined according to the preset conflict resolution rules, which include at least the following: when the ambient light intensity is lower than the threshold L, the headphone output is given priority; when the screen is at the presentation unfolded angle and the HDMI connection is detected to be valid, the HDMI output is given priority; when the user is detected to be still and without interactive operation for a set duration T, the current path is kept unchanged.
7. The method for dynamic control of audio output path in a multi-screen display device according to claim 1, characterized in that, The step of controlling the audio output path to switch to the target audio output path through the audio policy service module specifically includes: Call the audio policy service interface to bind the audio stream to the target output device node, and put the output devices corresponding to non-target paths into a mute or standby state; During the switching process, fade-in / fade-out control is performed according to the buffer structure of the target path to prevent transient pops; In concurrent output scenarios, each channel maintains an independent volume control channel, buffer refresh cycle, and synchronization flag to ensure continuous synchronization and distortion-free output of multiple channels after switching.
8. A dynamic control system for the audio output path of a multi-screen display device, characterized in that, include: The building module is used to construct a user audio behavior model based on the user's selection behavior of audio output path under different audio device connection states; The acquisition module is used to obtain the task type of the currently running foreground tasks in the system. The determination module is used to determine the target audio output path based on the user audio behavior model and the task type; The switching module is used to control the audio output path to switch to the target audio output path through the audio policy service module.
9. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the dynamic control method for the audio output path of a multi-screen display device as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the dynamic control method for the audio output path of a multi-screen display device as described in any one of claims 1 to 7.