Many-to-many audio equipment collaborative management method and system based on dynamic capacity constraint

Abstract

The invention discloses a many-to-many audio equipment collaborative management method and system based on dynamic capacity constraint, and belongs to the technical field of audio equipment management, and the method comprises the steps: building a binding capacity constraint through setting a first parameter of a collector and a second parameter of audio equipment according to an actual application scene; based on the binding capacity constraint, establishing a topological relation graph of the collector and the audio equipment by setting a binding relation between the collector and the audio equipment; and when the audio equipment receives the audio data packets from different collectors at the same time, determining the playing sequence of the audio data packets according to the playing priority provided by the topological relation graph. Therefore, by implementing the method, the device and the system, the problem that a plurality of audio devices cannot be flexibly switched in a complex application scene in the prior art can be solved.

Description

Technical Field

[0001] This application belongs to the field of audio device management technology, specifically relating to a method and system for collaborative management of many-to-many audio devices based on dynamic capacity constraints. Background Technology

[0002] As audio equipment applications become increasingly complex, more and more users want to use different combinations of audio equipment in different scenarios. Existing audio equipment management is generally based on centralized management by a central controller or through a fixed multicast / broadcast system.

[0003] The centralized controller architecture adopts a "host computer + control protocol + terminal device" model, where a central control server connects multiple audio devices via TCP / IP or a dedicated bus protocol for management and maintenance. However, this "one-to-many" management model generally does not support many-to-many bidirectional binding. Fixed multicast / broadcast mode systems publish audio devices to specific multicast addresses, determine the multicast stream of each audio device through binding relationships, and a single audio device can only play one multicast stream. It does not support multi-source switching or priority preemption, thus lacking flexibility and unable to dynamically change multicast addresses, making it difficult to support concurrent audio scheduling in complex scenarios. Summary of the Invention

[0004] This application proposes a method and system for collaborative management of many-to-many audio devices based on dynamic capacity constraints, which can solve the problem that existing technologies cannot flexibly switch between multiple audio devices in complex application scenarios.

[0005] The first aspect of this application provides a method for collaborative management of many-to-many audio devices based on dynamic capacity constraints, the method comprising:

[0006] Based on the actual application scenario, a binding capacity constraint is constructed by setting the first parameter of the collector and the second parameter of the audio device; wherein, the first parameter is used to limit the maximum number of audio devices that a single collector can be bound to, and the second parameter is used to limit the maximum number of collectors that a single audio device can be bound to.

[0007] Based on the aforementioned binding capacity constraint, a topology diagram of the collector and audio device is constructed by setting the binding relationship between the collector and the audio device;

[0008] When an audio device receives audio data packets from different acquisition devices simultaneously, the playback order of the audio data packets is determined according to the playback priority provided by the topology diagram.

[0009] The above solution sets an upper limit on the number of data collectors and audio devices that can be bound, based on the actual needs of the application scenario. The binding capacity can be dynamically adjusted using a set coefficient. Furthermore, the management of binding relationships is delegated to edge nodes such as data collectors, thus freeing them from the control of a central controller and enabling more flexible multi-device collaborative management. The binding relationship between data collectors and audio devices is constrained by limiting the amount of data each device can bind, thereby constructing a many-to-many topology graph to provide data support for subsequent binding relationship management and playback order settings. When a single audio device receives data from multiple data collectors, orderly audio playback is achieved by setting playback priorities, improving the flexibility of audio device collaborative management in complex scenarios.

[0010] In one possible implementation of the first aspect, based on the actual application scenario, a binding capacity constraint is constructed by setting the first parameter of the acquisition device and the second parameter of the audio device, specifically as follows:

[0011] When the management terminal, all collectors and all audio devices are connected to the same local area network, the first parameter of the collector and the second parameter of the audio device are set through the management terminal based on the number of devices used in the actual application scenario.

[0012] If the total number of collectors to be bound to the audio device exceeds the second parameter, the packet loss rate of all communication links of the audio device is detected, and the bound collectors are unbound according to the communication link priority obtained from the detection results.

[0013] Based on the first parameter and the second parameter, a binding capacity constraint is constructed.

[0014] The above solution allows for the binding and unbinding of data acquisition devices and audio devices within the same local area network via a management terminal. A first and second parameter limit is set to restrict the maximum number of devices that can be bound, and this limit can be dynamically managed by simply modifying the parameters, allowing the binding capacity to be dynamically adjusted according to changes in the scenario. For devices exceeding the limit, selection is based on current communication quality, ensuring that audio devices always connect to the data acquisition device with the best communication quality, thus improving audio playback quality.

[0015] In one possible implementation of the first aspect, the first parameter and the second parameter further include:

[0016] The communication link between the acquisition device and the audio device is detected based on a preset detection frequency to obtain the operating status of the communication link; wherein, the operating status includes packet loss rate, audio device load status, audio stream encoding complexity, and historical failure rate;

[0017] Based on the operating conditions, adjust the values ​​of the first and second parameters, and reset the acquisition unit and audio equipment according to the adjusted parameters.

[0018] In one possible implementation of the first aspect, based on the binding capacity constraint, a topology diagram of the collector and the audio device is constructed by setting the binding relationship between the collector and the audio device, specifically as follows:

[0019] The first management terminal sends a configuration command to the designated first collector, and queries the local database of the first collector according to the configuration command to obtain the number of devices bound to the first collector.

[0020] Obtain the number of bound collectors for the first audio device corresponding to the configuration instruction. If both the number of bound devices and the number of bound collectors meet the binding capacity constraint, then establish the binding relationship by establishing a communication link between the first collector and the first audio device.

[0021] The binding relationship is written into the local database of the first collector, and the topology graph is constructed based on the binding relationship of all collectors.

[0022] The above solution binds devices through a management terminal, while the storage and management of the binding relationship are carried out on the acquisition device. Compared with centralized management through a central controller, this decentralized management method is more flexible, has better scalability, and can be adjusted more quickly when adding new acquisition devices or audio devices.

[0023] In one possible implementation of the first aspect, when the binding relationship changes, it is detected whether the first collector is currently occupied by another management terminal; if it is occupied by another management terminal, the write request of the first management terminal is added to the management queue.

[0024] The corresponding management terminal is notified to modify the binding relationship according to the order of the management queue.

[0025] The above solution manages modification operations on multiple management terminals in an orderly manner through a management queue, ensuring that concurrent operation requests do not cause errors in the binding relationship, guaranteeing data consistency, and realizing collaborative control of multiple management terminals.

[0026] In one possible implementation of the first aspect, when the audio device simultaneously receives audio data packets from different acquisition devices, the playback order of the audio data packets is determined according to the playback priority provided by the topology diagram, specifically as follows:

[0027] Based on the topology diagram, the number of devices bound to the collector is obtained;

[0028] The system sends heartbeat packets to the collector at a fixed frequency via an audio device. If the collector fails to respond to the heartbeat packets for a first threshold number of consecutive times, the collector is marked as offline.

[0029] Based on the number of bound devices, the playback priority is set for the collectors that are not offline;

[0030] The audio data packets are sorted according to the playback priority to obtain the playback order; wherein, the higher the playback priority, the earlier the corresponding audio data packet is played.

[0031] The above solution intelligently schedules audio data packets from different sources during the same time period, and reasonably sets playback priorities by evaluating the operating status of the acquisition device to ensure that high-priority audio is played first.

[0032] One possible implementation of the first aspect also includes:

[0033] If, while playing the audio data packet, the audio device receives an audio data packet with a higher playback priority, the playback order is adjusted so that the audio device plays the audio data packet with the higher playback priority;

[0034] If the audio device supports mixed playback, the mixing module is invoked to perform multi-channel audio mixing and output of all the aforementioned audio data packets.

[0035] In one possible implementation of the first aspect, the local database is specifically:

[0036] Each collector has a built-in local database for storing the binding relationships and their corresponding audio device information;

[0037] The audio device information includes the unique identifier of the audio device, the playback priority, the operating status of the audio device, and the time when the last heartbeat packet was received.

[0038] The above solution stores and manages the binding relationships through a local database, enabling edge nodes to maintain the binding relationships autonomously, thus eliminating dependence on the central server and achieving edge autonomy.

[0039] The second aspect of this application provides a multi-to-multi audio device collaborative management system based on dynamic capacity constraints, the system comprising: a capacity constraint construction module, a device binding module, and an audio data scheduling module;

[0040] The capacity constraint construction module is used to construct a binding capacity constraint by setting the first parameter of the acquisition device and the second parameter of the audio device according to the actual application scenario. The first parameter is used to limit the maximum number of audio devices that a single acquisition device can be bound to, and the second parameter is used to limit the maximum number of acquisition devices that a single audio device can be bound to.

[0041] The device binding module is used to construct a topology diagram of the collector and audio device by setting the binding relationship between the collector and the audio device based on the binding capacity constraint.

[0042] The audio data scheduling module is used to determine the playback order of audio data packets based on the playback priority provided by the topology diagram when the audio device receives audio data packets from different collectors at the same time.

[0043] A third aspect of this application provides a terminal device, the device comprising: a terminal device including a processor and a memory, the memory storing a computer program, wherein the processor executes the computer program to implement the steps of the multi-to-multi audio device collaborative management method based on dynamic capacity constraints as described in any one of the embodiments of this application. Attached Figure Description

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

[0045] Figure 1 This is a schematic diagram of a specific process for a multi-to-multi audio device collaborative management method based on dynamic capacity constraints, provided in an embodiment of this application.

[0046] Figure 2 This is a structural diagram of a multi-to-multi audio device collaborative management system based on dynamic capacity constraints, provided in an embodiment of this application.

[0047] Figure 3 This is a structural diagram of a terminal device provided in an embodiment of this application. Detailed Implementation

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

[0049] It should be understood that the step numbers used in the text are for ease of description only and are not intended to limit the order in which the steps are performed.

[0050] First Embodiment

[0051] In current application scenarios, the binding relationship between audio devices and acquisition devices only supports "one-to-many" or fixed binding, and cannot achieve bidirectional many-to-many dynamic binding between the two. Moreover, if the binding relationship needs to be modified, it is necessary to contact the central controller for unified processing. If the controller crashes or the network is interrupted, the system cannot add or modify binding relationships. Therefore, in order to improve the flexibility of managing multiple audio devices in complex application scenarios, this application embodiment delegates the management authority of binding relationships to acquisition devices located at the edge, eliminating the dependence on the central controller and realizing flexible switching and management of multiple audio devices in practical applications.

[0052] like Figure 1 As shown, to address the problem in existing technologies that cannot flexibly switch between multiple audio devices in complex application scenarios, the first embodiment of this application provides a detailed flowchart of a multi-to-multi audio device collaborative management method based on dynamic capacity constraints. This embodiment's multi-to-multi audio device collaborative management method based on dynamic capacity constraints includes steps S1 to S3, detailed below:

[0053] Step S1: Based on the actual application scenario, construct the binding capacity constraint by setting the first parameter of the acquisition device and the second parameter of the audio device.

[0054] The implementation of this application embodiment is based on a system architecture including a data acquisition unit, an audio device, a management terminal, and a communication network. The data acquisition unit is an edge device with network communication, audio acquisition, and binding management capabilities, and has a built-in embedded operating system and local database. The audio device is a smart terminal that supports audio decoding and playback; in this application embodiment, it is a speaker. The management terminal, also known as a PC, is a host computer running management software, supporting graphical configuration, status monitoring, and policy distribution. The communication network is a local area network or dedicated audio network based on TCP / IP or UDP, supporting real-time control and audio stream transmission.

[0055] In a communication network, all devices use a unique device identifier for addressing and authentication.

[0056] In this application embodiment, two modifiable parameters are introduced: a first parameter and a second parameter. The first parameter is used to limit the maximum number of audio devices that can be bound to a single acquisition device; the second parameter is used to limit the maximum number of acquisition devices that can be bound to a single audio device.

[0057] Optionally, the factory default value of the first parameter is 128, which can be dynamically adjusted through the management terminal; the factory default value of the second parameter is 4, which can be configured remotely.

[0058] For example, in a small meeting room, the first parameter can be set to 32 and the second parameter to 2; in a large meeting room, the first parameter can be set to 256 and the second parameter to 8, so as to achieve multiple uses of one machine and configure it as needed.

[0059] Once the management terminal, all data acquisition units, and all audio devices are connected to the same communication network, the number of audio devices and data acquisition units to participate in audio playback, as well as their connection relationships, are determined based on the device usage limits specified in the current application scenario. According to these connection relationships and quantity information, the management terminal sets the first parameter of the data acquisition units and the second parameter of the audio devices to limit the binding of these devices and establish binding capacity constraints.

[0060] Parameters can be set through any management terminal, and the set parameters can be sent to the corresponding acquisition device and audio device through configuration commands.

[0061] As an improvement to the above scheme, when both the collector and the audio device reach the binding limit set by the parameters, if a new device to be bound appears, the congestion of the communication link (e.g., packet loss rate) is detected to set the communication link priority, and the lower-priority bound collector is unbound according to the communication link priority, while the higher-priority collector is preemptively bound.

[0062] In addition, this embodiment of the application will periodically detect the communication link between the collector and the audio device to obtain the operating status of the communication link. The operating status includes packet loss rate, audio device load status, audio stream encoding complexity, and historical failure rate. When the operating status is determined to be congested, the corresponding first parameter or second parameter will be automatically reduced to lower the binding limit of the collector or audio device and avoid data delay.

[0063] Therefore, based on the operating conditions, the values ​​of the first and second parameters are adjusted, and the acquisition unit and audio equipment are reset according to the adjusted parameters.

[0064] Step S2: Based on the binding capacity constraint, construct a topology diagram of the collector and audio device by setting the binding relationship between the collector and the audio device.

[0065] You can log in to any management terminal and send configuration commands to the specified data acquisition device. After receiving the command, the data acquisition device first queries the local database to count the number of currently bound audio devices. If the number of currently bound audio devices equals the first parameter, it returns "Capacity reached" and does not configure any binding relationships.

[0066] If the number of currently bound audio devices is less than the first parameter, the collector sends a binding request to the audio device according to the configuration instructions, obtains the number of collectors already bound to the audio device, and verifies whether the audio device is acceptable for binding.

[0067] If the number of bound collectors is greater than the second parameter and the audio device can be bound to a collector, then a communication link is established between the collector and the audio device to build a binding relationship between them, and the binding relationship is written to the collector's local database.

[0068] The audio device has a whitelist configured to record which data acquisition devices can be bound to it; this whitelist typically contains the unique device identifier of each data acquisition device. Upon receiving a binding request, the audio device checks the whitelist to determine whether to allow the data acquisition device to establish a communication link.

[0069] Furthermore, the local database is used to store binding relationships and their corresponding audio device information. This database is a lightweight, highly available database that supports transaction operations. Its specific storage information and structure are shown in Table 1 below:

[0070] Table 1

[0071]

[0072] The local data supports regular backup and recovery. Through the local database, the binding relationship is maintained autonomously by the edge collector, freeing it from dependence on the central server and achieving edge autonomy.

[0073] Every 30 seconds, all data collectors upload the binding relationships stored in the local database to the management terminal. The management platform generates and updates the topology diagram of the data collectors and audio devices in real time based on this uploaded information.

[0074] Furthermore, the management terminal employs a distributed collaborative management protocol to manage the data collectors, enabling multiple management terminals to manage different data collectors simultaneously. Under this protocol, each PC connects to the system architecture after security authentication. When a PC initiates a write operation to the data collector's local database, the system automatically allocates an exclusive write lock to the PC. At this time, write requests from other PCs to the data collector can only enter the management queue or be converted to read-only mode. All operation records to the local database are written to the operation audit log, which supports rollback and traceability, enabling multi-user collaborative, secure, orderly, and auditable remote management.

[0075] Furthermore, when a management terminal sends a request to the collector to modify the binding relationship, it first checks whether the collector is currently occupied by another management terminal or undergoing write operations (generally, it checks whether an exclusive write lock has been assigned). If it is occupied by another management terminal, the write request from that terminal is added to the management queue, and the corresponding management terminal is notified to modify the binding relationship according to the order in the management queue when the exclusive write lock is released. Finally, all write operations are recorded in the operation audit log.

[0076] As an improvement to the above solution, the operation priority of the management terminal can be set to dynamically control the modification of the binding relationship. For this operation priority, a higher-priority device can preempt the operation of a lower-priority device. Furthermore, when the management terminal sends a request to the collector to modify the binding relationship, it first writes the change information to a temporary buffer. Once automatic verification confirms that the change information will not conflict with the information in the local database, the change information is submitted to the local database. If the operation is interrupted during the write operation, the local database is rolled back to its original state according to the operation audit log, avoiding logical confusion caused by "partial updates".

[0077] Step S3: When the audio device receives audio data packets from different collectors simultaneously, the playback order of the audio data packets is determined according to the playback priority provided by the topology diagram.

[0078] When an audio device simultaneously receives multiple audio data packets from different collectors, the number of bound devices for each collector is first determined based on the latest version of the topology graph. Simultaneously, the most recent heartbeat response time for each collector is obtained. The operating status of the corresponding collector is determined based on the most recent heartbeat response time. Combining the operating status and the number of bound devices, the playback priority is set for collectors that are not offline; collectors that are offline are not processed.

[0079] According to the playback priority, the audio data packets are sorted for playback, and the higher the playback priority, the earlier the corresponding audio data packet is played.

[0080] For example, when audio device S1 receives audio data packets from collectors C1, C2 and C3 simultaneously, if C2 has a higher playback priority, the audio data packet from C2 will be played first; if C1 has a higher playback priority but C1 is offline, the audio data packet from C1 will not be played.

[0081] To collect the response time of the most recent heartbeat packet, this embodiment of the application introduces a heartbeat mechanism. Under the heartbeat mechanism, the audio device sends a heartbeat packet to all bound collectors every 5 seconds. After receiving the heartbeat packet, the collector updates the last_heartbeat in its local database (see Table 1) and sends a received signal back to the audio device. If the audio device fails to receive a received signal for three consecutive times, it marks the collector as "offline". When the audio device restarts, it will proactively send a "re-register" request to all bound collectors to restore the connection.

[0082] Furthermore, if the audio device receives other audio data packets with higher playback priority while playing audio data packets according to the playback order, the playback order is readjusted so that the audio device plays the audio data packets with higher playback priority, and the playback of low-priority data packets is interrupted.

[0083] If the audio device has a mixing module installed, it can support mixed playback. Multiple audio data packets can be mixed and output in a multi-channel audio output by calling the mixing module.

[0084] Optionally, the mixing module in this embodiment is a DSP module.

[0085] Additionally, if a data acquisition device is globally muted, the audio device it is paired with will automatically block that audio source. The speaker periodically sends heartbeat packets to the paired data acquisition device; if no response is received within a timeout period, it is marked as offline and the audio source is switched.

[0086] Therefore, based on the solution provided in this application, many-to-many bindings can be established between the acquisition device and the audio device, and the binding relationship can be managed locally on the acquisition device, enabling flexible switching of the binding relationship and elastic expansion of the device. When a new acquisition device or audio device is added, it can be managed directly.

[0087] Implementing the embodiments of this application has the following beneficial effects:

[0088] This application embodiment sets an upper limit on the number of data collectors and audio devices that can be bound, based on the actual needs of the application scenario. The binding capacity can be dynamically adjusted using a set coefficient. Furthermore, the management of binding relationships is delegated to edge nodes such as data collectors, thereby freeing them from the control of a central controller and enabling more flexible multi-device collaborative management. The binding relationship between data collectors and audio devices is constrained by limiting the amount of data each device can bind, thus constructing a many-to-many topology graph to provide data support for subsequent binding relationship management and playback order settings. When a single audio device receives data from multiple data collectors, orderly audio playback is achieved by setting playback priorities, improving the flexibility of audio device collaborative management in complex scenarios.

[0089] Second Embodiment

[0090] Furthermore, in order to implement the multi-to-multi audio device collaborative management system based on dynamic capacity constraints corresponding to the above method embodiments, and to achieve the corresponding functions and technical effects, Figure 2 A structural diagram of a multi-to-many audio device collaborative management system based on dynamic capacity constraints is provided. For ease of explanation, only the parts relevant to this embodiment are shown. The multi-to-many audio device collaborative management system based on dynamic capacity constraints provided in this application embodiment includes:

[0091] The capacity constraint construction module 201 is used to construct a binding capacity constraint by setting a first parameter of the acquisition device and a second parameter of the audio device according to the actual application scenario; wherein, the first parameter is used to limit the maximum number of audio devices that a single acquisition device can be bound to, and the second parameter is used to limit the maximum number of acquisition devices that a single audio device can be bound to.

[0092] The implementation of this application embodiment is based on a system architecture including a data acquisition unit, an audio device, a management terminal, and a communication network. The data acquisition unit is an edge device with network communication, audio acquisition, and binding management capabilities, and has a built-in embedded operating system and local database. The audio device is a smart terminal that supports audio decoding and playback; in this application embodiment, it is a speaker. The management terminal, also known as a PC, is a host computer running management software, supporting graphical configuration, status monitoring, and policy distribution. The communication network is a local area network or dedicated audio network based on TCP / IP or UDP, supporting real-time control and audio stream transmission.

[0093] In a communication network, all devices use a unique device identifier for addressing and authentication.

[0094] In this application embodiment, two modifiable parameters are introduced: a first parameter and a second parameter. The first parameter is used to limit the maximum number of audio devices that can be bound to a single acquisition device; the second parameter is used to limit the maximum number of acquisition devices that can be bound to a single audio device.

[0095] Optionally, the factory default value of the first parameter is 128, which can be dynamically adjusted through the management terminal; the factory default value of the second parameter is 4, which can be configured remotely.

[0096] For example, in a small meeting room, the first parameter can be set to 32 and the second parameter to 2; in a large meeting room, the first parameter can be set to 256 and the second parameter to 8, so as to achieve multiple uses of one machine and configure it as needed.

[0097] Once the management terminal, all data acquisition units, and all audio devices are connected to the same communication network, the number of audio devices and data acquisition units to participate in audio playback, as well as their connection relationships, are determined based on the device usage limits specified in the current application scenario. According to these connection relationships and quantity information, the management terminal sets the first parameter of the data acquisition units and the second parameter of the audio devices to limit the binding of these devices and establish binding capacity constraints.

[0098] Parameters can be set through any management terminal, and the set parameters can be sent to the corresponding acquisition device and audio device through configuration commands.

[0099] As an improvement to the above scheme, when both the collector and the audio device reach the binding limit set by the parameters, if a new device to be bound appears, the congestion of the communication link (e.g., packet loss rate) is detected to set the communication link priority, and the lower-priority bound collector is unbound according to the communication link priority, while the higher-priority collector is preemptively bound.

[0100] In addition, this embodiment of the application will periodically detect the communication link between the collector and the audio device to obtain the operating status of the communication link. The operating status includes packet loss rate, audio device load status, audio stream encoding complexity, and historical failure rate. When the operating status is determined to be congested, the corresponding first parameter or second parameter will be automatically reduced to lower the binding limit of the collector or audio device and avoid data delay.

[0101] Therefore, based on the operating conditions, the values ​​of the first and second parameters are adjusted, and the acquisition unit and audio equipment are reset according to the adjusted parameters.

[0102] The device binding module 202 is used to construct a topology diagram of the collector and the audio device by setting the binding relationship between the collector and the audio device based on the binding capacity constraint.

[0103] You can log in to any management terminal and send configuration commands to the specified data acquisition device. After receiving the command, the data acquisition device first queries the local database to count the number of currently bound audio devices. If the number of currently bound audio devices equals the first parameter, it returns "Capacity reached" and does not configure any binding relationships.

[0104] If the number of currently bound audio devices is less than the first parameter, the collector sends a binding request to the audio device according to the configuration instructions, obtains the number of collectors already bound to the audio device, and verifies whether the audio device is acceptable for binding.

[0105] If the number of bound collectors is greater than the second parameter and the audio device can be bound to a collector, then a communication link is established between the collector and the audio device to build a binding relationship between them, and the binding relationship is written to the collector's local database.

[0106] The audio device has a whitelist configured to record which data acquisition devices can be bound to it; this whitelist typically contains the unique device identifier of each data acquisition device. Upon receiving a binding request, the audio device checks the whitelist to determine whether to allow the data acquisition device to establish a communication link.

[0107] Furthermore, the local database is used to store binding relationships and their corresponding audio device information. This database is a lightweight, highly available database that supports transaction operations. Its specific storage information and structure are shown in Table 2 below:

[0108] Table 2

[0109]

[0110] The local data supports regular backup and recovery. Through the local database, the binding relationship is maintained autonomously by the edge collector, freeing it from dependence on the central server and achieving edge autonomy.

[0111] Every 30 seconds, all data collectors upload the binding relationships stored in the local database to the management terminal. The management platform generates and updates the topology diagram of the data collectors and audio devices in real time based on this uploaded information.

[0112] Furthermore, the management terminal employs a distributed collaborative management protocol to manage the data collectors, enabling multiple management terminals to manage different data collectors simultaneously. Under this protocol, each PC connects to the system architecture after security authentication. When a PC initiates a write operation to the data collector's local database, the system automatically allocates an exclusive write lock to the PC. At this time, write requests from other PCs to the data collector can only enter the management queue or be converted to read-only mode. All operation records to the local database are written to the operation audit log, which supports rollback and traceability, enabling multi-user collaborative, secure, orderly, and auditable remote management.

[0113] Furthermore, when a management terminal sends a request to the collector to modify the binding relationship, it first checks whether the collector is currently occupied by another management terminal or undergoing write operations (generally, it checks whether an exclusive write lock has been assigned). If it is occupied by another management terminal, the write request from that terminal is added to the management queue, and the corresponding management terminal is notified to modify the binding relationship according to the order in the management queue when the exclusive write lock is released. Finally, all write operations are recorded in the operation audit log.

[0114] As an improvement to the above solution, the operation priority of the management terminal can be set to dynamically control the modification of the binding relationship. For this operation priority, a higher-priority device can preempt the operation of a lower-priority device. Furthermore, when the management terminal sends a request to the collector to modify the binding relationship, it first writes the change information to a temporary buffer. Once automatic verification confirms that the change information will not conflict with the information in the local database, the change information is submitted to the local database. If the operation is interrupted during the write operation, the local database is rolled back to its original state according to the operation audit log, avoiding logical confusion caused by "partial updates".

[0115] The audio data scheduling module 203 is used to determine the playback order of the audio data packets according to the playback priority provided by the topology diagram when the audio device receives audio data packets from different collectors at the same time.

[0116] When an audio device simultaneously receives multiple audio data packets from different collectors, the number of bound devices for each collector is first determined based on the latest version of the topology graph. Simultaneously, the most recent heartbeat response time for each collector is obtained. The operating status of the corresponding collector is determined based on the most recent heartbeat response time. Combining the operating status and the number of bound devices, the playback priority is set for collectors that are not offline; collectors that are offline are not processed.

[0117] According to the playback priority, the audio data packets are sorted for playback, and the higher the playback priority, the earlier the corresponding audio data packet is played.

[0118] For example, when audio device S1 receives audio data packets from collectors C1, C2 and C3 simultaneously, if C2 has a higher playback priority, the audio data packet from C2 will be played first; if C1 has a higher playback priority but C1 is offline, the audio data packet from C1 will not be played.

[0119] To collect the response time of the most recent heartbeat packet, this embodiment of the application introduces a heartbeat mechanism. Under the heartbeat mechanism, the audio device sends a heartbeat packet to all bound collectors every 5 seconds. After receiving the heartbeat packet, the collector updates the last_heartbeat in its local database (see Table 2) and sends a received signal back to the audio device. If the audio device fails to receive a received signal for three consecutive times, it marks the collector as "offline". When the audio device restarts, it will proactively send a "re-register" request to all bound collectors to restore the connection.

[0120] Furthermore, if the audio device receives other audio data packets with higher playback priority while playing audio data packets according to the playback order, the playback order is readjusted so that the audio device plays the audio data packets with higher playback priority, and the playback of low-priority data packets is interrupted.

[0121] If the audio device has a mixing module installed, it can support mixed playback. Multiple audio data packets can be mixed and output in a multi-channel audio output by calling the mixing module.

[0122] Optionally, the mixing module in this embodiment is a DSP module.

[0123] Additionally, if a data acquisition device is globally muted, the audio device it is paired with will automatically block that audio source. The speaker periodically sends heartbeat packets to the paired data acquisition device; if no response is received within a timeout period, it is marked as offline and the audio source is switched.

[0124] Therefore, based on the solution provided in this application, many-to-many bindings can be established between the acquisition device and the audio device, and the binding relationship can be managed locally on the acquisition device, enabling flexible switching of the binding relationship and elastic expansion of the device. When a new acquisition device or audio device is added, it can be managed directly.

[0125] Implementing the embodiments of this application has the following beneficial effects:

[0126] This application embodiment sets an upper limit on the number of data collectors and audio devices that can be bound, based on the actual needs of the application scenario. The binding capacity can be dynamically adjusted using a set coefficient. Furthermore, the management of binding relationships is delegated to edge nodes such as data collectors, thereby freeing them from the control of a central controller and enabling more flexible multi-device collaborative management. The binding relationship between data collectors and audio devices is constrained by limiting the amount of data each device can bind, thus constructing a many-to-many topology graph to provide data support for subsequent binding relationship management and playback order settings. When a single audio device receives data from multiple data collectors, orderly audio playback is achieved by setting playback priorities, improving the flexibility of audio device collaborative management in complex scenarios.

[0127] Furthermore, Figure 3 This is a structural diagram of a terminal device provided in one embodiment of this application. Figure 3 As shown, the terminal device 3 of this embodiment includes: at least one processor 30 (in... Figure 3 The present invention includes a memory 31 and a computer program 32 stored in the memory 31 and executable on the at least one processor. When the processor 30 executes the computer program 32, it can implement the steps of a multi-to-multi audio device collaborative management method based on dynamic capacity constraints as described in any one of the embodiments of this application.

[0128] The terminal device 3 may be a computing device such as a desktop computer, a cloud server, or a laptop computer, and the computing device may include, but is not limited to, a processor 30 and a memory 31. Figure 3 This is merely an example of terminal device 3 and does not constitute a limitation on terminal device 3. It may include more or fewer components than those shown in the figure.

[0129] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. In particular, it should be noted that any modifications, equivalent substitutions, or improvements made by those skilled in the art within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for collaborative management of many-to-many audio devices based on dynamic capacity constraints, characterized in that, include: Based on the actual application scenario, a binding capacity constraint is constructed by setting the first parameter of the collector and the second parameter of the audio device; wherein, the first parameter is used to limit the maximum number of audio devices that a single collector can be bound to, and the second parameter is used to limit the maximum number of collectors that a single audio device can be bound to. Based on the aforementioned binding capacity constraint, a topology diagram of the collector and audio device is constructed by setting the binding relationship between the collector and the audio device; When an audio device receives audio data packets from different acquisition devices simultaneously, the playback order of the audio data packets is determined according to the playback priority provided by the topology diagram.

2. The method for collaborative management of many-to-many audio devices based on dynamic capacity constraints according to claim 1, characterized in that, Based on the actual application scenario, a binding capacity constraint is constructed by setting the first parameter of the acquisition device and the second parameter of the audio device, specifically as follows: When the management terminal, all collectors and all audio devices are connected to the same local area network, the first parameter of the collector and the second parameter of the audio device are set through the management terminal based on the number of devices used in the actual application scenario. If the total number of collectors to be bound to the audio device exceeds the second parameter, the packet loss rate of all communication links of the audio device is detected, and the bound collectors are unbound according to the communication link priority obtained from the detection results. Based on the first parameter and the second parameter, a binding capacity constraint is constructed.

3. The method for collaborative management of many-to-many audio devices based on dynamic capacity constraints according to claim 2, characterized in that, The first parameter and the second parameter also include: The communication link between the acquisition device and the audio device is detected based on a preset detection frequency to obtain the operating status of the communication link; wherein, the operating status includes packet loss rate, audio device load status, audio stream encoding complexity, and historical failure rate; Based on the operating conditions, adjust the values ​​of the first and second parameters, and reset the acquisition unit and audio equipment according to the adjusted parameters.

4. The method for collaborative management of many-to-many audio devices based on dynamic capacity constraints according to claim 1, characterized in that, Based on the binding capacity constraint, a topology diagram of the collector and audio device is constructed by setting the binding relationship between the collector and the audio device, specifically as follows: The first management terminal sends a configuration command to the designated first collector, and queries the local database of the first collector according to the configuration command to obtain the number of devices bound to the first collector. Obtain the number of bound collectors for the first audio device corresponding to the configuration instruction. If both the number of bound devices and the number of bound collectors meet the binding capacity constraint, then establish the binding relationship by establishing a communication link between the first collector and the first audio device. The binding relationship is written into the local database of the first collector, and the topology graph is constructed based on the binding relationship of all collectors.

5. The method for collaborative management of many-to-many audio devices based on dynamic capacity constraints according to claim 4, characterized in that, When the binding relationship changes, it is detected whether the first collector is currently occupied by another management terminal; If the task is occupied by another management terminal, the write request from the first management terminal will be added to the management queue. The corresponding management terminal is notified to modify the binding relationship according to the order of the management queue.

6. The method for collaborative management of many-to-many audio devices based on dynamic capacity constraints according to claim 1, characterized in that, When an audio device simultaneously receives audio data packets from different acquisition devices, the playback order of the audio data packets is determined according to the playback priority provided by the topology diagram, specifically as follows: Based on the topology diagram, the number of devices bound to the collector is obtained; The system sends heartbeat packets to the collector at a fixed frequency via an audio device. If the collector fails to respond to the heartbeat packets for a first threshold number of consecutive times, the collector is marked as offline. Based on the number of bound devices, the playback priority is set for the collectors that are not offline; The audio data packets are sorted according to the playback priority to obtain the playback order; wherein, the higher the playback priority, the earlier the corresponding audio data packet is played.

7. The method for collaborative management of many-to-many audio devices based on dynamic capacity constraints according to claim 6, characterized in that, Also includes: If, while playing the audio data packet, the audio device receives an audio data packet with a higher playback priority, the playback order is adjusted so that the audio device plays the audio data packet with the higher playback priority; If the audio device supports mixed playback, the mixing module is invoked to perform multi-channel audio mixing and output of all the aforementioned audio data packets.

8. The method for collaborative management of many-to-many audio devices based on dynamic capacity constraints according to any one of claims 1 to 7, characterized in that, The local database is specifically: Each collector has a built-in local database for storing the binding relationships and their corresponding audio device information; The audio device information includes the unique identifier of the audio device, the playback priority, the operating status of the audio device, and the time when the last heartbeat packet was received.

9. A multi-to-multi audio device collaborative management system based on dynamic capacity constraints, characterized in that, include: Capacity constraint construction module, device binding module, and audio data scheduling module; The capacity constraint construction module is used to construct a binding capacity constraint by setting the first parameter of the acquisition device and the second parameter of the audio device according to the actual application scenario. The first parameter is used to limit the maximum number of audio devices that a single acquisition device can be bound to, and the second parameter is used to limit the maximum number of acquisition devices that a single audio device can be bound to. The device binding module is used to construct a topology diagram of the collector and audio device by setting the binding relationship between the collector and the audio device based on the binding capacity constraint. The audio data scheduling module is used to determine the playback order of audio data packets based on the playback priority provided by the topology diagram when the audio device receives audio data packets from different collectors at the same time.

10. A terminal device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the steps of the multi-to-multi audio device collaborative management method based on dynamic capacity constraints according to any one of claims 1 to 8.

Images