Cross-terminal equipment state parameter synchronization method, system and equipment and storage medium

Abstract

The invention discloses a state parameter synchronization method, system and device across terminal devices and a storage medium, and relates to the technical field of audio processing and device collaboration, and the method comprises the steps: building a full duplex communication link between a plurality of clients and a synchronization server; in response to the adjustment operation of the state parameters, the first client generates an incremental update data set and sends the incremental update data set to the synchronization server; receiving the incremental update data set by the synchronization server, executing conflict detection and judgment, and updating a global main parameter state; the synchronization server generates a synchronization update instruction according to the updated global main parameter state and distributes the synchronization update instruction to an associated second client in real time through a corresponding communication link; and the second client receives and analyzes the synchronous updating instruction to locally apply parameter change, and low-delay and high-reliability multi-terminal state real-time synchronization is realized by establishing a real-time full-duplex link and combining incremental updating, a conflict detection and judgment mechanism and a fault-tolerant recovery strategy.

Description

Technical Field

[0001] This invention relates to the field of audio processing and device collaboration technology, and in particular to a method, system, device, and storage medium for synchronizing status parameters across terminal devices. Background Technology

[0002] In audio playback devices and applications, equalizers (EQ) are an important function for users to personalize sound quality adjustments. Users can optimize sound performance by adjusting the gain values ​​of different frequency bands to suit different music genres or personal listening preferences. With the widespread use of smart devices, users often access the same audio device or service simultaneously using mobile apps and web browsers. However, in current technology, EQ configurations are usually stored only on the local client, independent of each other across different platforms.

[0003] Traditional configuration synchronization solutions primarily rely on HTTP polling or manual synchronization. With HTTP polling, the client needs to periodically request the latest configuration from the server, resulting in significant latency (typically 5-30 seconds) and generating numerous invalid requests that waste bandwidth and server resources. Manual synchronization requires users to export the configuration file and import it onto another platform, a cumbersome process that cannot achieve real-time synchronization. Some solutions use push notifications to trigger configuration updates, but the latency and reliability of push services are difficult to guarantee, and additional integration with third-party push SDKs is required. None of these technical solutions meet modern users' expectations for a seamless cross-platform experience, especially in scenarios involving multi-user collaborative adjustments or rapid device switching, where configuration inconsistencies are particularly prominent and severely impact user experience. Therefore, there is an urgent need for a cross-platform, low-latency, highly reliable audio equalizer parameter real-time synchronization technology that supports collaboration and conflict resolution. Summary of the Invention

[0004] This invention aims to solve the technical problem that audio equalizer parameters cannot be synchronized in real time, consistently, and reliably across cross-platform devices in the prior art. It provides a method for synchronizing state parameters across terminal devices. By establishing a real-time full-duplex link and combining incremental updates, conflict detection and adjudication mechanisms, and fault-tolerant recovery strategies, it achieves low-latency and highly reliable real-time synchronization of multi-terminal states.

[0005] The first aspect of this invention provides a method for synchronizing status parameters across terminal devices, comprising: Establish full-duplex communication links between multiple clients and the synchronization server; The first client responds to the adjustment operation of the status parameters, generates an incremental update dataset containing version metadata, and sends it to the synchronization server; The synchronization server receives the incremental update dataset and performs conflict detection and adjudication based on the version metadata to update the global master parameter state; The synchronization server generates a synchronization update instruction based on the updated global master parameter status and distributes it in real time to at least one associated second client through the corresponding communication link; The second client receives and parses the synchronization update instruction to apply the parameter changes locally, thereby achieving real-time consistency synchronization of status parameters across multiple client devices.

[0006] Preferably, the full-duplex communication link is a communication link established based on the WebSocket protocol; and / or, the status parameters include audio equalizer parameters.

[0007] Preferably, establishing a full-duplex communication link between multiple clients and the synchronization server includes: The client initiates a connection request, which includes the user identifier, device identifier, and authentication information; After the synchronization server verifies the authentication information, it registers the current connection session to the connection state management library based on the user identifier and device identifier to establish a user-level session index. The synchronization server sends device connection status notifications to other online clients corresponding to the user based on the user identifier.

[0008] Preferably, after establishing full-duplex communication links between multiple clients and the synchronization server, a bidirectional heartbeat keep-alive mechanism is also included: Establish a two-way heartbeat keep-alive mechanism between the client and the synchronization server; When the client detects an anomaly based on this mechanism, it triggers an automatic reconnection process; Furthermore, the synchronization server continuously monitors the client's connection status and, upon determining that the connection has failed, proactively closes the connection and releases resources.

[0009] Preferably, generating the incremental update dataset containing version metadata and sending it to the synchronization server includes: Based on a predefined standardized parameter data structure, determine the target parameter item corresponding to the adjustment operation and its changed value; Generate differentiated update data containing path identifiers for locating target parameters, changed values, and version evolution information; The differentiated update data is sent to the synchronization server as the incremental update dataset.

[0010] Preferably, the conflict detection and adjudication based on the version metadata includes: Parse the version evolution information in the incremental update dataset; The version evolution information is compared with the version evolution information of the current global master parameter state for consistency. If a concurrent operation conflict is detected based on the comparison results, an automatic conflict resolution will be performed according to the preset conflict resolution strategy. The global master parameter status is updated based on the ruling, and the status change is synchronized to the relevant clients.

[0011] Preferably, the preset conflict resolution strategy includes: Conflict detection is performed based on multi-version state vectors, wherein the version evolution information includes vector data representing the modification history of each client; When concurrent modifications to the same parameter path are detected, priority decision is made based on operation timing. The priority decision is achieved by comparing the operation timing identifiers associated with the concurrent modification, and the final effective change is determined based on the comparison result to update the global master parameter state.

[0012] Preferably, the step of the synchronization server generating a synchronization update instruction based on the updated global master parameter status and distributing it in real time to at least one associated second client via the corresponding communication link includes: Based on the updated global master parameter status, a synchronization update instruction containing changed parameter information and an updated version identifier is generated; Based on the user identifiers associated with the incremental update dataset, determine the list of associated clients that need to be synchronized; The synchronization update command is distributed in real time to at least one second client in the associated client list via a full-duplex communication link.

[0013] Preferably, before generating the synchronization update instruction, the method further includes: The synchronization server performs a validity check on the received incremental update dataset. The validity check includes verifying the consistency between the base version identifier carried by the dataset and the current version identifier of the global master parameter status. After the verification is successful, the parameter changes in the incremental update dataset are applied to update the global master parameter state.

[0014] Preferably, the process of receiving the synchronization update instruction by the second client further includes a fault tolerance mechanism: Perform data integrity verification on the received synchronization update command; When the full-duplex communication link is interrupted, a recovery process including intelligent reconnection and local operation caching is executed; After the connection is restored or at a critical node, a consistency verification between the local state and the global master parameter state is performed.

[0015] Preferably, the data integrity verification and consistency verification include: Calculate the first check value of the received data and compare it with the second check value carried in the synchronization update instruction. If they do not match, trigger data retransmission. After the connection is established or restored, the first summary information of the global master parameter status maintained by the synchronization server is obtained and compared with the second summary information of the local status. If they are inconsistent, full status synchronization is triggered to correct the local status. The recovery process includes: automatic reconnection based on a backoff delay strategy, wherein the reconnection waiting time increases with the number of failures; During connection interruption, local parameter change operations are serialized and cached in the synchronization queue; After the connection is restored, the operations in the queue to be synchronized are sent in batches to the synchronization server for synchronization.

[0016] As a preferred option, performance optimization and multi-device expansion collaboration steps are also included: When transmitting synchronous data that includes multiple parameter changes, enable the data compression mechanism; The synchronization server supports cloud-based preset management, enabling the creation, storage, and real-time synchronous loading of named configurations across devices; In addition, a multi-terminal collaborative interaction mode is introduced, which can synchronize and visualize the operation status of each client in real time when multiple clients access the same configuration session.

[0017] A second aspect of the present invention provides a cross-terminal device status parameter synchronization system, including a first client, a second client, and a synchronization server; The first client, the second client, and the synchronization server are connected via a full-duplex communication link; The first client is used to generate an incremental update dataset containing version metadata and send it to the synchronization server in response to the adjustment operation of the status parameters; The synchronization server is used to receive the incremental update dataset, and perform conflict detection and adjudication based on the version metadata to update the global master parameter state; according to the updated global master parameter state, it generates a synchronization update instruction and distributes it to at least one associated second client in real time through the corresponding communication link; The second client is used to receive and parse the synchronization update instruction to apply parameter changes locally and achieve real-time consistency synchronization of status parameters among multiple client devices.

[0018] A third aspect of the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the aforementioned method for synchronizing state parameters across terminal devices.

[0019] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the aforementioned method for synchronizing state parameters across terminal devices. Compared with the prior art, the present invention has the following advantages: This invention proposes a method for synchronizing state parameters across terminal devices, constructing a core architecture based on WebSocket full-duplex communication, incremental updates, and vector clock version control. Through a real-time synchronization model, parameter changes are broadcast to all associated devices with millisecond-level latency, solving the pain points of traditional solutions such as high synchronization latency, concurrency conflicts, and network sensitivity. Specifically, this is reflected in: 1. Build a real-time synchronization channel for millisecond-level cross-device experience: Employ the WebSocket protocol to establish a persistent full-duplex link, replacing inefficient HTTP polling. Implement user-level session indexing through a connection state management library, combined with bidirectional heartbeat keep-alive and intelligent reconnection mechanisms, to ensure high link availability. Parameter adjustments on any device can be synchronized to all online devices within 100 milliseconds, achieving "zero-perceptible" latency synchronization.

[0020] 2. Innovative incremental update and conflict resolution mechanisms ensure strong data consistency: A standardized parameter structure and a JSONPath-based incremental update protocol are designed, synchronizing only changes and reducing single-transmission volume by over 87%. A vector clock algorithm is introduced for version management, and the server automatically detects concurrent conflicts and resolves them according to a preset strategy, ensuring linear evolution of the system state when multiple devices operate simultaneously and achieving eventual data consistency.

[0021] 3. A multi-layered fault-tolerance and self-healing system is designed to ensure high reliability: intelligent reconnection is achieved through an exponential backoff algorithm; local queues are used to cache operations during network outages, and automatic batch synchronization is performed after recovery. Transport layer CRC32 checksum and application layer state hash verification are added to build end-to-end reliability assurance, achieving system availability of over 99.9%.

[0022] 4. Supports cloud collaboration and performance expansion: The expansion supports preset cloud management and real-time synchronous loading, introduces a multi-device collaborative interaction mode, can display the operation status of each device in real time, and supports collaborative editing. Combined with message compression optimization, system resource consumption is reduced by 30%, creating a seamless cross-device collaborative environment for users. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the method for synchronizing status parameters across terminal devices in this embodiment; Figure 2 This is a schematic diagram of the cross-terminal device status parameter synchronization device in this embodiment; Figure 3This is a schematic diagram of one embodiment of the computer device in this example. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Example 1 For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 This invention proposes a method for synchronizing state parameters across terminal devices, applicable to a system architecture including a first client, a second client, and a synchronization server. The method specifically includes the following steps: Step S1: Establish full-duplex communication links between multiple clients and the synchronization server. This step aims to establish a real-time, bidirectional communication channel between each user terminal and the synchronization server, providing a foundation for subsequent state synchronization. The specific implementation process includes two main stages: client connection initialization and server connection verification and session management. The full-duplex communication link is established based on the WebSocket protocol.

[0026] In one embodiment, step S1 specifically involves establishing a WebSocket connection channel, client connection initialization, and server-side connection verification and session management. The detailed process is as follows: The client initiates a connection request, which carries a user identifier, a device identifier, and authentication information; after the synchronization server verifies the authentication information, it registers the current connection session in the connection state management library based on the user identifier and the device identifier to establish a user-level session index; the synchronization server sends device connection status notifications to other online clients corresponding to the user based on the user identifier.

[0027] In this embodiment, step S101: Client connection initialization: When a user launches and logs in to the application on the App or Web client, the client immediately initiates a WebSocket connection request. The connection address format is: wss: / / sync.domain.com / eq-sync?userId={userId}&deviceId={deviceId}&token={authToken}. Here, userId identifies the user, deviceId uniquely identifies the current device terminal (App or Web browser), and token is used for authentication. The client carries the protocol version number (e.g., v1.0) when establishing the connection so that the server can perform a compatibility check.

[0028] For example, when a user opens an audio application on an iPhone app, the app retrieves the locally stored userId="user_123456" and the deviceId generated from the device fingerprint="ios_device_abc", while also obtaining a valid token from the login session. It then assembles a WebSocket connection URL as wss: / / sync.wiim.com / eq-sync?userId=user_123456&deviceId=ios_device_abc&token=eyJhbGc... The app's WebSocket client library initiates a connection handshake, sends an HTTP upgrade request carrying the Upgrade:websocket and Connection:Upgrade headers, completes the protocol upgrade, and thus establishes a WebSocket connection.

[0029] In this embodiment, step S102: Server-side connection verification and management: After receiving a connection request, the WebSocket server first verifies the validity of the token, including but not limited to signature verification and expiration time check. After successful verification, the server registers the connection in the in-memory connection pool, indexed using a composite key (userId, deviceId). The server assigns a unique connectionId to each connection and records the connection establishment timestamp. Simultaneously, the server broadcasts a device online notification to all other online devices of the user, with the message format as follows: { "type":"device_online", / / Message type: Indicates this is a notification of a change in device connection status. "deviceId":"ios_device_abc", / / Device identifier: uniquely identifies the currently online device (generated and registered by the client). "deviceType":"iOSApp", / / Device type: Describes the device platform or client type, used for front-end display or business logic differentiation. "timestamp":1702345678900 / / Timestamp: The time the event occurred (Unix millisecond timestamp) generated by the server, used to ensure time sequence. } For example, the server maintains a Redis cluster as a distributed connection registry. When user_123456's iPhone device successfully connects, the server writes the following key-value pair to Redis: eq_connections:user_123456:ios_device_abc->{connectionId:"conn_001",serverId:"server_01",connectedAt:1702345678900}. Simultaneously, the server queries other online connections for the same user and finds that the web device "web_device_xyz" is also online. It then sends a device online notification via its WebSocket connection, and the web interface displays a "iPhone connected" message in real time.

[0030] Because WebSockets are persistent connections, they may unexpectedly disconnect in real-world network environments due to network fluctuations, device hibernation, or other reasons. To ensure the continuous availability of the communication link and provide a stable foundation for the subsequent step S2 (state parameter synchronization), a connection keep-alive and exception handling mechanism must be introduced after the connection is established.

[0031] In one embodiment, step S102: Establish a two-way heartbeat keep-alive mechanism: Two-way heartbeat keep-alive: A two-way heartbeat keep-alive mechanism is established between the client and the synchronization server. To maintain the stability of the long-lived connection, the client periodically sends ping messages to the server, and the server immediately replies with a pong message upon receiving the message. This mechanism is used to continuously probe the connection's activity; the client sends a ping message every 30 seconds, and the server immediately replies with a pong message upon receiving the message.

[0032] Client-side anomaly detection and automatic reconnection: When the client detects an anomaly based on this mechanism, an automatic reconnection process is triggered. The reconnection process includes: firstly attempting to re-establish the WebSocket connection; if this fails, switching to an alternative communication mode (such as HTTP short polling) to temporarily obtain the latest status, and periodically retrying the WebSocket connection to ensure that critical states are temporarily synchronized, while continuing to periodically retry the WebSocket connection in the background until recovery; the synchronization server monitors the client's connection status and actively closes the connection when it determines that the connection has failed; when the WebSocket connection is restored, the client synchronizes the state changes that occurred during the connection interruption with the synchronization server; for example, the client sends a ping message every 30 seconds, and the server immediately replies with a pong message upon receiving it. If the client does not receive a pong response for three consecutive times (90 seconds), it determines that the connection is broken and automatically triggers the reconnection logic.

[0033] Server-side connection status monitoring: The synchronization server continuously monitors the client's connection status and proactively closes the connection and releases resources when it determines that the connection has failed. For example, the server also monitors the client's heartbeat; if no messages, including pings or business messages, are received within 120 seconds, the connection is proactively closed and resources are released.

[0034] State synchronization after connection restoration: When the WebSocket connection is restored, the client needs to send a synchronization request to the synchronization server to obtain state parameter changes that may have been missed during the connection interruption, so as to ensure eventual consistency of the state.

[0035] For example, when a user uses the app on the subway, the network signal is unstable. The app client sends a ping message at 60 seconds, but due to network fluctuations, it still hasn't received a pong response after 90 seconds. The client determines that the connection may have been broken and immediately initiates a reconnection process: first, it attempts to re-handshake using the original connection parameters; if that fails, it falls back to HTTP polling mode to temporarily obtain the latest EQ configuration, while retrying the WebSocket connection every 5 seconds. When the subway exits the tunnel and the signal recovers, the WebSocket connection is successfully re-established, and the client sends a synchronization request to retrieve any missed configuration changes. Through these steps, the system not only establishes a real-time communication link but also ensures its robustness and high availability in complex network environments through heartbeat keep-alive and intelligent reconnection mechanisms.

[0036] Step S2: In response to the adjustment operation of the state parameters, the first client generates an incremental update dataset containing version metadata and sends it to the synchronization server. The state parameters include audio equalizer parameters. This step is the core of state synchronization, aiming to efficiently, accurately, and orderly synchronize parameter changes at a single point to the server, laying the foundation for subsequent multi-device distribution. To achieve accurate synchronization and resolve conflicts that may be caused by concurrent modifications on multiple devices, this embodiment introduces an ordered change management based on version numbers and an incremental data description mechanism, thereby avoiding bandwidth waste caused by transmitting complete configuration data.

[0037] In one embodiment, step S2, generating an incremental update dataset containing version metadata and sending it to the synchronization server, includes: Step S201: Based on a predefined standardized parameter data structure, determine the target parameter item corresponding to the adjustment operation and its changed value. Specifically, the predefined standardized parameter data structure includes at least a configuration identifier, version number, preset name, activation status, and a frequency band parameter array. Each element in the frequency band parameter array corresponds to a frequency band and includes at least a frequency center point, gain value, and quality factor. In response to an adjustment operation on a parameter field (such as gain value or center frequency) of a specific frequency band in the audio equalizer parameters, the client obtains the new adjusted value and the currently stored baseline version number. Subsequently, based on the hierarchical position of the parameter field in the audio equalizer parameter data structure, a change path in JSONPath format is generated.

[0038] In this embodiment, during the EQ parameter data structure design in step S2, a unified EQ parameter data structure is defined to support a 10-band parameter equalizer. Each band includes: frequency (Hz), gain (dB, range -12 to +12), and quality factor Q (0.5 to 5.0). The complete configuration object includes: { "configId":"uuid", / / Unique configuration identifier: A globally unique ID generated using a UUID, used to accurately locate and operate specific equalizer configurations within the system. "userId":"user_123456", / / User ID: The user ID to which this configuration belongs, used for data isolation and ownership determination in a multi-tenant environment. "deviceId":"ios_device_abc", / / Last operating device identifier: Records the terminal device ID that last modified this configuration. "timestamp":1702345678900, / / Last update timestamp: Records the last time this configuration was modified (Unix millisecond timestamp), used to determine the order of operations. "version": 5, / / Current version number: A monotonically increasing integer representing the current revision of this configuration. This is the core basis for optimistic locking control and resolving conflicts caused by concurrent modifications from multiple devices. "presetName":"BassBoost", / / Preset name: A user-defined, easily identifiable name for this set of parameters. "bands":[ / / Band parameter array: An array containing 10 band objects, each defining the core parameters of an adjustable filter.] {"frequency":32,"gain":6.0,"q":1.0}, / / Frequency Band 1: Center frequency 32Hz, gain +6.0dB, quality factor 1.0 {"frequency":64,"gain":4.5,"q":1.0}, / Band 2: Center frequency 64Hz {"frequency":125,"gain":2.0,"q":1.0}, / / Frequency Band 3: Center frequency 125Hz {"frequency":250,"gain":0.0,"q":1.0}, / / Frequency Band 4: Center frequency 250Hz {"frequency":500,"gain":-1.0,"q":1.0}, / / Band 5: Center frequency 500Hz, gain -1.0dB {"frequency":1000,"gain":-2.0,"q":1.0}, / / Frequency Band 6: Center frequency 1kHz {"frequency":2000,"gain":0.0,"q":1.0}, / / Frequency Band 7: Center frequency 2kHz {"frequency":4000,"gain":1.5,"q":1.0}, / / Band 8: Center frequency 4kHz {"frequency":8000,"gain":3.0,"q":1.0}, / / Frequency Band 9: Center frequency 8kHz {"frequency":16000,"gain":4.0,"q":1.0} / / Band 10: Center frequency 16kHz ], "enabled":true / / Enabled status: Boolean value indicating whether this set of equalizer parameters is currently active and applied to the audio output. } For example, a user creates a custom EQ preset named "Jazz Optimization" in the app, focusing on enhancing mid-range vocals and high-frequency details. The user adjusts the 1kHz gain from 0 to +3dB and the 4kHz gain from 0 to +2dB. The app immediately constructs the aforementioned JSON object, where the configId is generated using the UUIDv4 algorithm as "a1b2c3d4-e5f6-7890-abcd-ef1234567890", the timestamp records the current millisecond timestamp, and the version is initially set to 1. This configuration object is stored locally in IndexedDB as a baseline version.

[0039] Step S202: Generate differentiated update data containing path identifiers for locating target parameter items, changed values, and version evolution information; the client constructs an incremental update data packet, which includes at least: operation type, the changed path, the new value, configuration identifier, device identifier, timestamp, the base version number, and a target version number generated incrementally based on the base version number. Finally, the incremental update data packet is encapsulated into the incremental update dataset and sent to the synchronization server through the established WebSocket full-duplex communication link.

[0040] To optimize transmission efficiency, an incremental update protocol is designed. Only the changed parameter fields are transmitted, rather than the complete configuration. To maximize network transmission efficiency and support fine-grained version control, when the client detects a parameter adjustment, it does not send the entire configuration object, but instead constructs and sends an incremental update data packet that only describes the changed parts.

[0041] Its generation logic is as follows: Capture change context: In response to the adjustment operation of a specific frequency band parameter of the audio equalizer, the client immediately obtains the new value after adjustment and reads the current base version number (baseVersion) of this configuration stored locally. Generate location path: Based on the precise hierarchical position of the modified parameter in the standardized data structure, a change path in JSONPath format is generated, such as $.bands[3].gain, to unambiguously point to the target field. Build incremental package: Integrate the above information to build a lightweight incremental update data package. The core fields of this package include: operation type (update / delete), change path (JSONPath format), base version (baseVersion), target version (targetVersion), new value (value), configuration identifier (configId), device identifier (deviceId), and timestamp.

[0042] For example, the user continues to adjust the aforementioned "Jazz Optimization" preset in the app, reducing the gain of the 250Hz band from 0 to -2dB. Instead of sending the full 10 bands of data, the app constructs incremental packets: { "type":"eq_update", / / Message type: EQ configuration update "operation":"update", / / Operation type: update "configId":"a1b2c3d4-e5f6-7890-abcd-ef1234567890", / / Target configuration ID "baseVersion":1, / / Change the version based on "targetVersion":2, / / The new version to be achieved after the change "changes":[ / / Change array] { "path":"$.bands[3].gain", / / JSONPath locates the path "value": -2.0 / / New gain value } ], "timestamp":1702345680150, / / Time when the change occurred "deviceId":"ios_device_abc" / / The device that initiated the change } The incremental packet is approximately 200 bytes in size, reducing the transmission volume by 87% compared to the full configuration's 1.5KB. After generation, the client immediately sends this packet via its active WebSocket connection with the synchronization server. Step S203: The differentiated update data is sent to the synchronization server as the incremental update dataset.

[0043] Step S3: The synchronization server receives the incremental update dataset and performs conflict detection and adjudication based on the version metadata to update the global master parameter state. This step is the central processing stage of state synchronization, designed to ensure the consistency and orderliness of data changes under concurrent operation of multiple devices. The synchronization server, as the sole source of fact, is responsible for receiving incremental updates from each client and maintaining an authoritative, linear history of the global master parameter state evolution through a rigorous conflict detection and automatic adjudication mechanism, thereby reliably distributing the agreed-upon results to all relevant devices.

[0044] In one embodiment, step S3 specifically includes the following core process: the synchronization server receives and parses the version evolution information in the incremental update dataset; compares the version evolution information with the version evolution information of the current global master parameter state; if a concurrent operation conflict is detected according to the comparison result, it automatically makes a decision according to a preset conflict resolution strategy; updates the global master parameter state according to the resolution result, and synchronizes the state change with the relevant clients.

[0045] To support accurate conflict identification in high-concurrency scenarios, this embodiment uses a vector clock algorithm as the cornerstone of version management. The specific implementation is as follows: Version vector maintenance: Conflict detection is performed based on multi-version state vectors, where the version evolution information includes vector data representing the modification history of each client. The synchronization server uses the VectorClock algorithm to maintain a logical clock system for each user. The version metadata carried in the global master parameter state includes a version vector, which is a set of key-value pairs. The key is the device identifier (deviceId), and the value is the number of logical modifications that have occurred on that device. For example, the version vector {"ios_device_abc":5, "web_device_xyz":3} indicates that the modification history from the iOS device is counted as 5 times, and the modification history from the Web device is counted as 3 times.

[0046] Receiving and parsing: When detecting concurrent modifications to the same parameter path, a priority adjudication based on the operation timing sequence is adopted; when receiving an incremental update data set, parse the version vector in the incremental update data set and compare the version vector with the version vector of the current global main parameter status; when the synchronization server receives an incremental update data set from a certain client (such as device_A), first parse the data packet and extract the carried base version vector (baseVector) and target version information.

[0047] Vector comparison and conflict determination: The priority adjudication is implemented by comparing the operation timing identifiers associated with the concurrent modifications, and the final effective change is determined according to the comparison result to update the global main parameter status. If a concurrent modification conflict for the same parameter path is detected, the last writer wins strategy is adopted for adjudication according to the timestamp in the incremental update data set to update the global main parameter status; send a conflict notification and the latest parameter status to the initiating end of the non-winning change so that the initiating end of the change overwrites the local parameters. The server compares the extracted baseVector with the latest version vector (currentVector) saved in the current global main parameter status. Conflict detection follows the comparison rules of vector clocks: Mergeable (no conflict): If baseVector is "prior to" currentVector in the partial order relationship of the vector clock (that is, the count value of each device in baseVector is less than or equal to the corresponding value in currentVector), it means that this update is based on a known old state and can be directly applied.

[0048] Concurrent conflict: If baseVector and currentVector are not comparable (that is, there exists a device i such that baseVector[i]>currentVector[i], and at the same time there exists a device j such that baseVector[j]<currentVector[j]), it is determined that a concurrent modification conflict has occurred. This means that when the client was preparing its update, other devices had submitted modifications that it was not aware of.

[0049] When concurrent modifications to the same parameter path are detected, the system automatically adjudicates the conflict using a preset, deterministic conflict resolution strategy to ensure consistency of results. In this embodiment, the strategy is a priority-based adjudication strategy (the last writer wins). Priority adjudication is achieved by comparing the operation timing identifiers associated with the concurrent modifications (i.e., the timestamp field in the incremental update data packet). The server compares the timestamps of each conflicting update data packet, determines the change with the latest timestamp as the winner, and updates the global master parameter state accordingly. Simultaneously, it updates the global version vector, incrementing the count value corresponding to the winning device by 1. The server sends a conflict notification to the non-winning change initiator (i.e., the device whose update was overwritten due to the conflict). This notification contains the latest global parameter state and version evolution information. Upon receiving the notification, the client automatically overwrites its local parameters with the authoritative state issued by the server and prompts the user on the UI as appropriate that "the configuration has been updated by another device" to ensure that the final state of all devices is consistent with the server.

[0050] For example, a user adjusts the 32Hz gain to +8dB on the iPhone app (version vector becomes {ios:6,web:3}), and simultaneously adjusts the same frequency band to +5dB on the web app (version vector becomes {ios:5,web:4}). When the two incremental packets arrive at the server, the server compares the version vectors and finds a concurrent conflict: the iOS device's modification is based on version 5, but the web device has been modified to version 4, and both have modified the same path. The server adopts a "last write wins" strategy, comparing the timestamp fields. Assuming the web device's timestamp is later, the +5dB modification from the web device is retained, and a conflict notification and the latest configuration are sent to the iOS device. The iOS device's local EQ parameters are overwritten with +5dB, and the user is notified that "the configuration has been updated by another device."

[0051] Step S4: The synchronization server generates a synchronization update instruction based on the updated global master parameter status and distributes it in real time to at least one associated second client via the corresponding communication link. This step is a crucial distribution link in state synchronization, aiming to efficiently and reliably distribute the final state change, which has undergone conflict resolution, to all relevant devices in real time, ensuring the eventual consistency of multi-terminal views. The synchronization server plays the role of a central scheduling and distribution hub, ensuring that the state change of any device is reflected instantly and accurately on all other online devices of the user.

[0052] In one embodiment, step S4 is specifically implemented by the following process: Step S401: Based on the updated global master parameter state, generate a synchronization update command containing changed parameter information and an updated version identifier; when the user drags the EQ slider to adjust the gain value in the App, the App adopts an anti-jitter strategy: synchronization is triggered only 300ms after the user stops operating. The App constructs an incremental update package and sends it to the server via a WebSocket connection. Before sending, the version number is updated locally and marked as "synchronizing" to prevent duplicate sending.

[0053] For example, a user quickly adjusts the 64Hz band slider in the app's EQ interface, generating over 30 intermediate values ​​as they drag it from +4dB to +7dB. The app's anti-jitter logic detects no new activity within 300ms and then builds an update packet with the final value of +7dB. Before sending, the app updates its local configuration version from 6 to 7 and marks the band as "syncing" in memory; a rotating synchronization icon is displayed next to the band slider on the UI. The update packet is sent via WebSocket. { "type":"eq_update", / / Message type: Indicates that this message is an audio equalizer parameter update operation. "operation":"update", / / Operation type: Indicates the specific operation for this update, such as "update" for update, "create" for create, and "delete" for delete. "configId":"a1b2c3d4...", / / Configuration identifier: A globally unique ID for the equalizer configuration that needs to be updated. "baseVersion":6, / / Base version number: The current version number configured locally when this update is initiated, used for optimistic locking control. "targetVersion":7, / / Target version number: The expected new version number after the update (usually baseVersion + 1) "changes":[ / / Changes array: An array containing one or more specific changes, each describing a modification to a parameter.] {"path":"$.bands[1].gain","value":7.0}], / / Change path: JSONPath format, used to precisely locate the field in the data structure that needs to be modified; Change value: The new value of this parameter after the change. "timestamp":1702345685500, / / Timestamp: Local time (Unix millisecond timestamp) when the client generated this update. "deviceId":"ios_device_abc" / / Device identifier: A unique identifier for the client device that initiated this update. } Step S402: Determine the list of associated clients to be synchronized based on the user identifier associated with the incremental update dataset; after receiving the update package, the server performs the following steps: verify whether baseVersion matches the current version on the server; if they do not match, it is determined to be an expired update; apply the changes to the main configuration object in the server memory; broadcast the update package to all other online devices of the user; asynchronously persist the latest configuration to the database (MongoDB); reply with an acknowledgment message (ACK) to the sending device.

[0054] For example, the server receives the 64Hz gain update packet from the aforementioned iOS device, checks that baseVersion=6 matches the server's main configuration version, and the verification passes. The server updates the 64Hz gain field in memory from +4dB to +7dB, incrementing the version number to 7. Subsequently, the server queries the connection pool and finds that the user also has a web-based device online (deviceId="web_device_xyz"), constructing a broadcast message: { "type":"eq_sync", "source":"ios_device_abc", "configId":"a1b2c3d4...", "version":7, "changes":[{"path":"$.bands[1].gain","value":7.0}], "timestamp":1702345685500 } The message is sent via a WebSocket connection on the web device. Simultaneously, the server starts an asynchronous task to write the complete configuration to MongoDB: `db.eq_configs.updateOne({configId:"a1b2c3d4..."},{$set:{version:7,"bands.1.gain":7.0,updatedAt:ISODate("2023-12-12T10:34:45.500Z")}})`. Finally, an ACK is sent to the iOS device: `{"type":"ack","targetVersion":7,"status":"success"}`. Upon receiving this, the iOS device removes the "syncing" flag, and the synchronization icon changes to a checkmark, indicating success.

[0055] Step S403: The synchronization update command is distributed in real time to at least one second client in the associated client list via a full-duplex communication link. After receiving the update message broadcast by the server via a WebSocket connection, the Web client parses the changes array, uses JSONPath to locate the DOM element that needs to be updated, and dynamically updates the UI. If the user is currently operating the EQ interface, the Web client will cache the received update first and apply it after the user finishes operating, avoiding conflicts and UI jitter.

[0056] For example, after receiving a 64Hz gain update message, the WebSocket client parses the change path and locates the corresponding slider control and numerical display element. It checks if the slider is currently being dragged by the user; if not, it immediately performs the update: setting the new slider value, updating the numerical display, triggering an audio engine update, and adding a synchronization marker to achieve a smooth animation transition. The user sees the 64Hz slider smoothly move from +4dB to +7dB on the Web interface, with the new parameters applied to the audio output in real time. The entire process has a delay of approximately 80ms.

[0057] The specific implementation method is as follows: 1) Receiving Verification and State Update: The synchronization server verifies whether the base version number in the incremental update dataset is consistent with the version evolution information of the global master parameter state, ensuring linear state evolution. If the verification is consistent, the parameter changes are applied to the global master parameter state in memory, and the version number is incremented to generate the updated version identifier.

[0058] 2) Associated Client Identification: The server queries the connection state management database based on the user's identifier, excludes the first client that initiated the update from all online device sessions of that user, and determines the list of associated online devices that need to be synchronized.

[0059] Furthermore, this embodiment introduces a synchronization distribution priority scheduling algorithm. This algorithm aims to intelligently evaluate the real-time status of each client in the list, dynamically calculate its synchronization priority, and thus optimize the distribution order and server resource allocation. While ensuring eventual consistency, it prioritizes ensuring that core devices receive the best synchronization experience. To quantitatively evaluate the synchronization urgency and efficiency of each client (denoted as the i-th client), its synchronization priority value P is defined. i The calculation formula is as follows: , where P i This represents the synchronization priority value; a higher value indicates that the client should be processed first in this synchronization distribution. i This is the network quality factor, with a value range of [0, 1]. It is calculated by the server based on historical monitoring data (such as average round-trip time (RTT) and packet loss rate). A higher value indicates a better network condition. i The activity level of the device, ranging from [0, 1], reflects the recent operating frequency of the device; S i This is the session stability coefficient, ranging from [0, 1]. It is calculated based on the duration of the current connection session and the number of historical abnormal reconnections. A higher value indicates a more stable and reliable connection. i The network latency normalization value ranges from [0, 1] and is mapped to the normalized interval based on the latest latency detected by the server to the client. w1, w2, and w3 are weighting coefficients, which are constants that satisfy w1+w2+w3=1. They are used to adjust the relative importance of network quality, device activity, and session stability in the evaluation and can be configured according to specific business scenarios. k is the latency penalty factor, which is used to control the degree of priority decay of high-latency devices.

[0060] For example, suppose a user has three online devices that need to be synchronized, and set weight coefficients w1=0.4, w2=0.3, w3=0.3, and delay penalty factor k=2, as shown in Table 1 below.

[0061] Table 1 Example of Priority Calculation According to calculations, the synchronization distribution order is iOS phones → web browsers → tablets. The server prioritizes pushing synchronization commands to iPhones with good network quality and high activity levels, and processes tablets with higher network latency and lower activity levels last. By introducing this algorithm, the overall synchronization completion time is reduced by prioritizing the distribution of synchronization commands to devices with good network quality and high activity levels. In high-concurrency scenarios, the server can dynamically allocate bandwidth and processing resources based on priority values, avoiding resource waste on inactive or unstable devices. Active devices that users are currently operating receive the latest status first, reducing operation waiting time and the perception of status inconsistencies. Devices with high network latency or unstable connections are appropriately prioritized, reducing the risk of synchronization blocking due to waiting for responses.

[0062] 3) Constructing and Broadcasting Synchronization Commands: The server constructs a lightweight synchronization update command, which includes the source device identifier, configuration identifier, updated version number, change details array, and server processing timestamp. The command is then broadcast in real-time to each secondary client via a WebSocket connection.

[0063] 4) Persistence and Acknowledgment Feedback: After completing the memory update and real-time broadcast, the server initiates an asynchronous persistence task to store the state in the database. This operation runs in parallel with the broadcast and does not block the synchronization link. Finally, an acknowledgment message carrying the updated version number is returned to the first client.

[0064] Step S5: The second client receives and parses the synchronization update instruction to apply the parameter changes locally, achieving real-time consistency synchronization of state parameters across multiple client devices. This step is the terminal execution and consistency guarantee link in the state synchronization process. Its goal is to ensure that the parameter state changes distributed by the synchronization server, which have achieved global consistency, can be reliably received, accurately parsed, and securely applied by all relevant second clients (i.e., other online devices that did not initiate the change), ultimately achieving real-time synchronization and unification of multi-terminal states. To achieve this goal, this step not only defines the standard process for instruction reception and application but also integrates a complete client-side fault tolerance and recovery mechanism to cope with complex network environments and system anomalies.

[0065] In one embodiment, step S5 is specifically implemented by the following process: The synchronization server validates the received incremental update dataset, verifying that the base version identifier it carries matches the current version identifier of the global master parameter state. If the validation passes, the application makes the changes and constructs a synchronization update command. Simultaneously, an asynchronous persistence task is initiated to store the updated state in the database, and an operation confirmation notification is returned to the first client.

[0066] In this embodiment, when the client detects a WebSocket connection failure, it immediately enters reconnection mode. An exponential backoff algorithm is used: the first reconnection is delayed by 1 second, and the delay doubles for each subsequent failure, with a maximum delay of 60 seconds. During reconnection, the client caches user operations in a local queue, synchronizing them in batches once the connection is restored.

[0067] For example, a user experiences a brief WiFi outage while using the app, causing the WebSocket connection to close. The app starts a reconnection timer; after 1 second, the first reconnection attempt fails, so the delay is set to 2 seconds. During this time, the user adjusts the gain of both the 125Hz and 500Hz frequency bands. The app serializes these operations and stores them in a local synchronization queue. Each record in the queue includes the changed path, the changed value, and a timestamp. After 5 seconds, WiFi is restored, the app successfully reconnects, and immediately sends a batch synchronization request. The request includes the message type, configuration identifier, base version number, operation array, and device identifier. The server receives the request, applies the operations in timestamp order, increments the version number, and broadcasts it to other devices.

[0068] In one embodiment, the receiving of the synchronization update instruction by the second client further includes a fault tolerance mechanism: performing data integrity verification on the received synchronization update instruction; executing a recovery process including intelligent reconnection and local operation caching when the full-duplex communication link is interrupted; and performing consistency verification between the local state and the global master parameter state after connection restoration or at critical nodes. The data integrity verification and consistency verification include: calculating a first checksum of the received data and comparing it with a second checksum carried in the synchronization update instruction; if they are inconsistent, data retransmission is triggered; after connection establishment or restoration, obtaining the first digest information of the global master parameter state maintained by the synchronization server and comparing it with the second digest information of the local state; if they are inconsistent, full state synchronization is triggered to correct the local state. To prevent network transmission errors or tampering by intermediate nodes, each update packet carries a CRC32 checksum. Upon receiving a message, the server and client first verify the checksum; if they do not match, the message is discarded and a retransmission is requested. Furthermore, after each successful reconnection, the client actively requests the hash value of the complete configuration and compares it with the locally calculated hash; if they are inconsistent, the full configuration is retrieved for correction.

[0069] For example, the app sends an update packet containing an 8kHz band gain of -5dB, appended with a CRC32 checksum. Due to a network transmission error, the server receives a garbled gain field, recalculates the CRC32, and finds it doesn't match the checksum at the end of the packet. The server immediately sends a checksum failure message to the app and requests a retransmission. Upon receiving the error response, the app retrieves the original update packet from its local cache and retransmits it.

[0070] Meanwhile, the app sends a hash verification request each time it reconnects, and the server replies with the SHA256 hash value of the current configuration. The app calculates the local configuration hash and compares it. If an inconsistency is found, the app immediately requests the full configuration. The server returns a complete configuration object, which the app uses to overwrite the local configuration and re-render the UI.

[0071] Furthermore, the recovery process includes: automatic reconnection based on a backoff delay strategy, wherein the reconnection waiting time increases with the number of failures; during the connection interruption, local parameter change operations are serialized and cached in a queue to be synchronized; after the connection is restored, the operations in the queue to be synchronized are sent in batches to the synchronization server for synchronization.

[0072] In this embodiment, the server cluster adopts a master-slave architecture, with slave nodes automatically taking over when the master node fails. Client connection URLs are configured with multiple server addresses; if the preferred address fails, a backup address is automatically attempted. All connection states and user configurations are synchronized to all nodes in real time via Redis, ensuring that any node can provide complete service.

[0073] For example, the WebSocket server cluster consists of three nodes: server-01 (master node), server-02, and server-03 (slave node). A user's iOS device connects to server-01, and a web device connects to server-02. At some point, server-01 crashes due to a hardware failure, triggering the `onerror` event for all clients connected to that node (including the iOS device). The iOS device reads the list of backup servers from its configuration file and immediately attempts to connect to server-02. Server-02 reads the user's connection history and current configuration version from Redis and successfully takes over the connection. The user adjusts the EQ (Effective Keyless Response) on their iOS device, and the update packet is sent to server-02. Server-02 broadcasts this update to the web device also connected to it, achieving seamless failover. The user is unaware of the server switch, experiencing only a reconnection delay of approximately 2 seconds.

[0074] In one embodiment, the synchronization method further includes step S6: performance optimization and multi-device extended collaboration. Step S601: When transmitting synchronization data containing multiple parameter changes, enable the data compression mechanism to improve the transmission efficiency of the full-duplex communication link; for batch updates containing multiple frequency band changes, enable the WebSocket permessage-deflate compression extension. JSON messages are compressed using the DEFLATE algorithm before transmission; a typical EQ configuration compresses a complete JSON from 1.5KB to approximately 400 bytes, saving 73% of bandwidth. The client and server negotiate whether to enable compression during the handshake phase.

[0075] For example, when a user switches preset configurations on the App from "BassBoost" to "VocalEnhancement," the gain values ​​for all 10 frequency bands need to be updated simultaneously. The App builds a batch update package containing 10 changes, with the original JSON size being 1.2KB. When the WebSocket connection is established, the client sends a Sec-WebSocket-Extensions:permessage-deflate;client_max_window_bits header. The server confirms support for compression and restores the same header. During transmission, the App's WebSocket library automatically performs DEFLATE compression on the JSON string, resulting in only 320 bytes of compressed data. The server receives the data, decompresses it, restores it to the original JSON, and processes it. In a 4G network environment (uplink speed 2Mbps), uncompressed transmission takes approximately 5ms, while compressed transmission takes only 1.3ms, resulting in a 74% reduction in perceived latency for the user. Step S602: The synchronization server supports cloud-based preset management, enabling the creation, storage, and real-time synchronous loading of named configurations across devices; the extended system allows users to save EQ configurations as named presets and synchronize them to the cloud. Users can create, modify, or delete presets on any device, and the results are immediately synchronized across all devices. The preset list is pushed in real time via WebSocket, avoiding the delays of traditional API polling.

[0076] For example, after adjusting EQ parameters on the web interface, the user clicks the "Save Preset" button and enters a preset name. The web interface sends a preset creation message containing the preset identifier, name, full configuration, creation timestamp, and device identifier. The server stores the preset in the database and broadcasts it to all the user's online devices. The iOS app receives a notification in real time, automatically refreshes the preset list, and adds the option. When the user clicks the preset in the app, the app sends an application preset request, the server pushes the full configuration, and the slider on the app interface smoothly transitions to the new position after the app is applied—the entire process is completed within 1 second.

[0077] Step S603: Introduce a multi-terminal collaborative interaction mode. When multiple clients access the same configuration session, the operation status of each client is synchronized in real time and visualized. Introduce the "Collaborative Adjustment" feature, allowing multiple users or devices to view and adjust the same EQ configuration simultaneously. When this mode is enabled, all devices display the real-time cursor position, similar to an online collaborative document. Each device's operation is indicated by a different color, allowing other devices to see in real time who is adjusting which frequency band.

[0078] For example, a home user enables the "PartyMode" collaborative adjustment feature. The father configures the EQ settings on the living room stereo on his iPad, and the son simultaneously opens the same settings on his phone. The server adds both devices to a collaborative session and assigns color codes: blue for the iPad and green for the phone. The father starts adjusting the low-frequency bands, and the iPad sends an action event: { "type":"collab_cursor", "deviceId":"ipad_device_def", "bandIndex":0, "action":"drag_start", "timestamp":1702345710000 } The son's phone received the message in real time, and a small blue icon and the text "iPad is adjusting" appeared above the 32Hz band slider on the EQ interface. The father completed the adjustment and released the slider, and the phone received the final updated value and applied it. The son then adjusted the high-frequency band on his phone, and the iPad similarly displayed a green operation prompt in real time. The two collaborated to complete the overall EQ adjustment; the sound output from the speakers was the combined result of all adjustments, and all device interfaces were perfectly synchronized without any noticeable conflicts or delays.

[0079] This invention achieves true real-time bidirectional synchronization of EQ parameters across platforms through WebSocket full-duplex communication, incremental updates, version control, and intelligent conflict resolution mechanisms. The synchronization latency is less than 100 milliseconds, the data transmission volume is reduced by more than 90%, and it supports multi-device collaboration and automatic recovery from anomalies, providing users with a seamless and unified cross-platform audio adjustment experience.

[0080] Example 2 like Figure 2 As shown, based on the same inventive concept, this embodiment provides a cross-terminal device status parameter synchronization system, including a first client, a second client, and a synchronization server; The first client, the second client, and the synchronization server are connected via a full-duplex communication link; The first client is used to generate an incremental update dataset containing version metadata and send it to the synchronization server in response to the adjustment operation of the status parameters; The synchronization server is used to receive the incremental update dataset, and perform conflict detection and adjudication based on the version metadata to update the global master parameter state; according to the updated global master parameter state, it generates a synchronization update instruction and distributes it to at least one associated second client in real time through the corresponding communication link; The second client is used to receive and parse the synchronization update instruction to apply parameter changes locally, thereby achieving real-time consistency synchronization of status parameters among multiple client devices. The principle is described in Embodiment 1 and will not be repeated here.

[0081] Based on the same inventive concept, this embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the computer program, when executed by the processor, implements the steps of the cross-terminal device state parameter synchronization method described above.

[0082] Based on the same inventive concept, this embodiment provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the cross-terminal device state parameter synchronization method described above.

[0083] The computer device in this embodiment will be described in detail below from the perspective of hardware processing.

[0084] See Figure 3 As shown, the computer device includes a processor 100 and a memory 101. The memory 101 stores machine-executable instructions that can be executed by the processor 100. The processor 100 executes the machine-executable instructions to implement the above-described method for synchronizing state parameters across terminal devices.

[0085] further, Figure 3 The computer device shown also includes a bus 102 and a communication interface 103, with the processor 100, communication interface 103 and memory 101 connected via the bus 102.

[0086] The memory 101 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0087] The processor 100 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 100 or by instructions in software form. The processor 100 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 101, and the processor 100 reads the information in memory 101 and, in conjunction with its hardware, completes the method steps of the aforementioned embodiments.

[0088] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of a method for synchronizing state parameters across terminal devices.

[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0090] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for synchronizing status parameters across terminal devices, characterized in that, include: Establish full-duplex communication links between multiple clients and the synchronization server; The first client responds to the adjustment operation of the status parameters, generates an incremental update dataset containing version metadata, and sends it to the synchronization server; The synchronization server receives the incremental update dataset and performs conflict detection and adjudication based on the version metadata to update the global master parameter state; The synchronization server generates a synchronization update instruction based on the updated global master parameter status and distributes it in real time to at least one associated second client through the corresponding communication link; The second client receives and parses the synchronization update instruction to apply the parameter changes locally, thereby achieving real-time consistency synchronization of status parameters across multiple client devices.

2. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, The full-duplex communication link is a communication link established based on the WebSocket protocol; and / or, the status parameters include audio equalizer parameters.

3. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, Establishing full-duplex communication links between multiple clients and the synchronization server includes: The client initiates a connection request, which includes the user identifier, device identifier, and authentication information; After the synchronization server verifies the authentication information, it registers the current connection session to the connection state management library based on the user identifier and device identifier to establish a user-level session index. The synchronization server sends device connection status notifications to other online clients corresponding to the user based on the user identifier.

4. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, After establishing full-duplex communication links between multiple clients and the synchronization server, a bidirectional heartbeat keep-alive mechanism is also included: Establish a two-way heartbeat keep-alive mechanism between the client and the synchronization server; When the client detects an anomaly based on this mechanism, it triggers an automatic reconnection process; Furthermore, the synchronization server continuously monitors the client's connection status and, upon determining that the connection has failed, proactively closes the connection and releases resources.

5. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, The process of generating an incremental update dataset containing version metadata and sending it to the synchronization server includes: Based on a predefined standardized parameter data structure, determine the target parameter item corresponding to the adjustment operation and its changed value; Generate differentiated update data containing path identifiers for locating target parameters, changed values, and version evolution information; The differentiated update data is sent to the synchronization server as the incremental update dataset.

6. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, The conflict detection and adjudication based on the version metadata includes: Parse the version evolution information in the incremental update dataset; The version evolution information is compared with the version evolution information of the current global master parameter state for consistency. If a concurrent operation conflict is detected based on the comparison results, an automatic conflict resolution will be performed according to the preset conflict resolution strategy. The global master parameter status is updated according to the ruling, and the status change is synchronized to the relevant clients.

7. The method for synchronizing status parameters across terminal devices according to claim 6, characterized in that, The preset conflict resolution strategy includes: Conflict detection is performed based on multi-version state vectors, wherein the version evolution information includes vector data representing the modification history of each client; When concurrent modifications to the same parameter path are detected, priority decision is made based on operation timing. The priority decision is achieved by comparing the operation timing identifiers associated with the concurrent modification, and the final effective change is determined based on the comparison result to update the global master parameter state.

8. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, The step of the synchronization server generating a synchronization update instruction based on the updated global master parameter status and distributing it in real time to at least one associated second client via the corresponding communication link includes: Based on the updated global master parameter status, a synchronization update instruction containing changed parameter information and an updated version identifier is generated; Based on the user identifiers associated with the incremental update dataset, determine the list of associated clients that need to be synchronized; The synchronization update command is distributed in real time to at least one second client in the associated client list via a full-duplex communication link.

9. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, Before generating the synchronization update instruction, the following is also included: The synchronization server performs a validity check on the received incremental update dataset. The validity check includes verifying the consistency between the base version identifier carried by the dataset and the current version identifier of the global master parameter status. After the verification is successful, the parameter changes in the incremental update dataset are applied to update the global master parameter state.

10. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, The process of receiving the synchronization update instruction by the second client also includes a fault tolerance mechanism: Perform data integrity verification on the received synchronization update command; When the full-duplex communication link is interrupted, a recovery process including intelligent reconnection and local operation caching is executed; After the connection is restored or at a critical node, a consistency verification between the local state and the global master parameter state is performed.

11. The method for synchronizing status parameters across terminal devices according to claim 10, characterized in that, The data integrity and consistency verification includes: Calculate the first check value of the received data and compare it with the second check value carried in the synchronization update instruction. If they do not match, trigger data retransmission. After a connection is established or restored, the first digest information of the global master parameter state maintained by the synchronization server is obtained and compared with the second digest information of the local state. If they are inconsistent, a full state synchronization is triggered to correct the local state. The restoration process includes: Automatic reconnection is performed based on a backoff delay strategy, where the reconnection waiting time increases with the number of failures. During connection interruption, local parameter change operations are serialized and cached in the synchronization queue; After the connection is restored, the operations in the queue to be synchronized are sent in batches to the synchronization server for synchronization.

12. The method for synchronizing status parameters across terminal devices according to claim 1, characterized in that, It also includes performance optimization and multi-device collaborative expansion steps: When transmitting synchronous data that includes multiple parameter changes, enable the data compression mechanism; The synchronization server supports cloud-based preset management, enabling the creation, storage, and real-time synchronous loading of named configurations across devices; In addition, a multi-terminal collaborative interaction mode is introduced, which can synchronize and visualize the operation status of each client in real time when multiple clients access the same configuration session.

13. A cross-terminal device status parameter synchronization system, characterized in that, This includes a first client, a second client, and a synchronization server; The first client, the second client, and the synchronization server are connected via a full-duplex communication link; The first client is used to generate an incremental update dataset containing version metadata and send it to the synchronization server in response to the adjustment operation of the status parameters; The synchronization server is used to receive the incremental update dataset, and perform conflict detection and adjudication based on the version metadata to update the global master parameter state; according to the updated global master parameter state, it generates a synchronization update instruction and distributes it to at least one associated second client in real time through the corresponding communication link; The second client is used to receive and parse the synchronization update instruction to apply parameter changes locally and achieve real-time consistency synchronization of status parameters among multiple client devices.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the computer program is executed by the processor, it implements the method steps for synchronizing state parameters across terminal devices as described in any one of claims 1-12.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method steps for synchronizing state parameters across terminal devices as described in any one of claims 1-12.

Images