Microphone position anomaly detection method, device and system, electronic equipment and storage medium

Abstract

The invention provides a microphone position anomaly detection method, device and system, electronic equipment and a storage medium, and the method comprises the steps: obtaining first user state data of a user in a voice room from a voice server during microphone position anomaly detection, and obtaining second user state data of a user in a local voice room of a business server, and performing user state consistency verification based on the first user state data and the second user state data to determine whether the user has the ghost microphone abnormity, thereby realizing detection of the ghost microphone abnormity at least based on the user states respectively maintained by the business server and the voice server. The problem that it is difficult to comprehensively detect the ghost phenomenon in real time due to the fact that ghost abnormity detection is carried out through the user state maintained by the service server is solved, consistency verification is carried out through the user state data maintained by the service server and the voice server, and the ghost phenomenon in voice interaction can be comprehensively and accurately detected in real time.

Description

Technical Field

[0001] This disclosure relates to the field of network technology, and in particular to a method, apparatus, system, electronic device, and storage medium for detecting abnormal microphone positions. Background Technology

[0002] Real-time voice interaction refers to providing multiple microphone positions in scenarios such as social live streaming, online games, and team collaboration, allowing multiple users in the scenario to interact via voice through their respective microphone positions.

[0003] "Ghost microphone" refers to a situation where, even though a user's microphone status is displayed as off-mic on the client interface, other users can still hear the off-mic user's voice, or a user's microphone status is displayed as on-mic but other users cannot hear the user's voice. Currently, the client reports microphone status operations to the business server via events, and the business server maintains the microphone status of users in the voice room.

[0004] The above-mentioned solution of maintaining microphone status through the business server is prone to ghost microphones when the client fails to report microphone operation in time due to network abnormality and reconnection or program error. Currently, it mainly relies on manual reporting to discover ghost microphones and update microphone status, which is lagging and prone to errors and omissions, making it difficult to detect ghost microphones in real time and comprehensively. Summary of the Invention

[0005] This disclosure provides a method, apparatus, system, electronic device, and storage medium for detecting abnormal microphone positions, in order to solve the problem that it is difficult to detect ghost microphones in real time and comprehensively when maintaining microphone position status through business servers.

[0006] In a first aspect, this disclosure provides a method for detecting abnormal microphone placement, applied to a service server, wherein the service server communicates with a voice server and a client respectively, including: When a preset microphone position anomaly detection trigger event is detected, the first user status data of the users in each voice room is obtained from the voice server; Obtain second user status data for each voice room, wherein the second user status data is user status data determined based on events reported by the client and the voice server; Based on the first user status data and the second user status data, determine whether the user status of the users in the voice room is consistent; If so, confirm that no ghost microphone anomaly has occurred in the stated voice room; If not, it is determined that a ghost microphone anomaly has occurred in the aforementioned voice room.

[0007] Secondly, this disclosure provides a method for detecting abnormal microphone positions, applied to a client side, including: Receive a status update message sent by the service server. The status update message is a message generated by the service server when it determines that a target user has a ghost microphone abnormality based on the first user status data and the second user status data in the voice room. The first user status data is data obtained from the voice server, and the second user status data is data determined based on the events reported by the client and the voice server. Based on the status update message, update the display status of the target user in the voice room.

[0008] Thirdly, this disclosure provides a microphone position anomaly detection device, applied to a service server, wherein the service server communicates with a voice server and a client respectively, including: The first user status data acquisition module is used to acquire the first user status data of users in each voice room from the voice server when a preset microphone position abnormality detection trigger event is detected. The second user status data acquisition module is used to acquire the second user status data of each voice room. The second user status data is user status data determined based on events reported by the client and the voice server. The consistency verification module is used to determine whether the user status of the users in the voice room is consistent based on the first user status data and the second user status data. If yes, the first determination module is executed; if no, the second determination module is executed. The first determining module is used to determine that no ghost microphone abnormality has occurred in the voice room; The second determining module is used to determine that a ghost microphone anomaly has occurred in the voice room.

[0009] Fourthly, this disclosure provides a microphone position anomaly detection device, applied to a client, wherein the client communicates with a business server and a voice server, including: The status update message receiving module is used to receive status update messages sent by the business server. The status update message is a message generated by the business server when it determines that a target user has a ghost microphone abnormality based on the first user status data and the second user status data in the voice room. The first user status data is data obtained from the voice server, and the second user status data is data determined based on the events reported by the client and the voice server. The status update module is used to update the display status of the target user in the voice room based on the status update message.

[0010] Fifthly, this disclosure provides a voice interaction system, including a business server, a client, and a voice server, wherein the business server communicates with the voice server and the client respectively, and the client also communicates with the voice server; The service server is configured as follows: When a preset microphone position anomaly detection trigger event is detected, the first user status data of the users in each voice room is obtained from the voice server; Obtain second user status data for each voice room, wherein the second user status data is user status data determined based on events reported by the client and the voice server; Based on the first user status data and the second user status data, determine whether the user status of the users in the voice room is consistent; If so, confirm that no ghost microphone anomaly has occurred in the stated voice room; If not, it is determined that a ghost microphone anomaly has occurred in the aforementioned voice room; The client is configured as follows: Receive a status update message sent by the service server, wherein the status update message is generated by the service server when it detects a ghost microphone anomaly in the voice room; Based on the status update message, update the display status of the user in the voice room.

[0011] Sixthly, this disclosure provides an electronic device, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the microphone position anomaly detection method described in the first and / or second aspects of this disclosure.

[0012] In a seventh aspect, this disclosure provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the microphone position anomaly detection method described in the first and / or second aspects of this disclosure.

[0013] In the microphone position anomaly detection method of this disclosure embodiment, when the service server detects a microphone position anomaly detection trigger event, it obtains the first user status data of users in each voice room from the voice server, and the second user status data of each voice room maintained locally by the service server. Based on the first user status data and the second user status data, it performs user status consistency verification to determine whether a user in the voice room has experienced a ghost microphone anomaly. This achieves ghost microphone anomaly detection based at least on the user status in the voice room maintained by the service server and the voice server respectively, solving the problem that ghost microphone anomaly detection based on the user status maintained by the service server is difficult to detect in real time and comprehensively. By performing consistency verification on the user status data maintained by both the service server and the voice server, ghost microphone anomaly can be detected in real time, comprehensively and accurately.

[0014] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

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

[0016] Figure 1 This is a flowchart of a microphone position anomaly detection method provided in an embodiment of this disclosure; Figure 2 This is an architecture diagram of a voice interaction system; Figure 3 This is a flowchart of a microphone position anomaly detection method provided in another optional embodiment of this disclosure; Figure 4 This is a flowchart of the ghost wheat anomaly detection in this embodiment of the present disclosure; Figure 5 This is a flowchart of the client reconnecting after going offline; Figure 6 This is a flowchart of a method for detecting abnormal microphone placement provided in another embodiment of this disclosure; Figure 7 This is a schematic diagram of the structure of a microphone position abnormality detection device provided in an embodiment of this disclosure; Figure 8 This is a schematic diagram of the structure of a microphone position abnormality detection device provided in another embodiment of this disclosure; Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present disclosure, the technical solutions of the present disclosure will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present disclosure, and not all embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present disclosure.

[0018] In scenarios such as social live streaming, online games, and team collaboration, users interact with other users via voice through a client. The client integrates a voice SDK and connects to both a business server and a voice server. The voice server provides uplink and downlink voice media streams, while the business server handles business-related tasks for scenarios such as social live streaming, online games, and team collaboration. For example, the business server processes requests from the client to go on, off, turn on, and mute the microphone, and drives the client to display the status of each microphone position in the voice room.

[0019] In existing technologies, the microphone position status in a voice room is maintained by the service server. When the microphone position status cannot be updated in a timely manner due to network disconnection and reconnection or program errors, ghost microphones are prone to occur. Ghost microphones refer to a mismatch between the microphone position status and the voice status of a user in the voice room. For example, the client may show that user A has disconnected from the microphone, but in fact, user A is still sending voice through the voice server. As a result, other users' clients may see that user A has disconnected from the microphone, but they can still hear user A's voice, thus causing the ghost microphone phenomenon. Currently, the occurrence of ghost microphones mainly relies on manual reporting, or waiting for the client to reconnect or recover from the program error to correct the microphone position status maintained by the service server. This is delayed and makes it difficult to detect ghost microphones in real time and comprehensively.

[0020] Based on this, the present disclosure provides a method, apparatus, electronic device, and storage medium for detecting abnormal microphone positions, so as to detect ghost microphones in voice interaction in a timely and comprehensive manner. The implementation of the microphone position abnormality detection method of the present disclosure will be described in detail below.

[0021] Figure 1 This is a flowchart of a microphone position anomaly detection method provided in one embodiment of this disclosure, as follows: Figure 1 As shown, the abnormal microphone placement detection method includes: S101. When a preset microphone position abnormality detection trigger event is detected, the first user status data of the users in each voice room is obtained from the voice server.

[0022] like Figure 2The diagram shows the system architecture of a voice interaction system, which includes a client, a business server, and a voice server. The client can be an application that supports voice interaction; for example, it can be a live streaming client, a game client, etc. The client can integrate voice interaction functionality. The business server can be the client's backend server, which is used to respond to the client's business operation requests based on relevant business logic. For example, the client can be a live streaming client, and the business server can be a server that processes live streaming services; the client can be a game client, and the business server can be a game server. The voice server can be the backend server for voice functionality, used to process the client's voice encoding, forwarding, and other voice services. In one example, the voice server can be a server provided by at least one RTC (Real-Time Communication) service provider.

[0023] During voice interaction, the business server communicates with both the client and the voice server. A voice room can accommodate multiple clients (multiple users). Within a voice room, a client captures a user's voice and sends it to the voice server, which encodes the voice and sends it to other users. Additionally, client actions are reported to the business server, which responds to client actions based on business logic and displays the results on the client. For example, users in a voice room may request to go on, off, turn on, or mute their microphones on their clients, and these events are reported to the business server. The business server responds to these actions, maintains the user's microphone position status, and synchronizes it with other users, ensuring that all users in the voice room see the same microphone position.

[0024] In this embodiment, the preset microphone position anomaly detection trigger event can be a timed task trigger event, a microphone position status change event in the voice room, or other preset trigger operations for the voice room. Taking the timed task trigger event as an example, a minute-level timed task trigger can be configured on the business server to perform microphone position anomaly detection on all voice rooms.

[0025] In the voice server, user status and microphone status can be maintained for each voice room as the first user status data. The user status can include online status (online or offline) and user role (host or viewer). The microphone status can include statuses such as microphone on, microphone off, microphone on, microphone off, and streaming.

[0026] like Figure 2 As shown, in one embodiment, the service server may include a consistency verification module, which is used to detect microphone position anomalies. When a microphone position anomaly detection trigger event is detected, the consistency verification module can query the first user status data of each voice room from the voice server.

[0027] S102. Obtain the second user status data for each voice room. The second user status data is user status data determined based on events reported by the client and the voice server.

[0028] In this embodiment, the second user status data can be the user status data of each voice room stored locally on the service server, such as... Figure 2 As shown, the business server may include an authoritative persistence module, which is used to maintain second user status data. The status changes of users in each voice room on the client and voice server are finally confirmed, recorded and stored by the authoritative persistence module. The second user status data is the authoritative data source of the status of each voice room and the user status. When a microphone position anomaly detection trigger event is detected, the consistency verification module in the business server obtains the second user status data of users in each voice room from the authoritative persistence module. The second user status data may include user status and microphone position status.

[0029] S103. Determine whether the user status of the users in the voice room is consistent based on the first user status data and the second user status data.

[0030] In the business server, after the consistency verification module obtains the first user status data and the second user status data, it can use the first user status data and the second user status data to perform consistency verification on the user status of the users in the voice room. For example, the first user status data and the second user status data can be used to check whether the online status and microphone position status of the users in the voice room are consistent.

[0031] For example, if the first user status data records that user A is online and streaming in the voice room, while the second user status data records that user A has disconnected from the microphone, it indicates that user A's user status on the voice server and the service server is inconsistent, and user A has experienced a ghost microphone anomaly. Alternatively, if the second user status data records that user B is on the microphone, but the first user status data records that user B has not streamed within a preset time period, it is determined that user B's user status on the voice server and the service server is inconsistent. When any user in the voice room has an inconsistent user status on the voice server and the service server, it is determined that the voice room has experienced a ghost microphone anomaly, and S105 can be executed. Otherwise, it is determined that the voice room has not experienced a ghost microphone anomaly, and S104 can be executed.

[0032] S104. Confirm that no ghost microphone abnormality has occurred in the voice room.

[0033] If the user status of the user in the voice room is consistent based on the first user status data and the second user status data, it is determined that no ghost microphone anomaly has occurred in the voice room.

[0034] S105. Confirmed that a ghost microphone anomaly has occurred in the voice room.

[0035] like Figure 2 As shown, the business server includes an exception handling executor and a microphone position controller. When a ghost microphone error occurs, the exception handling executor can perform corresponding handling measures. For example, when the second user status data indicates that the user has disconnected from the microphone and the first user status data indicates that the user is streaming, the exception handling executor can generate an operation instruction to kick the user out of the voice channel of the voice room and send it to the voice server. After receiving the operation instruction, the voice server will kick the user out of the voice channel and release the user's microphone position to eliminate the ghost microphone error in the voice room.

[0036] In this embodiment of the present disclosure, when a preset microphone position anomaly detection trigger event is detected, the service server obtains the first user status data of users in each voice room from the voice server, and obtains the second user status data of each voice room maintained locally by the service server. Based on the first user status data and the second user status data, a user status consistency verification is performed to determine whether a user in the voice room has experienced a ghost microphone anomaly. This achieves ghost microphone anomaly detection based at least on the user status in the voice room maintained by the service server and the voice server, avoiding the problem of difficulty in real-time and comprehensive detection of ghost microphone anomaly caused by relying solely on the user status maintained by the service server. By using the user status data maintained by both the service server and the voice server, the consistency of user status can be verified, enabling comprehensive and real-time detection of ghost microphone anomalies.

[0037] Figure 3 The flowchart of an abnormal microphone position detection method provided as an optional embodiment of this disclosure is as follows: Figure 3 As shown, the abnormal microphone placement detection method includes: S301. When a preset microphone position abnormality detection trigger event is detected, select the voice rooms where the user is on the microphone as the voice rooms to be detected.

[0038] In this embodiment, the microphone position anomaly detection trigger event can be a scheduled task trigger event, a microphone position status change event in the voice room, or other preset trigger operations for the voice room. The scheduled task trigger event can be a scheduled task configured on the business server, such as a task that performs microphone position anomaly detection once every minute or second. The microphone position status change event can be events such as microphone on, microphone off, microphone on, and microphone off reported by the client. The preset trigger operation can be a microphone position update operation performed by the voice room administrator or a microphone position consistency check operation performed by the backend administrator.

[0039] like Figure 2As shown, in the business server, when the consistency verification module detects a microphone position anomaly detection trigger event, it can call the authoritative persistence module interface to obtain the user status data of each voice room, and filter out any voice room where the microphone position is occupied by a user as the voice room to be detected, so as to exclude voice rooms where all microphone positions are idle and reduce the amount of data to be processed in the future.

[0040] S302. Obtain the first user status data of the user in the voice room to be detected from the voice server. The first user status data includes the user's online status and the user's microphone position status.

[0041] In this embodiment, after determining the voice room to be detected, the first user status data of each user in the voice room to be detected can be queried from the voice server through the room ID of the voice room to be detected. The first user status data includes the user's online status and the user's microphone position status.

[0042] S303. Obtain the second user status data of the user in the voice room to be detected from the storage database. The second user status data includes the user's online status and the user's microphone position status.

[0043] In this embodiment, the second user status data can be the user status data of each voice room stored in the local storage of the business server. In the business server, the authoritative persistence module is used to maintain the second user status data of users in each voice room. The status changes of users in each voice room on the client and the voice server are finally confirmed and recorded by the authoritative persistence module. The second user status data is the authoritative data source of user status in each voice room. When a microphone position anomaly detection trigger event is detected, the consistency verification module calls the interface of the authoritative persistence module and reads the second user status data of users in each voice room from the database through the authoritative persistence module. The second user status data includes user status and microphone position status.

[0044] S304. Obtain the third user status data of the voice room to be detected. The third user status data is the user status data generated in response to the client's request and the intermediate user status data generated based on the preset business logic. The third user status data includes the user's online status and the user's microphone position status.

[0045] like Figure 2As shown, the business server also includes a business logic module. This business logic module responds to the client's microphone operation and maintains the microphone status and online status of each user in the voice room. It also maintains the microphone status based on preset business logic. For example, the business logic can be a preset business rule. In some business scenarios, it is necessary to add a simulated microphone in a muted state to create a scenario where virtual users or real users are online but do not participate in voice speaking. The third user status data can be user status data generated in response to the client's request and business logic, which is an intermediate business state that is not synchronized to the authoritative persistence module. For example, the third user status data can be data in the memory of the business server.

[0046] S305. Based on the user online status and user microphone status in the first user status data and the third user status data, determine whether the user status of the users in the voice room to be detected is consistent.

[0047] Since the third user status data may include simulated microphone position data, and the third user status data is generated by the business logic module that communicates with the client, it can reflect the microphone position status in the voice room in the client in real time. The first user status data is maintained by the voice server, and it can reflect the real situation of the current voice transmission of each user in the voice room in real time. The first user status data and the third user status data can be used to determine whether the user status of each user in the voice room is consistent. If they are consistent, it means that there is no ghost microphone abnormality in the voice room, and S306 can be executed. If they are inconsistent, then S307 is executed.

[0048] S306, confirming that no ghost microphone abnormalities have occurred in the user's voice room to be tested.

[0049] When the user status of a user in a voice room is determined to be consistent based on the user online status and user microphone status in the first user status data and the third user status data, it is determined that no ghost microphone abnormality has occurred in the user in the voice room to be detected.

[0050] S307. For each user in the voice room to be detected, determine the first microphone position status of each user based on the first user status data, and determine the second microphone position status of each user based on the second user status data.

[0051] When the user status of a user in a voice room is inconsistent based on the user online status and user microphone status in the first user status data and the third user status data, it is determined that there may be a ghost microphone anomaly in the voice room. The first microphone status of each user can be determined based on the first user status data, and the second microphone status of each user can be determined based on the second user status data.

[0052] S308. Determine whether the first microphone position is in microphone state and whether the second microphone position is not in microphone state.

[0053] For each user in the voice room, if the voice server records that the user is in the microphone state, while the business server records that the user is out of the microphone state, then it is determined that the user is experiencing a ghost microphone phenomenon, and this user is the target user of the ghost microphone anomaly. S309 can be executed. If the voice server and the business server record that the microphone position status of all users in the voice room is the same, then it is determined that no ghost microphone anomaly has occurred in the voice room, and S306 can be executed.

[0054] S309. Identify the target user experiencing the ghost microphone anomaly, generate an operation command to kick the target user out of the voice room to be tested, and generate a status update message for the target user.

[0055] like Figure 2 As shown, the exception handling executor in the business server can generate an operation command to kick the target user out of the voice room to be detected, and generate a status update message for the target user. This status update message can indicate that the user has been kicked out of the voice channel, so that other users in the voice room can see the message and eliminate the ghost microphone effect.

[0056] S310 sends operation commands to the voice server and pushes status update messages to the client.

[0057] The exception handling executor in the business server can send operation instructions to the voice server and push status update messages to the client. After receiving the operation instructions, the voice server will kick the target user out of the audio segment of the voice room to be tested and release the microphone occupied by the target user. After receiving the status update message, the client will update the displayed status of the target user.

[0058] Figure 4 The diagram shown is a flowchart of an example of ghost wheat anomaly detection. (Refer to...) Figure 4 When a timed detection task is received, all rooms with occupied microphones are identified as rooms to be detected. The PS microphone position data (second user status data) of the rooms to be detected is obtained, and the RTC microphone position data (first user status data) is obtained from a third party (voice server). The business microphone position data (third user status data) is compared with the RTC microphone position data (first user status data). If they match, it is determined that there is no ghost microphone anomaly. If they do not match, the consistency of the PS microphone position data and the RTC microphone position data is verified. If they do not match, it is determined that a ghost microphone anomaly has occurred, and the third party (voice server) kicks the ghost microphone user out of the channel. If they match, it is determined that there is a business microphone position without ghost microphone anomaly. Data generated by non-business simulated microphone positions is retained from the business microphone position data, and simulated business microphone positions generated by business logic are removed.

[0059] The following example illustrates the process of ghost wheat anomaly detection: Scenario: Social voice live streaming room (Room ID: 00001), there are currently 3 microphone positions. User A is speaking in microphone position 1, while users B and C are speaking in microphone positions 2 and 3 respectively (both are muted). First user status data (voice server) record: User A occupies the voice channel, is a broadcaster, and has uplink voice messages; Second user status data (authoritative persistent module) records: User A has occupied microphone position 1, is online in the room, and is in microphone-on status; Third user status data (business logic module) record: User A has occupied microphone position 1, host role, microphone access timestamp xxxx; At time t=0, user A loses internet access. The voice server detects that user A's uplink bandwidth is 0, triggering an offline event for the broadcaster. However, due to the network interruption, this event is not synchronized to the business logic module and the authoritative persistence module in a timely manner. At t=5 seconds, the voice server marks that user A has left the voice channel and stops receiving user A's voice stream; At this point, the data from the three parties are inconsistent: The authoritative persistence module still records that user A has occupied microphone position 1, is online, and has turned on the microphone. The business logic module does not update when it receives user A's offline event, and still records that user A has occupied microphone position 1 and is a broadcaster. The voice server records that user A has left the voice channel and there is no uplink stream. On the client side, this manifests as follows: other users in the room see that user A is still in microphone position 1 and shows as online, but they cannot hear user A speaking, resulting in a ghost microphone phenomenon.

[0060] When a TimeJob (scheduled task) is triggered in the business server, it calls the consistency verification module to start the ghost microphone detection: Step S1: Retrieve the list of rooms with occupants on the microphone, and filter out Room ID: 00001 (which exists in 3 rooms). (each microphone slot occupied) was identified as a room to be tested; Step S2: Retrieve data from the business logic module and the voice server: Retrieve room microphone data from the business logic module: User A (Mic #1, host role, already occupied), User B (Mic #2, host role, already occupied), User C (Mic #3, host role, already occupied); Retrieve room channel data via the voice server API: User B (in channel, host role, no streaming), User C (in channel, host role, no streaming), no record for User A (has left the channel); Step 3: Verify on a user-by-user basis User A: The business logic module has a record of the user speaking into the microphone, but the voice server does not have this user, which is inconsistent; User B / C: The status recorded by the business logic module and the voice server is consistent (both are in the channel, broadcaster role, and no flow has not exceeded the threshold). The test results show that only user A's status is inconsistent. Further verification is needed. The consistency verification module pulls user A's authoritative data from the authoritative persistence module and compares it with the data from the voice server: Authoritative persistent module records: User A has occupied microphone slot 1, the room is online, and the microphone slot is valid (not reconnecting); Voice server log: User A has left the channel; last interaction time was 55 seconds ago (exceeding the offline threshold of 5 seconds). The comparison results are as follows: the authoritative persistent module records that user A's microphone position is valid, the voice server records that user A is offline, the authoritative persistent module records that user A's microphone access is enabled, and the voice server records that user A is not sending any streams, confirming that user A has a real ghost microphone.

[0061] The above is just one type of ghost wheat. Other types of ghost wheat can be referred to the above examples, and will not be described in detail here.

[0062] This embodiment of the application, upon detecting a microphone position anomaly detection trigger event, filters out the voice rooms to be tested where the user's status is on the microphone. It obtains first user status data of the users in the voice room to be tested from the voice server, second user status data of the users in the voice room to be tested from the storage database, and third user status data of the voice room to be tested. The second user status data is the authoritative data source for the user status of each voice room, while the third user status data is user status data generated in response to client requests and based on preset business logic, representing an intermediate business state. By using the first, second, and third user status data, it determines whether a ghost microphone anomaly exists in the voice room. This achieves consistency verification of data from the voice server, the business server locally, and the business side to determine ghost microphone anomalies. It avoids the problem of difficulty in real-time and comprehensive detection of ghost microphone phenomena caused by relying solely on user status maintained by the business server. By using user status data recorded by all three parties to perform consistency verification of user status, it is possible to comprehensively and in real-time detect ghost microphone anomalies.

[0063] In an optional embodiment, when a user's abnormal offline event is received from the voice server, if the user's status before offline was on microphone, the user's status in the second user status data is set to reconnection status, and the second user status data is sent to the online users in the voice room. After a preset time, it is determined whether the user has successfully reconnected. If yes, if the user was a broadcaster before offline, the broadcaster role and microphone position are restored; if the user was a viewer before offline, the microphone position occupied by the user is released, the second user status data is updated and sent to the online users in the voice room. If no, a notification message indicating that the user is offline is sent to other users, and the microphone position occupied by the user is released.

[0064] like Figure 5 As shown, when a client goes offline in a weak network environment, the voice server sends an event indicating that the target user has gone offline due to network issues to the business server. Simultaneously, the client detects the weak network environment and initiates a reconnection. The business server determines whether the target user is logged in. If not, it directly processes the reconnection process for the client the target user is logged into. If so, in the authoritative persistence module, it modifies the target user's status in the second user status data to "reconnecting" and sets a delay to clear it (e.g., a 10-second delay). It then sends the target user's status from the second user status data to other online users in the voice room, causing their client interfaces to display that the target user is offline. The reconnection process checks the target user's status after 10 seconds. If successful, it checks if the user is a broadcaster. If so, the user's microphone position is restored; otherwise, it is released. The target user's status in the second user status data is updated to online and the corresponding microphone position is displayed. This second user status data is then sent to the clients of online users in the voice room. Each client in the voice room displays the target user's online and microphone positions based on the second user status data after successful reconnection. If the reconnection fails, an offline notification message is sent to other users in the voice room, displaying "User A is offline." For the user's logged-in client, the latest voice room status is retrieved from the authoritative persistent module on the business server during reconnection and compared with the client's local operation log. This ensures that the microphone position displayed on the client matches the microphone position in the authoritative persistent module, achieving rapid, seamless, and synchronized reconnection recovery, reducing user-perceived interruptions and microphone position status inconsistencies.

[0065] In another optional embodiment, the operation sequence of each user in the voice room to be detected can be obtained. Based on the operation sequence, target users with abnormal microphone operation can be detected. Specifically, if the number of user operations exceeds a threshold within a preset time period based on the user's operation sequence, frequent user operations are identified, triggering the generation of a globally consistent snapshot based on the operation sequence. For example, snapshots corresponding to the time points of each operation in the operation sequence can be captured from the second user state data recorded by the authoritative persistent module. The globally consistent snapshot, combined with preset business logic rules and attack characteristics, determines whether the user has abnormal operations. The business logic rules can be rules for microphone entry, exit, opening, and closing. For example, after an abnormal exit, a user must exit before entering again, and the microphone position must be confirmed to be idle before entering. Attack characteristics can include high-frequency microphone entry and exit within a short period, rapid reconnection after abnormal exit, and high-frequency exit and entry into the room. This embodiment, by combining a globally consistent snapshot with preset business logic rules and attack characteristics, can accurately detect repeated exploitation of vulnerabilities and refusal to release microphone positions, proactively defending against vulnerability exploitation and improving the security of voice interaction.

[0066] In another optional embodiment, upon receiving user events reported by the voice server and client, the target state machine of the user is determined, and the user's state machine is transferred from the current state machine to the target state machine. Atomic update data is generated, and the user's state in the second user state data is updated using the atomic update data. Specifically, the second user state data maintained by the authoritative persistence module in the business server is authoritative data of voice room information (room created, active, destroying, destroyed) and user state (entering the room, in the room, applying to go on microphone, going on microphone, on microphone, off microphone, leaving the room, etc.). Any final change of state needs to be processed and confirmed by the authoritative persistence module. In this embodiment, state changes are triggered by state machine transitions, and each transition will initiate an atomic update request to the authoritative persistence module and complete the recording, ensuring that the state at any time is predictable and traceable, reducing the risk of dirty data caused by concurrent operations, and also providing a reliable time point reference for consistency verification.

[0067] Figure 6 This is a flowchart of a microphone position anomaly detection method provided in one embodiment of this disclosure, as follows: Figure 6 As shown, this microphone position anomaly detection method is applied to the client side and includes the following steps: S601, Receive status update messages sent by the service server.

[0068] like Figure 2The diagram shows the system architecture of the voice interaction system, which includes a client, a business server, and a voice server. The status update message is generated by the business server when it detects a ghost microphone anomaly in any voice room. This status update message is sent to the client, so that when the client receives the status update message, it updates the microphone position status in the voice room and the user's online status to eliminate the ghost microphone.

[0069] In one embodiment, when the service server detects a microphone position anomaly detection trigger event, it performs microphone position anomaly detection. Specifically, the service server obtains the first user status data of users in each voice room from the voice server, and the second user status data of each voice room stored locally on the service server. The second user status data is determined based on events reported by the client and the voice server. Both the first and second user status data include the user's online status and microphone position status. The service server determines whether the user status of users in the voice room is consistent based on the first and second user status data. If they are consistent, it is determined that there is no ghost microphone anomaly. If they are inconsistent, it is determined that the target user in the voice room has a ghost microphone anomaly, and a status update message for the target user is generated and sent to the client. The client can receive the status update message. It should be noted that when there are multiple users in the voice room, multiple clients communicate with the service server. The service server sends the status update message to the clients logged into by multiple users in the voice room, so that multiple clients synchronously update the status of the target user who has a ghost microphone.

[0070] S602. Based on the status update message, update the display status of the target user in the voice room.

[0071] The client interface typically displays the online status and microphone position status of each user in the voice room. When a status update message is received, the client updates the online status and / or microphone position status of the target user.

[0072] In one optional embodiment, the status update message includes a message that the target user has been kicked out of the voice channel of the voice room. When the client receives the status update message, it clears the microphone occupancy status of the target user in the client interface and displays a message in the voice room that the target user has been kicked out of the voice channel.

[0073] For example, if the first user status data records that user A is online and streaming in the voice room, while the second user status data records that user A has logged off, it indicates that user A's user status on the voice server and the business server is inconsistent, and user A is experiencing a ghost microphone anomaly. The business server can generate an operation command to kick user A out of the voice room's voice channel and send it to the voice server. After receiving the operation command, the voice server kicks the user out of the voice channel and releases the user's microphone position to eliminate the ghost microphone anomaly in the voice room. It also generates a status update message and sends it to the client. After receiving the status update message, the client clears user A's microphone position occupancy status on the client interface and generates text information indicating that user A has been kicked out of the voice channel, prompting other users in the voice room that the ghost microphone anomaly has been eliminated. This prevents other users from mistakenly reporting user A for experiencing a ghost microphone anomaly, and realizes that after detecting a ghost microphone anomaly, the display status of users in the voice room is updated in a timely manner through status update messages to quickly eliminate the ghost microphone anomaly.

[0074] In an optional embodiment, when the target user's client reconnects to the voice server and business server after a network outage, it sends a status acquisition request for the target voice room to the business server, receives the second user status data of the target voice room returned by the business server, and renders and displays the online status and microphone position status of each user in the target voice room based on the second user status data. When the target user's client successfully reconnects to the voice server and business server within a preset time after a network outage, the second user status data is used for: if the target user is a broadcaster, restoring the target user's broadcaster role and corresponding microphone position; if the target user is a viewer, releasing the microphone position occupied by the target user.

[0075] Specifically, such as Figure 5As shown, when a client goes offline in a weak network environment, the voice server sends an offline event due to network issues to the business server. Simultaneously, the client detects the weak network environment and initiates a reconnection. The business server determines if the target user is logged in. If not, it directly processes the reconnection of the client logged in by the target user. If so, in the authoritative persistence module, it modifies the target user's status in the second user status data to "reconnecting," sets a delay to clear it, and sends the target user's status in the second user status data to other online users in the voice room, so that the online users' client interfaces display the target user's "reconnecting" status. After a delay, the system checks whether the target user has successfully reconnected. If so, it determines whether the user is a broadcaster. If the user is a broadcaster, their microphone position is restored; otherwise, it is released. The target user's status in the second user status data is updated to online and the corresponding microphone position is set. This second user status data is then sent to the clients of online users in the voice room. Each client of an online user in the voice room displays the target user's online and microphone positions after successful reconnection based on the second user status data. If the reconnection fails, a delayed message is sent to other users in the voice room, displaying "User A is offline" to them. For the client logged in by the user, the latest status of the voice room is retrieved from the authoritative persistent module of the business server during reconnection and compared with the client's local operation log to ensure that the microphone position displayed on the client is consistent with the microphone position recorded by the authoritative persistent module. This achieves fast, synchronized, and seamless reconnection recovery, reducing user-perceived interruptions and microphone position status errors.

[0076] In another optional embodiment, the client reports user events in the voice room to the service server in real time. The service server is used to transfer the user state machine from the current state machine to the target state machine based on the user events, and update the second user state data based on atomic update data. The client receives the second user state data sent by the service server and updates the user microphone status and online status displayed on the client in real time.

[0077] Specifically, the second user state data maintained by the authoritative persistence module in the business server consists of authoritative data on voice room information (room created, active, destroying, destroyed) and user status (entering the room, in the room, applying to go on microphone, going on microphone, on microphone, off microphone, leaving the room, etc.). Any final change to any status needs to be processed and confirmed by the authoritative persistence module. Each state machine change triggers an update of the second user state data and sends it to each client, ensuring that each client synchronously updates the online status and microphone position of each user in the voice room. In this embodiment, status changes are triggered by state machine transitions, and each transition initiates an atomic update request to the authoritative persistence module for recording. This ensures that the status at any given time is predictable and traceable, reducing the risk of dirty data due to concurrent operations and providing a reliable time point reference for consistency verification.

[0078] Figure 7 This is a schematic diagram of a microphone position anomaly detection device provided in an embodiment of this disclosure. Figure 7 As shown, this microphone position anomaly detection device is applied to the business server, which communicates with both the voice server and the client, including: The first user status data acquisition module 701 is used to acquire the first user status data of users in each voice room from the voice server when a preset microphone position abnormality detection trigger event is detected. The second user status data acquisition module 702 is used to acquire the second user status data of each voice room. The second user status data is user status data determined based on events reported by the client and the voice server. The consistency verification module 703 is used to determine whether the user status of the user in the voice room is consistent based on the first user status data and the second user status data. If yes, the first determination module 704 is executed; if no, the second determination module 705 is executed. The first determining module 704 is used to determine that no ghost microphone abnormality has occurred in the voice room; The second determining module 705 is used to determine that a ghost microphone abnormality has occurred in the voice room.

[0079] Figure 8 This is a schematic diagram of a microphone position anomaly detection device provided in an embodiment of this disclosure. Figure 8 As shown, this microphone position anomaly detection device is applied to the client side, which communicates with the business server and the voice server, including: The status update message receiving module 801 is used to receive a status update message sent by the service server. The status update message is a message generated by the service server when it determines that a target user has a ghost microphone abnormality based on the first user status data and the second user status data in the voice room. The first user status data is data obtained from the voice server, and the second user status data is data determined based on the events reported by the client and the voice server. The status update module 802 is used to update the display status of the target user in the voice room based on the status update message.

[0080] Figure 2 A voice interaction system provided in this disclosure embodiment, such as Figure 2 As shown, the voice interaction system includes a business server, a client, and a voice server. The business server communicates with both the voice server and the client, and the client also communicates with the voice server.

[0081] The service server is configured as follows: when a preset microphone position anomaly detection trigger event is detected, it obtains the first user status data of the users in each voice room from the voice server, and obtains the second user status data of each voice room. The second user status data is user status data determined based on the events reported by the client and the voice server. Based on the first user status data and the second user status data, it determines whether the user status of the users in the voice room is consistent. If yes, it determines that no ghost microphone anomaly has occurred in the voice room; if no, it determines that a ghost microphone anomaly has occurred in the voice room. The client is configured to receive status update messages sent by the service server. These status update messages are generated by the service server when it detects a ghost microphone anomaly in the voice room. Based on these status update messages, the client updates the display status of the user in the voice room.

[0082] Figure 9 A schematic diagram of the structure of an electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, mainframe computers, smartphones, tablet computers, game consoles, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0083] like Figure 9As shown, the electronic device 900 includes at least one processor 901 and a memory, such as a read-only memory (ROM) 902 or a random access memory (RAM) 903, communicatively connected to the at least one processor 901. The memory stores computer programs executable by the at least one processor. The processor 901 can perform various appropriate actions and processes based on the computer program stored in the ROM 902 or loaded into the RAM 903 from storage unit 908. The RAM 903 can also store various programs and data required for the operation of the electronic device 900. The processor 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0084] Multiple components in electronic device 900 are connected to I / O interface 905, including: input unit 906, such as keyboard, mouse, touch screen, game controller, etc.; output unit 907, such as various types of monitors, speakers, etc.; storage unit 908, such as disk, optical disk, etc.; and communication unit 909, such as network card, modem, wireless transceiver, etc. Communication unit 909 allows electronic device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0085] Processor 901 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 901 performs the various methods and processes described above, such as microphone position anomaly detection methods.

[0086] In one embodiment, the microphone position anomaly detection method is applied to a service server, which communicates with both a voice server and a client, including: Optionally, when a microphone position anomaly detection trigger event is detected, the first user status data of the users in each voice room is obtained from the voice server, including: When an abnormal microphone position detection event is detected, the voice rooms where the user is on the microphone are selected as the voice rooms to be detected. The first user status data of the user in the voice room to be detected is obtained from the voice server. The first user status data includes the user's online status and the user's microphone position status.

[0087] Optionally, the microphone position anomaly detection trigger event includes any one of the following events: Scheduled task trigger events, microphone status change events in the voice room, and preset trigger operations in the voice room.

[0088] Optionally, second user status data for each voice room is obtained, including: The second user status data of the user in the voice room to be detected is obtained from the local storage database of the business server. The second user status data includes the user's online status and the user's microphone position status.

[0089] Optionally, before determining whether the user states of the users in the voice room are consistent based on the first user state data and the second user state data, the method further includes: Obtain the third user status data of the voice room to be detected. The third user status data is the user status data of the intermediate state of the business generated in response to the client's request and based on the preset business logic. The third user status data includes the user's online status and the user's microphone position status.

[0090] Optionally, determining whether the user states of users in the voice room are consistent based on the first user state data and the second user state data includes: Based on the user online status and user microphone status in the first user status data and the third user status data, determine whether the user status of the users in the voice room to be detected is consistent. If so, confirm that no ghost microphone abnormality has occurred in the user in the voice room to be tested; If not, for each user in the voice room to be detected, determine the first microphone position status of each user based on the first user status data, and determine the second microphone position status of each user based on the second user status data; Determine whether the first microphone position is in microphone mode and whether the second microphone position is not in microphone mode; If so, confirm that the user has experienced a ghost microphone anomaly; If not, it is determined that the user has not experienced any ghosting or abnormalities.

[0091] Optionally, after determining that a ghost microphone anomaly has occurred in the voice room, the method further includes: Identify the target user experiencing the ghost microphone anomaly, generate an operation command to kick the target user out of the voice room to be detected, and generate a status update message for the target user; The operation instruction is sent to the voice server, and a status update message for the target user is generated and pushed to the client. After receiving the operation instruction, the voice server kicks the target user out of the audio segment of the voice room to be detected and releases the microphone position occupied by the target user. After receiving the status update message, the client updates the displayed status of the target user.

[0092] Optionally, it also includes: Obtain the operation sequence of each user in the voice room to be detected; Target users with abnormal microphone operation are detected based on the operation sequence.

[0093] Optionally, it also includes: When a user in the voice room is received from the voice server as an abnormal offline event, if the user's status before going offline was in microphone mode, the user's status in the second user status data is set to reconnection mode, and the second user status data is sent to the online users in the voice room. After a preset time period, determine whether the user has successfully reconnected; If so, when the user was a broadcaster before going offline, restore the user's broadcaster role and microphone position; when the user was a viewer before going offline, release the microphone position occupied by the user, update the second user status data and send it to the online users in the voice room. If not, send a notification message to other users indicating that the user is offline, and release the microphone slot occupied by the user.

[0094] Optionally, it also includes: When a user event is received from the voice server and the client, the target state machine of the user is determined, and the user's state machine is transferred from the current state machine to the target state machine. Atomic update data is generated, and the user's state in the second user state data is updated using the atomic update data.

[0095] In another embodiment, a microphone position anomaly detection method is applied to a client that communicates with a service server and a voice server, comprising: Receive a status update message sent by the service server. The status update message is a message generated by the service server when it determines that a target user has a ghost microphone abnormality based on the first user status data and the second user status data in the voice room. The first user status data is data obtained from the voice server, and the second user status data is data determined based on the events reported by the client and the voice server. Based on the status update message, update the display status of the target user in the voice room.

[0096] Optionally, the status update message includes a message indicating that the target user has been kicked out of the voice room's voice channel; Based on the status update message, update the display status of the target user in the voice room, including: Based on the status update message, the microphone occupancy status of the target user is cleared from the client interface, and a message that the target user has been kicked out of the voice channel is displayed in the voice room.

[0097] Optionally, it also includes: When the target user's client reconnects to the voice server and the business server after the client disconnects from the network, a status acquisition request for the target voice room is sent to the business server. Receive the second user status data of the target voice room returned by the service server; Based on the second user status data, render and display the online status and microphone position status of each user in the target voice room; When the target user's client successfully reconnects to the voice server and the business server within a preset time after the network disconnection, the second user status data is used to: restore the target user's broadcaster role and corresponding microphone position if the target user is a broadcaster, and release the microphone position occupied by the target user if the target user is a viewer.

[0098] Optionally, it also includes: The service server reports user events in the voice room to the service server in real time. The service server is used to transfer the user state machine from the current state machine to the target state machine based on the user events, and update the second user state data based on atomic update data. Receive the second user status data sent by the business server and update the user's microphone position status and online status displayed on the client in real time.

[0099] In some embodiments, the microphone position anomaly detection method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 908. In some embodiments, part or all of the computer program may be loaded into and / or installed on electronic device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by processor 901, one or more steps of the microphone position anomaly detection method described above may be performed. Alternatively, in other embodiments, processor 901 may be configured by any other suitable means (e.g., by means of firmware) to perform the microphone position anomaly detection method provided in the embodiments of this disclosure.

[0100] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0101] Computer programs used to implement the methods of this disclosure may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0102] In the context of this disclosure, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0103] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0104] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0105] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0106] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0107] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for detecting abnormal wheat planting location, characterized in that, Applied to a business server, the business server communicates with both the voice server and the client, including: When a preset microphone position anomaly detection trigger event is detected, the first user status data of the users in each voice room is obtained from the voice server; Obtain second user status data for each voice room, wherein the second user status data is user status data determined based on events reported by the client and the voice server; Based on the first user status data and the second user status data, determine whether the user status of the users in the voice room is consistent; If so, confirm that no ghost microphone anomaly has occurred in the stated voice room; If not, it is determined that a ghost microphone anomaly has occurred in the aforementioned voice room.

2. The method according to claim 1, characterized in that, When a microphone position anomaly detection event is detected, the first user status data of the users in each voice room is obtained from the voice server, including: When an abnormal microphone position detection event is detected, the voice rooms where the user is on the microphone are selected as the voice rooms to be detected. The first user status data of the user in the voice room to be detected is obtained from the voice server. The first user status data includes the user's online status and the user's microphone position status.

3. The method according to claim 2, characterized in that, Before determining whether the user states of the users in the voice room are consistent based on the first user state data and the second user state data, the method further includes: Obtain the third user status data of the voice room to be detected. The third user status data is the user status data of the intermediate state of the business generated in response to the client's request and based on the preset business logic. The third user status data includes the user's online status and the user's microphone position status.

4. The method according to claim 3, characterized in that, Determining whether the user statuses of users in the voice room are consistent based on the first user status data and the second user status data includes: Based on the user online status and user microphone status in the first user status data and the third user status data, determine whether the user status of the users in the voice room to be detected is consistent. If so, confirm that no ghost microphone abnormality has occurred in the user in the voice room to be tested; If not, for each user in the voice room to be detected, determine the first microphone position status of each user based on the first user status data, and determine the second microphone position status of each user based on the second user status data; Determine whether the first microphone position is in microphone mode and whether the second microphone position is not in microphone mode; If so, confirm that the user has experienced a ghost microphone anomaly; If not, it is determined that the user has not experienced any ghosting or abnormalities.

5. The method according to any one of claims 2-4, characterized in that, After determining that a ghost microphone anomaly has occurred in the voice room, the process also includes: Identify the target user experiencing the ghost microphone anomaly, generate an operation command to kick the target user out of the voice room to be detected, and generate a status update message for the target user; The operation instruction is sent to the voice server, and the status update message is pushed to the client. After receiving the operation instruction, the voice server kicks the target user out of the audio segment of the voice room to be detected and releases the microphone position occupied by the target user. After receiving the status update message, the client updates the displayed status of the target user.

6. A method for detecting abnormal wheat planting location, characterized in that, Applied to a client-side application, the client communicates with a business server and a voice server, including: Receive a status update message sent by the service server. The status update message is a message generated by the service server when it determines that a target user has a ghost microphone abnormality based on the first user status data and the second user status data in the voice room. The first user status data is data obtained from the voice server, and the second user status data is data determined based on the events reported by the client and the voice server. Based on the status update message, update the display status of the target user in the voice room.

7. A device for detecting abnormal wheat placement, characterized in that, Applied to a business server, the business server communicates with both the voice server and the client, including: The first user status data acquisition module is used to acquire the first user status data of users in each voice room from the voice server when a preset microphone position abnormality detection trigger event is detected. The second user status data acquisition module is used to acquire the second user status data of each voice room. The second user status data is user status data determined based on events reported by the client and the voice server. The consistency verification module is used to determine whether the user status of the users in the voice room is consistent based on the first user status data and the second user status data. If yes, the first determination module is executed; if no, the second determination module is executed. The first determining module is used to determine that no ghost microphone abnormality has occurred in the voice room; The second determining module is used to determine that a ghost microphone anomaly has occurred in the voice room.

8. A voice interaction system, characterized in that, It includes a business server, a client, and a voice server. The business server communicates with the voice server and the client respectively, and the client also communicates with the voice server. The service server is configured as follows: When a preset microphone position anomaly detection trigger event is detected, the first user status data of the users in each voice room is obtained from the voice server; Obtain second user status data for each voice room, wherein the second user status data is user status data determined based on events reported by the client and the voice server; Based on the first user status data and the second user status data, determine whether the user status of the users in the voice room is consistent; If so, confirm that no ghost microphone anomaly has occurred in the stated voice room; If not, it is determined that a ghost microphone anomaly has occurred in the aforementioned voice room; The client is configured as follows: Receive a status update message sent by the service server, wherein the status update message is generated by the service server when it detects a ghost microphone anomaly in the voice room; Based on the status update message, update the display status of the user in the voice room.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the microphone position anomaly detection method according to any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the microphone position anomaly detection method according to any one of claims 1-6.

Images