Methods for scheduling audio playback resources, controllers, and vehicles

Abstract

This application discloses a method, controller, and vehicle for scheduling audio playback resources, belonging to the field of vehicle control technology. The method includes: receiving a Bluetooth audio playback request from a first application, the Bluetooth audio playback request being used to request audio playback resources; detecting the occupancy status of audio playback resources based on the Bluetooth audio playback request; and, if the audio playback resources are occupied, determining a scheduling strategy based on the application type of the second application occupying the audio playback resources, and scheduling the audio playback resources according to the scheduling strategy. This achieves unified monitoring and management of audio playback resources running simultaneously with multiple protocols and applications, enabling resource scheduling in multi-interconnected application scenarios, and improving the overall human-machine interaction experience of the vehicle system.

Description

Technical Field

[0001] This application relates to the field of vehicle information management technology, and in particular to a method for scheduling audio playback resources, a controller, and a vehicle. Background Technology

[0002] As the functions of in-vehicle infotainment systems become increasingly sophisticated, these systems typically need to support multiple Bluetooth protocols and interconnected applications, all of which involve the use of Bluetooth resources.

[0003] When multiple connected applications are running simultaneously in the vehicle's infotainment system, the relevant technologies independently monitor and manage Bluetooth resources for the Bluetooth audio transmission protocol when scheduling Bluetooth resources, lacking a unified resource scheduling mechanism for multiple protocols and applications running simultaneously. Summary of the Invention

[0004] This application provides a method, controller, and vehicle for scheduling audio playback resources, which can be used for unified resource scheduling when multiple protocols and applications run simultaneously. The technical solution is as follows: On one hand, embodiments of this application provide a method for scheduling audio playback resources, the method comprising: Receive a Bluetooth audio playback request from a first application, wherein the Bluetooth audio playback request is used to request audio playback resources; Based on the Bluetooth audio playback request, the occupancy status of the audio playback resources is detected; If the audio playback resource is occupied, a scheduling strategy is determined based on the application type of the second application occupying the audio playback resource, and the audio playback resource is scheduled according to the scheduling strategy.

[0005] On the other hand, an audio playback resource scheduling device is provided, the device comprising: A receiving module is used to receive a Bluetooth audio playback request from a first application, wherein the Bluetooth audio playback request is used to request audio playback resources; The detection module is used to detect the occupancy status of the audio playback resources based on the Bluetooth audio playback request; The determining module is configured to, when the audio playback resource is occupied, determine a scheduling strategy based on the application type of the second application occupying the audio playback resource, and schedule the audio playback resource according to the scheduling strategy.

[0006] On the other hand, a vehicle controller is also provided, the vehicle controller including a processor coupled to a memory, the memory being used to store scheduling instructions for audio playback resources, the scheduling instructions being executed by the processor to implement any of the above-described audio playback resource scheduling methods.

[0007] On the other hand, a vehicle is also provided, the vehicle including the vehicle controller described above, the vehicle controller being configured to execute any of the above-described audio playback resource scheduling methods to schedule audio playback resources for applications installed on the vehicle.

[0008] The technical solution provided in this application brings at least the following beneficial effects: Upon receiving a Bluetooth audio playback request from a first application requesting audio playback resources, if the audio playback resources are already occupied by a second application, this application determines a scheduling strategy based on the application type of the second application and schedules the audio playback resources according to the scheduling strategy. This enables unified monitoring and management of audio playback resources running simultaneously with multiple protocols and applications, achieving resource scheduling in multi-interconnected application scenarios and improving the overall human-machine interaction experience of the in-vehicle system. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application; Figure 2 This is a flowchart of an audio playback resource scheduling method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an update of a resource usage database provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the determination of audio playback resource occupancy according to an embodiment of this application; Figure 5 This is a flowchart illustrating the scheduling of audio playback resources provided in an embodiment of this application; Figure 6 This is a flowchart illustrating the process of restoring audio playback, as provided in an embodiment of this application. Figure 7 This is a system architecture diagram provided in an embodiment of this application; Figure 8 This is a system interaction timing diagram provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an audio playback resource scheduling device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0012] This application provides a method for scheduling audio playback resources. Please refer to [link / reference]. Figure 1 The diagram illustrates the implementation environment of the method provided in this application embodiment. The implementation environment includes: CDC (Cockpit Domain Controller) 11, first application 12, second application 13, HMI (Human-Machine Interface) 14, and power amplifier and speaker 15.

[0013] Optionally, the first application 12 can be an in-vehicle Bluetooth music application, an in-vehicle voice assistant, an in-vehicle connectivity application, an in-vehicle Bluetooth call application, a TTS (Text-to-Speech) broadcast application, an ADAS (Advanced Driving Assistance System) application, or an in-vehicle navigation broadcast application; the first application 12 is used to send a Bluetooth audio playback request to the CDC11. The Bluetooth audio playback request is used to request audio playback resources; the first application 12 is also used to receive scheduling instructions sent by the CDC11, and perform at least one of the following operations according to the scheduling instructions: output audio data to the audio router to achieve music playback, pause current playback, suspend audio output, release audio playback resources, or resume audio output.

[0014] For example, the second application 13 can be an application different from the first application 12, such as an in-vehicle Bluetooth music application, an in-vehicle voice assistant, an in-vehicle connectivity application, an in-vehicle Bluetooth call application, a TTS broadcast application, an ADAS, or an in-vehicle navigation broadcast application; the second application 13 is used to receive scheduling instructions sent by CDC11 and perform at least one of the following operations according to the scheduling instructions: output audio data to the audio router to realize music playback, pause the current playback, suspend audio output, release audio playback resources, or resume audio output.

[0015] Optionally, HMI14 is used to receive instructions from CDC11 and output interactive prompts, wherein the interactive prompts are used to prompt the user to select the application for scheduling audio playback resources in the first application 12 and the second application 13; HMI14 is also used to receive instructions from CDC11 and display the current playback status and the occupancy information of audio playback resources and applications. Exemplarily, the power amplifier and speaker 15 are used to receive audio data processed by CDC11 and convert the audio data into sound signals for playback. CDC11, the first application 12, the second application 13, HMI14, and the power amplifier and speaker 15 establish a communication connection through a wired or wireless network.

[0016] Based on the above Figure 1 The implementation environment shown in this application provides a method for scheduling audio playback resources, such as... Figure 2 As shown, taking the application of this method to CDC as an example, the method includes steps 201-203.

[0017] In step 201, the CDC receives a Bluetooth audio playback request from the first application, which is used to request audio playback resources.

[0018] In one possible implementation, the first application can be an in-vehicle Bluetooth music application, an in-vehicle voice assistant, an in-vehicle connectivity application, an in-vehicle Bluetooth calling application, a TTS (Text-to-Speech) application, an ADAS (Advanced Driver Assistance System) application, or an in-vehicle navigation application. Among these, the in-vehicle connectivity application supports calling functionality in addition to music playback.

[0019] Optionally, the Bluetooth audio playback request is used to request audio playback resources, including requesting to occupy the A2DP (Advanced Audio Distribution Profile) audio output channel or the HFP (Hands-Free Profile) audio output channel, wherein the HFP audio output channel is an audio output channel dedicated to calls.

[0020] In one possible implementation, the CDC receives a Bluetooth audio playback request from a first application, including: the CDC receiving a Bluetooth audio playback request from an in-vehicle Bluetooth music application; receiving a Bluetooth audio playback request from an in-vehicle voice assistant; receiving a Bluetooth audio playback request from an in-vehicle connectivity application; receiving a Bluetooth audio playback request from a TTS (Text-to-Speech) application; receiving a Bluetooth audio playback request from an ADAS (Advanced Driver Assistance System); or receiving a Bluetooth audio playback request from an in-vehicle navigation application.

[0021] Since the first application can be any of the following: in-vehicle Bluetooth music application, in-vehicle voice assistant, in-vehicle connectivity application, in-vehicle Bluetooth calling application, TTS broadcast application, ADAS, or in-vehicle navigation broadcast application, by receiving Bluetooth audio playback requests from the first application that requests audio playback resources, the system can uniformly receive Bluetooth audio playback requests initiated by different types of first applications. This ensures comprehensive and unified identification of user or vehicle audio playback requests in a timely manner, facilitating subsequent detection of audio playback resource occupancy based on received Bluetooth audio playback requests, determination of scheduling strategies based on the application type of the second application occupying audio playback resources, and scheduling of audio playback resources according to the scheduling strategy. This improves the real-time response capability to vehicle audio playback, thereby improving the overall human-machine interaction experience of the in-vehicle system. Furthermore, because the first application covers various software functional entities that may initiate audio playback requests while driving, this solution is applicable in multiple scenarios, enhancing the versatility and scalability of the technical solution.

[0022] In step 202, the CDC detects the occupancy of audio playback resources based on the Bluetooth audio playback request.

[0023] For example, the occupancy status of audio playback resources includes whether the audio playback resources are occupied or not. Optionally, the CDC detects the occupancy status of audio playback resources based on Bluetooth audio playback requests, including: obtaining at least one of the Bluetooth protocol connection status or the audio output channel allocation status based on the Bluetooth audio playback request; and determining that the audio playback resources are occupied if the Bluetooth protocol connection status is a streaming connection status or the audio output channel allocation status is allocated.

[0024] In one possible implementation, obtaining at least one of the Bluetooth protocol connection status or the audio output channel allocation status based on the Bluetooth audio playback request includes: the CDC collects at least one of the A2DP Profile status field of the Bluetooth protocol stack or the A2DP output channel allocation status at preset intervals through the MON (Monitoring Module). The A2DP output channel allocation status includes whether the A2DP output channel has been allocated or the A2DP output channel has been allocated.

[0025] For example, after acquiring at least one of the A2DP Profile status field of the Bluetooth protocol stack or the allocation status of the A2DP output channel, MON stores the acquired information in the resource occupancy database; DET (DetectionModule) reads the acquired information from the resource occupancy database and analyzes it, including: if DET identifies that the A2DP Profile status field is in the Streaming state, it indicates that the Bluetooth protocol connection status is a streaming connection state; if DET identifies that the A2DP Profile status field is in the Idle or Paused state, it indicates that the Bluetooth protocol connection status is a non-streaming connection state.

[0026] Optionally, after obtaining the Bluetooth connection status, if the Bluetooth connection status is a streaming connection or the audio output channel allocation status is allocated, the CDC determines that the audio playback resource is occupied; if the Bluetooth connection status is not a streaming connection and the audio output channel allocation status is unallocated, it determines that the audio playback resource is not occupied. In one possible implementation, the preset duration can be set according to the verification settings; the aforementioned MON and DET can be software function modules of the CDC.

[0027] By combining the A2DP Profile status field and the allocation status of the audio output channel, the system determines whether audio playback resources are occupied, avoiding misjudgments that may occur when relying on a single parameter and improving the accuracy of this determination. The CDC collects at least one of the A2DP Profile status field or the A2DP output channel allocation status from the Bluetooth protocol stack at preset intervals via the MON, and periodically stores the collected information in a resource occupancy database. The DET can directly obtain real-time updated information from this database to determine whether audio playback resources are occupied, ensuring the real-time nature and reliability of the parameters used for this determination.

[0028] In step 203, when audio playback resources are occupied, the CDC determines the scheduling strategy based on the application type of the second application occupying the audio playback resources, and schedules the audio playback resources according to the scheduling strategy.

[0029] For example, after obtaining the occupancy status of audio playback resources, if the audio playback resources are occupied, the CDC determines the scheduling strategy based on the application type of the second application occupying the audio playback resources. Optionally, the second application occupying the audio playback resources can be an application different from the first application, such as an in-vehicle Bluetooth music application, an in-vehicle voice assistant, an in-vehicle connectivity application, an in-vehicle Bluetooth call application, a TTS broadcast application, an ADAS application, or an in-vehicle navigation broadcast application.

[0030] In one possible implementation, the in-vehicle Bluetooth music application, in-vehicle voice assistant, in-vehicle connectivity application, TTS broadcast application, ADAS, and in-vehicle navigation broadcast application are classified as non-call applications; the in-vehicle Bluetooth call application is classified as a call application. For example, among the non-call applications, the ADAS and TTS broadcast applications are classified as emergency alert applications; the Bluetooth music application and the in-vehicle voice assistant are classified as user-explicit applications; the in-vehicle navigation broadcast application is classified as an overlay application; and the in-vehicle connectivity application is classified as a media application.

[0031] Optionally, the CDC determines the scheduling strategy based on the application type of the second application occupying the audio playback resources, including: determining the priority order of the first application and the second application based on the application type of the second application occupying the audio playback resources; and determining the scheduling strategy based on the priority order of the first application and the second application, with different priority orders corresponding to different scheduling strategies.

[0032] For example, CDC determines the priority of the first application based on its type; determines the priority of the second application based on its type; and then compares the priorities of the first and second applications to determine their priority order. In one possible implementation, the priority order can be determined based on a check setting, for example, according to a sorting standard that decreases in priority from call applications, emergency alert applications, user-display applications, overlay applications, to media applications.

[0033] Optionally, after determining the priority order of the first application and the second application, the CDC determines a scheduling strategy based on the priority order of the first application and the second application, including: if the priority order is that the first application has a higher priority than the second application, and the application type of the second application is a non-call application, the scheduling strategy is to suspend the second application's occupation of audio playback resources and schedule the audio playback resources to the first application; if the priority order is that the first application has a higher priority than the second application, and the application type of the second application is a call application, or if the priority order is that the first application has a lower priority than the second application, the scheduling strategy is to schedule the audio playback resources to the first application after the second application has finished running.

[0034] In one possible implementation, if the priority order is that the first application has a higher priority than the second application, and the application type of the second application is a non-call application and a non-overlay application, the CDC determines the scheduling strategy to temporarily release the audio playback resources occupied by the second application and schedule the released audio playback resources to the first application.

[0035] For example, if the priority order is that the first application has a higher priority than the second application and the second application is a call application, or if the priority order is that the first application has a lower priority than the second application and the second application is a non-overlapping application, the CDC determines the scheduling strategy to continue to maintain the second application's occupation of audio playback resources, release the audio playback resources occupied by the second application after the second application finishes running, and schedule the audio playback resources to the first application.

[0036] Optionally, the scheduling strategy is determined based on the application type of the second application occupying the audio playback resources, including: if the application type of the second application is an overlay application, enabling a parallel sub-channel for the audio playback resources, and realizing the sharing of audio playback resources between the first application and the second application through the parallel sub-channel.

[0037] In one possible implementation, if the second application is an overlay application and the vehicle audio playback-related hardware and systems support multi-channel parallelism, the CDC determines the scheduling strategy to enable a parallel sub-channel for audio playback resources. This parallel sub-channel enables the sharing of audio playback resources between the first and second applications. For example, when sharing audio playback resources between the first and second applications via a parallel sub-channel, the audio playback volume of the first and second applications needs to be set according to a volume coordination standard. This volume coordination standard can be pre-set based on verification. Whether the vehicle audio playback-related hardware and systems support multi-channel parallelism can be pre-determined and stored in the CDC.

[0038] Optionally, after determining the scheduling strategy, the CDC schedules audio playback resources according to the scheduling strategy, including: if the scheduling strategy is to schedule audio playback resources to the first application after the second application finishes running, the audio channel of the first application is preloaded before the second application finishes running, and the preloaded audio channel is switched after the second application finishes running, so that the first application occupies the audio playback resources.

[0039] In one possible implementation, if the scheduling strategy is to allocate audio playback resources to the first application only after the second application has finished running, a preset duration is set before the second application finishes running. The CDC (Digital Channel Control) preloads the audio channel and audio route of the first application, pre-establishes a mapping relationship between the first application and the audio playback resources in the audio route, and marks the mapping relationship as inactive. Upon detecting that the second application has finished running, the CDC marks the mapping relationship between the first application and the audio playback resources as active and switches the audio output path from the audio channel currently occupied by the second application to the audio channel preloaded by the first application, thereby switching the owner of the audio playback resources from the second application to the first application. The audio route then outputs the audio data corresponding to the first application to the amplifier and speakers to achieve audio playback. The preset duration can be set according to the verification settings.

[0040] For example, if the scheduling strategy is to suspend the second application's use of audio playback resources and schedule the audio playback resources to the first application, the following steps are taken: the CDC stores the playback progress of the second application; the A2DP audio output channel is unbound from the second application, making the audio output channel available for allocation; the A2DP audio output channel is then allocated to the first application, and the audio router outputs the audio data corresponding to the first application to the power amplifier and speakers to achieve audio playback.

[0041] Optionally, when the scheduling strategy is to suspend the second application's use of audio playback resources and schedule the audio playback resources to the first application, after the first application finishes running, the second application's use of audio playback resources is restored. This includes: after the CDC detects that the first application has finished running, the CDC searches for the most recently suspended second application; unbinds the A2DP audio output channel from the first application, making the audio output channel available for allocation; then rebinds the A2DP audio output channel to the second application, and then the audio router outputs the audio data of the second application from the last playback record point to the power amplifier and speakers, thereby restoring audio playback.

[0042] In one possible implementation, after scheduling audio playback resources according to the scheduling strategy, if the scheduling strategy fails to schedule the audio playback resources, an interactive prompt is output to prompt the user to select the application to schedule the audio playback resources in the first application and the second application; the selection result is obtained, and the audio playback resources are scheduled based on the selection result.

[0043] For example, after scheduling audio playback resources according to the scheduling strategy, if a link anomaly, audio playback failure, or conflict that cannot be automatically handled results in unsuccessful scheduling of audio playback resources, the CDC automatically performs a reconnection. If the reconnection fails, playback reverts to the audio from the previous application. If the revert fails, an interactive prompt is output through the HMI, prompting the user to select the application for scheduling audio playback resources from the first and second applications. If the user's selection result is obtained, the CDC schedules audio playback resources based on the selection result. Optionally, the HMI is also used to display the current playback status and the occupancy information of audio playback resources and applications during audio playback.

[0044] By establishing a priority order criterion, high-priority applications can be guaranteed to occupy audio playback resources; this also solves the problem of inconsistent audio resource scheduling when conflicts occur. Different audio playback resource scheduling strategies are selected for different priorities and application types, enabling rapid switching and conflict resolution of audio channels in multi-interconnected application scenarios. This improves the real-time response capability and seamless switching experience, enhancing the overall human-machine interaction of the in-vehicle system. Similarly, since the second application can be any of the following: in-vehicle Bluetooth music application, in-vehicle voice assistant, in-vehicle connectivity application, in-vehicle Bluetooth call application, TTS broadcast application, ADAS, or in-vehicle navigation broadcast application, like the first application, it also covers various software functional entities that may initiate audio playback requests while driving. This makes the solution applicable in multiple scenarios, improving the versatility and scalability of the technical solution.

[0045] In summary, with Figure 3 The following example illustrates the update process for the resource usage database, where the executing entity can be the CDC. Optionally, steps 301, 302, 303, and 304 are executed sequentially. Step 301 includes: a Bluetooth audio playback request from the first application triggers monitoring; step 302 includes: collecting at least one of the A2DP Profile status field of the Bluetooth protocol stack or the allocation status of the A2DP output channel; step 303 includes: updating the resource usage database; and step 304 includes: status update complete.

[0046] In summary, with Figure 4The following example illustrates the process for determining the occupancy of audio playback resources. The executing entity can be the CDC (Control Center for Disease Control and Prevention). Optionally, step 401 is executed first; then step 402 is executed; after step 402, if the audio playback resource is occupied, step 403 is executed; if the audio playback resource is not occupied, step 404 is executed. Step 401 includes: monitoring triggered by a Bluetooth audio playback request from the first application; step 402 includes: determining whether the audio playback resource is occupied; step 403: determining a scheduling strategy based on the application type of the second application occupying the audio playback resource, and scheduling the audio playback resource according to the scheduling strategy; step 404: directly allowing playback of the audio corresponding to the first application.

[0047] In summary, with Figure 5 The following example illustrates the process of scheduling audio playback resources, where the execution entity can be the CDC (Center for Disease Control and Prevention). First, step 501 is executed; then step 502 is executed; after step 502, if an automatic solution exists, step 503 is executed; if no automatic solution exists, step 509 is executed. Optionally, after step 503, any one of steps 504, 505, or 506 is executed; after completing any one of steps 504, 505, or 506, step 507 is executed; then step 508 is executed.

[0048] In one possible implementation, step 501 determines that audio playback resources are occupied; step 502 determines whether there are measures that can be automatically resolved; step 503 selects a scheduling strategy according to priority order; step 504 sends a suspension command to the application occupying the audio playback resources; step 505 enables the sub-channel; step 506 preloads the audio channel; step 507 schedules the audio playback resources according to the scheduling strategy; step 508 updates the resource occupancy database; and step 509 prompts the user to select the application to schedule the audio playback resources.

[0049] In summary, with Figure 6 The following example illustrates the process of resuming audio playback, where the execution entity can be CDC (Control Center). First, execute step 601; then step 602; then step 603; after step 603, if any application is suspended, execute step 604; if no application is suspended, execute step 606; after step 604, execute step 605; after step 605, execute step 606. Optionally, in step 601, the first application terminates; in step 602, find the second most recently suspended application; in step 603, determine if any application is suspended; in step 604, send a resumption command to the suspended application; in step 605, update the resource usage database; and in step 606, ensure system functional continuity.

[0050] In summary, the system architecture diagram is as follows: Figure 7 As shown, the user can launch the in-vehicle connectivity application 702 in the interactive application layer through the user interface HMI 701 of the user interaction layer; the resource monitoring module 703 can obtain the status of the in-vehicle connectivity application 702 and send it to the conflict determination module 704; after the conflict determination module 704 determines that a conflict exists, the multi-strategy intelligent scheduling module 705 generates a scheduling strategy and sends it to the resource recovery module 706. After completing the recovery operation, the resource recovery module 706 sends the information to HMI 701 for display. Among them, the resource monitoring module 703, the conflict determination module 704, the multi-strategy intelligent scheduling module 705, and the resource recovery module 706 belong to the conflict scheduling control layer.

[0051] After generating a scheduling policy, the multi-strategy intelligent scheduling module 705 sends it to the audio playback resource 707. Once the audio playback resource 707 is occupied, the policy is sent to the power amplifier and speaker 709 via the audio router 708 to enable audio playback. The audio playback resource 707 and the audio router 708 belong to the Bluetooth and audio layer; the power amplifier and speaker 709 belong to the hardware layer.

[0052] In summary, the system interaction sequence diagram is as follows: Figure 8 As shown, in one scenario, the user clicks to play music through the HMI interface; the HMI interface sends a playback request to the in-vehicle connectivity application; the in-vehicle connectivity application then sends a request to the conflict scheduling control layer to occupy audio resources; the conflict scheduling control layer allocates audio channels through audio playback resources, and then the audio router establishes audio routes; the audio routes then output audio to the amplifier and speakers. In another scenario, the user starts audio playback through the in-vehicle connectivity application; the in-vehicle connectivity application requests audio resources from the conflict scheduling control layer and requests the release of audio playback resources; the conflict scheduling control layer switches the audio resources to the in-vehicle connectivity application; updates the audio routes; the audio routes then output the audio from the in-vehicle connectivity application to the amplifier and speakers. In yet another scenario, if the in-vehicle connectivity application fails to request audio playback resources, the conflict scheduling control layer sends a pause command to the in-vehicle connectivity application. Optionally, during the interaction, the conflict scheduling control layer updates the playback status in real time through the HMI interface.

[0053] This application embodiment receives a Bluetooth audio playback request from a first application requesting audio playback resources. Based on the Bluetooth audio playback request, it detects the occupancy status of the audio playback resources. If the audio playback resources are occupied, it determines a scheduling strategy based on the application type of the second application occupying the audio playback resources, and schedules the audio playback resources according to the scheduling strategy. By uniformly monitoring and managing audio playback resources running simultaneously with multiple protocols and applications, it achieves rapid switching and conflict resolution of audio channels in multi-interconnected application scenarios, thereby improving the instantaneous response capability and seamless switching experience of playback, and enhancing the overall human-machine interaction experience of the in-vehicle system.

[0054] See Figure 9 This application provides an audio playback resource scheduling device, which includes: The receiving module 901 is used to receive a Bluetooth audio playback request from the first application, which is used to request audio playback resources. The detection module 902 is used to detect the occupancy of audio playback resources based on Bluetooth audio playback requests; The determination module 903 is used to determine the scheduling strategy based on the application type of the second application occupying the audio playback resources when the audio playback resources are occupied, and to schedule the audio playback resources according to the scheduling strategy.

[0055] In one possible implementation, the detection module 902 is used to obtain at least one of the Bluetooth protocol connection status or the audio output channel allocation status based on the Bluetooth audio playback request; if the Bluetooth protocol connection status is a streaming connection status, or the audio output channel allocation status is allocated, it determines that the audio playback resource is occupied.

[0056] In one possible implementation, the determining module 903 is used to determine the priority order of the first application and the second application based on the application type of the second application occupying the audio playback resources; and to determine a scheduling strategy based on the priority order of the first application and the second application, with different priority orders corresponding to different scheduling strategies.

[0057] In one possible implementation, if the priority order is that the first application has a higher priority than the second application, and the second application is a non-call application, the scheduling strategy is to suspend the second application's use of audio playback resources and schedule the audio playback resources to the first application. If the priority order is that the first application has a higher priority than the second application, and the second application is a call application, or if the priority order is that the first application has a lower priority than the second application, the scheduling strategy is to schedule the audio playback resources to the first application after the second application has finished running.

[0058] In one possible implementation, the determining module 903 is configured to, when the scheduling strategy is to schedule audio playback resources to the first application after the second application has finished running, preload the audio channel of the first application before the second application has finished running, and switch to the preloaded audio channel after the second application has finished running, so that the first application occupies the audio playback resources.

[0059] In one possible implementation, the determining module 903 is used to restore the second application's access to the audio playback resources after the first application has finished running, when the scheduling strategy is to suspend the second application's access to the audio playback resources and schedule the audio playback resources to the first application.

[0060] In one possible implementation, module 903 is used to enable a parallel sub-channel for audio playback resources when the application type of the second application is an overlay application, so as to realize the sharing of audio playback resources between the first application and the second application through the parallel sub-channel.

[0061] In one possible implementation, the determining module 903 is further configured to output an interactive prompt when the audio playback resource is not successfully scheduled according to the scheduling strategy. The interactive prompt is used to prompt the user to select the application for scheduling the audio playback resource in the first application and the second application; obtain the selection result; and schedule the audio playback resource based on the selection result.

[0062] This device receives Bluetooth audio playback requests from a first application requesting audio playback resources. Based on these requests, it detects the occupancy of audio playback resources. If resources are occupied, it determines a scheduling strategy based on the application type of the second application occupying the resources and schedules the audio playback resources accordingly. By uniformly monitoring and managing audio playback resources running with multiple protocols and applications simultaneously, it achieves rapid switching and conflict resolution of audio channels in multi-interconnected application scenarios. This improves the instantaneous response capability and seamless switching experience, enhancing the overall human-machine interaction of the in-vehicle system.

[0063] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0064] In an exemplary embodiment, a vehicle controller is also provided, characterized in that the vehicle controller includes a processor and a memory coupled together, the memory being used to store scheduling instructions for audio playback resources, the scheduling instructions being executed by the processor to implement any of the above-described audio playback resource scheduling methods.

[0065] In an exemplary embodiment, a vehicle is also provided, the vehicle including the vehicle controller described above, the vehicle controller being configured to execute any of the above-described audio playback resource scheduling methods to schedule audio playback resources for applications installed in the vehicle.

[0066] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the application type of the first application, the application type of the second application, the Bluetooth audio playback request of the first application, the Bluetooth audio playback request of the second application, the occupancy of audio playback resources, and the scheduling strategy involved in this application were all obtained with full authorization.

[0067] It should be understood that "multiple" as used in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0068] It should be noted that the terms "first," "second," etc. (if applicable) in the specification and claims of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0069] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for scheduling audio playback resources, characterized in that, The method includes: Receive a Bluetooth audio playback request from a first application, wherein the Bluetooth audio playback request is used to request audio playback resources; Based on the Bluetooth audio playback request, the occupancy status of the audio playback resources is detected; If the audio playback resource is occupied, a scheduling strategy is determined based on the application type of the second application occupying the audio playback resource, and the audio playback resource is scheduled according to the scheduling strategy.

2. The method according to claim 1, characterized in that, The step of detecting the occupancy of audio playback resources based on the Bluetooth audio playback request includes: Based on the Bluetooth audio playback request, obtain at least one of the Bluetooth protocol connection status or the audio output channel allocation status; If the Bluetooth connection status is a streaming connection status, or if the audio output channel allocation status is allocated, it is determined that the audio playback resource is occupied.

3. The method according to claim 1, characterized in that, The step of determining the scheduling strategy based on the application type of the second application occupying the audio playback resources includes: The priority order of the first application and the second application is determined based on the application type of the second application that occupies the audio playback resources; The scheduling strategy is determined based on the priority order of the first application and the second application, with different priority orders corresponding to different scheduling strategies.

4. The method according to claim 3, characterized in that, When the priority order is that the first application has a higher priority than the second application, and the application type of the second application is a non-call application, the scheduling strategy is to suspend the second application's occupation of the audio playback resource and schedule the audio playback resource to the first application. If the priority order is such that the first application has a higher priority than the second application and the second application is a call application, or if the priority order is such that the first application has a lower priority than the second application, the scheduling strategy is to schedule the audio playback resources to the first application after the second application has finished running.

5. The method according to claim 4, characterized in that, The step of scheduling the audio playback resources according to the scheduling strategy includes: In the case where the scheduling strategy is to allocate the audio playback resources to the first application after the second application has finished running, the audio channel of the first application is preloaded before the second application finishes running, and the preloaded audio channel is switched to after the second application finishes running, so that the first application occupies the audio playback resources.

6. The method according to claim 4, characterized in that, The step of scheduling the audio playback resources according to the scheduling strategy includes: When the scheduling strategy is to suspend the second application's use of the audio playback resources and schedule the audio playback resources to the first application, the second application's use of the audio playback resources will be restored after the first application finishes running.

7. The method according to claim 1, characterized in that, The step of determining the scheduling strategy based on the application type of the second application occupying the audio playback resources includes: When the application type of the second application is an overlay application, the parallel sub-channel of the audio playback resource is enabled, and the first application and the second application share the audio playback resource through the parallel sub-channel.

8. The method according to claim 1, characterized in that, After scheduling the audio playback resources according to the scheduling strategy, the method further includes: If the audio playback resource is not successfully scheduled according to the scheduling strategy, an interactive prompt is output. The interactive prompt is used to prompt the user to select the application to schedule the audio playback resource between the first application and the second application. Obtain the selection result, and schedule the audio playback resources based on the selection result.

9. A vehicle controller, characterized in that, The vehicle controller includes a processor coupled to a memory for storing scheduling instructions for Bluetooth resources. The scheduling instructions are executed by the processor to implement the audio playback resource scheduling method according to any one of claims 1-8.

10. A vehicle, characterized in that, The vehicle includes a vehicle controller as described in claim 9, the vehicle controller being configured to execute the audio playback resource scheduling method as described in any one of claims 1-8, to schedule audio playback resources for applications installed on the vehicle.

Images