A multi-protocol AoIP audio stream monitoring system and method based on B / S architecture

Abstract

This invention discloses a multi-protocol AoIP audio stream monitoring system based on a B / S architecture, comprising a server and a client. The client communicates with the server and is responsible for displaying audio status and alarm information. The server includes network receiving, fixed-length audio caching, multi-threaded audio calculation, an audio stream parsing engine, status management, alarm and event generation, and a northbound interface module. The network receiving module receives multi-protocol AoIP data packets; the fixed-length audio caching module maintains a fixed-length reusable cache; the multi-threading module allocates independent threads for each audio stream; the parsing engine parses RTP audio data; the status management module updates and pushes status; the alarm module detects anomalies and generates events; and the northbound interface module allows external systems to query and receive data. The system is compatible with multiple protocols, has high real-time performance, flexible deployment, and supports integration with upper-layer systems.

Description

Technical Field

[0001] This invention relates to the fields of broadcast television and professional audio technology, specifically a multi-protocol AoIP audio stream monitoring system and method based on a B / S architecture. Background Technology

[0002] With the full IP-based transmission of real-time audio signals, multiple AoIP protocols such as AES67, SMPTE ST 2110-30, Ravenna, and Dante coexist in the professional audio field. Existing audio monitoring solutions are mostly dedicated hardware devices or client / server (C / S) architecture software based on specific protocols, which have the following limitations: 1. Poor protocol compatibility: Different AoIP protocols have different data packet structures, clock synchronization mechanisms, and metadata declaration methods (such as through Session Description Protocol (SDP), making the design of a general-purpose parser extremely complex. Typically, a monitoring device or software can only handle one or a few protocols, increasing the purchase and maintenance costs for users in multi-protocol environments. 2. Insufficient real-time performance: C / S architecture software solutions place a large computational load on the client side. Due to the varying performance of client hardware, the real-time monitoring of the same audio stream varies significantly across different clients, making it difficult to guarantee accurate and consistent monitoring of critical anomalies such as audio interruptions and silence. 3. Inflexible access and deployment: Hardware devices require physical contact, and C / S architecture software requires the installation of a dedicated client. This limits convenient remote, cross-platform (e.g., via mobile devices) access and makes centralized, comprehensive monitoring difficult. 4. Low system integration: Existing solutions typically lack standardized northbound interfaces, hindering efficient integration with higher-level network management or automated operation and maintenance platforms, thus impeding the realization of intelligent and automated operation and maintenance processes. Therefore, there is an urgent need in this field for an audio stream monitoring solution that can overcome the above shortcomings and achieve high compatibility, high real-time performance, flexible deployment, and easy integration. Summary of the Invention

[0003] The purpose of this invention is to provide a multi-protocol AoIP audio stream monitoring system and method based on a B / S architecture. The system of this invention supports multiple mainstream AoIP protocols, possesses high real-time performance and low latency, enables flexible deployment across platforms and hardware architectures, and supports deep integration with upper-layer systems through standardized interfaces.

[0004] The technical solution of this invention is: a multi-protocol AoIP audio stream monitoring system based on a B / S architecture, comprising a server and a client; the client is communicatively connected to the server and is used to receive and display real-time audio status and alarm information;

[0005] The server-side includes a network receiving module, a fixed-length audio buffer module, an audio calculation multi-threading partitioning module, an audio stream parsing engine, a state management module, an alarm and event generation module, and a northbound interface module, wherein:

[0006] The network receiving module is used to join the specified IP multicast group according to the configuration, receive various AoIP protocol data packets from the network, and send the received data packets to the fixed-length audio buffer module;

[0007] The fixed-length audio buffer module is used to independently create and maintain a fixed-length reusable memory buffer for each monitored audio stream to buffer the received audio stream data and output the buffered data to the audio stream parsing engine.

[0008] The audio computing multi-threaded partitioning module interacts with the fixed-length audio caching module, the audio stream parsing engine, and the state management module to create an independent thread for each audio stream and collaboratively complete data caching, parsing, and state updates.

[0009] The audio stream parsing engine is used to obtain data from the fixed-length audio cache module, parse the audio data in the RTP payload, and send the parsing result to the status management module.

[0010] The status management module is used to receive the output of the audio stream parsing engine, update the status information of the audio stream in real time, and push it to the client. At the same time, the status information is provided to the alarm and event generation module and the northbound interface module.

[0011] The alarm and event generation module is used to obtain status information from the status management module, detect anomalies, and generate alarm events.

[0012] The northbound interface module is used to obtain real-time status from the status management module, so that external systems can query and receive real-time events.

[0013] The aforementioned multi-protocol AoIP audio stream monitoring system based on a B / S architecture has a network receiving module implemented using UDPSocket. It specifies the local network card for multicast reception by setting the SO_REUSEADDR parameter and supports the IGMPV3 protocol.

[0014] The aforementioned multi-protocol AoIP audio stream monitoring system based on B / S architecture uses a fixed-length audio cache module implemented using a JDK native array structure. During initialization, a fixed size is pre-allocated according to the audio stream parameters. Furthermore, by optimizing the JVM parameter -XX:PretenureSizeThreshold, cached objects are controlled to directly enter the old generation, thereby reducing system pauses caused by garbage collection.

[0015] In the aforementioned multi-protocol AoIP audio stream monitoring system based on a B / S architecture, the audio calculation multi-threading partitioning module allocates an independent thread to each audio stream, realizing parallel utilization of CPU resources and ensuring that the monitoring anomaly of a single audio stream does not affect the real-time calculation of other streams.

[0016] The aforementioned multi-protocol AoIP audio stream monitoring system based on a B / S architecture includes an audio stream parsing engine with two operating modes:

[0017] Metadata-guided mode: Metadata is obtained dynamically by parsing SAP / SDP messages or from the source device interface, and the RTP packet structure is accurately parsed based on the metadata.

[0018] The manual configuration mode enables accurate parsing by manually configuring audio parameters when metadata is missing.

[0019] The aforementioned multi-protocol AoIP audio stream monitoring system based on a B / S architecture includes a status management module that calculates the audio stream's reception status, channel level, and overall loudness LKFS in real time, and actively pushes real-time status information to the client via WebSocket technology.

[0020] The aforementioned multi-protocol AoIP audio stream monitoring system based on B / S architecture generates an alarm event when a stream interruption or a signal below a set threshold is detected, and combines this with buzzer control to achieve audible and visual alarms; a memory barrier method is used during continuous alarm triggering to prevent impact on the buzzer.

[0021] The aforementioned multi-protocol AoIP audio stream monitoring system based on B / S architecture provides a RESTful API for external systems to query the real-time status of audio streams and channels. It also provides a WebSocket-based real-time event push interface to proactively push alarms and status change events to clients or external systems.

[0022] A multi-protocol AoIP audio stream monitoring method based on a B / S architecture, applied to the aforementioned system, includes the following steps:

[0023] Step 1: Start the server and load the audio stream configuration information;

[0024] Step 2: The network receiving module joins the specified multicast group and receives AoIP protocol data packets;

[0025] Step 3: The fixed-length audio buffer module stores the received data packets into a fixed-length reusable buffer area that is independently allocated for each audio stream;

[0026] Step 4: The audio stream parsing engine parses the audio data in the RTP payload based on metadata or manual configuration;

[0027] Step 5: The audio calculation multi-threading partitioning module allocates an independent thread for each audio stream for real-time calculation;

[0028] Step 6: The state management module updates the audio stream state information and pushes it to the client via WebSocket;

[0029] Step 7: The alarm and event generation module detects anomalies based on status information and triggers an alarm;

[0030] Step 8: The northbound interface module responds to query requests from external systems or actively pushes real-time events.

[0031] The aforementioned multi-protocol AoIP audio stream monitoring method based on B / S architecture uses a manual configuration mode for the audio stream parsing engine when metadata is missing, and automatically extracts SDP information for accurate parsing when metadata is available, thus achieving compatibility support for multiple AoIP protocols such as AES67, SMPTE ST 2110-30, Dante, and Ravenna.

[0032] Compared with the prior art, the present invention has the following beneficial effects:

[0033] 1. This invention supports automatic discovery and manual configuration of metadata through a parsing engine. A single system can handle multiple mainstream AoIP protocols such as AES67, ST2110-30, Dante, and Ravenna, greatly reducing the complexity of procurement and operation and maintenance for users in multi-protocol environments.

[0034] 2. This invention adopts a B / S architecture to concentrate the core computing pressure on the high-performance server side. Combined with high-performance fixed-length caching, multi-threaded partitioning and JVM optimization technology, it ensures ultra-low latency and high reliability of audio parsing, status calculation and alarm response, and overcomes the drawbacks of uneven client performance under C / S architecture.

[0035] 3. This invention adopts a pure B / S architecture and a cross-platform (supporting Windows / Linux, x86 / ARM) server design, enabling the system to be easily deployed on local servers, private clouds, or public clouds. Users can access the system across devices and regions using any modern browser, making operation and maintenance extremely convenient.

[0036] 4. This invention provides a standardized RESTful API and a real-time event push (WebSocket) northbound interface, which can be easily integrated with large-scale monitoring systems, network management platforms or operation and maintenance automation (AIOps) systems, providing key support for building an intelligent and centralized operation and maintenance system.

[0037] High scalability: The modular design makes it easy to add support for new AoIP protocols or to develop new analysis and alarm functions in the future. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the system structure of the present invention;

[0039] Figure 2 This is the overall operational logic diagram of the system of the present invention;

[0040] Figure 3 This is a schematic diagram illustrating the working principle of the fixed-length audio buffer of the present invention. Detailed Implementation

[0041] The following detailed description of specific embodiments, in conjunction with the technical solution of the present invention, is provided. These embodiments are only used to illustrate the present invention and are not intended to limit the scope of protection of the present invention.

[0042] Example: A multi-protocol AoIP audio stream monitoring system based on a B / S architecture. The system consists of two core parts: a server and a client. The server handles all core computational tasks, including audio stream reception, caching, parsing, calculation, status management, alarm generation, and external interface interaction. The client is only responsible for real-time status display and alarm information reception. The two communicate bidirectionally via HTTP and WebSocket protocols. The overall architecture centralizes computational load and lightweights client access. The following provides a detailed description of each component and its core implementation scheme.

[0043] I. Server-side

[0044] The server-side is developed using Java, enabling cross-platform deployment. It can run on all JDK-covered operating systems, including Windows and Linux, and supports x86 and Arm CPUs, offering high deployment flexibility. The server employs a modular design, consisting of seven core modules: a network receiving module, a fixed-length audio buffer module, a multi-threaded audio computation module, an audio stream parsing engine, a status management module, an alarm and event generation module, and a northbound interface module. These modules work collaboratively to complete the entire process from audio stream data reception and status push notifications to alarm generation and external system interaction. The modules are highly decoupled, facilitating functional expansion and maintenance. Details are as follows:

[0045] 1. Network receiving module

[0046] The core function of the network receiving module is to join the specified IP multicast group according to the system configuration, receive multi-protocol AoIP UDP data packets transmitted in the network, and forward the raw data packets to the fixed-length audio buffer module without processing. It also supports receiving data from the specified local network card and prevents data loop storms.

[0047] The technical implementation of the network receiving module includes:

[0048] This implementation uses Java UDPSocket to listen for and receive UDP packets. When creating a Socket instance, the SO_REUSEADDR parameter is set to true to enable local multi-process / thread sharing of the port. It also supports multicast reception by specifying the local network card IP address, thus avoiding network card resource conflicts.

[0049] The IGMPv3 protocol-related methods are encapsulated to enable dynamic joining / leaving of multicast groups, reducing the operational costs of manual route configuration. The network receiving module also sets the IP_MULTICAST_LOOP parameter to false to disable multicast loopback and prevent data storms caused by local loopback links.

[0050] A configurable interface has been developed to support reading parameters such as the multicast address, port number, and bound network card IP from the configuration file. The interface is automatically loaded and joined to the multicast group at startup without the need for hard-coding modifications.

[0051] 2. Fixed-length audio buffer module

[0052] The core function of the fixed-length audio caching module is to independently create and maintain a fixed-length reusable memory buffer for each monitored audio stream, caching the raw data packets transmitted by the network receiving module, avoiding the memory overhead caused by frequent object creation / destruction, and reducing system pauses caused by JVM garbage collection (GC), thus providing stable data support for subsequent parsing.

[0053] The fixed-length audio buffer module technology implementation includes:

[0054] The buffer is implemented based on JDK's native array structure (such as byte[]), abandoning the encapsulation of collection classes (such as ArrayList) to avoid the extra computational overhead caused by expansion operations; when the system starts and loads the audio stream configuration, it pre-calculates and allocates a fixed-size buffer based on parameters such as the audio stream's sampling rate, sampling bit depth, and number of channels. Each audio stream corresponds to an independent buffer, which is isolated from each other.

[0055] Configure the JVM parameter -XX:PretenureSizeThreshold to set the memory threshold according to the actual business scenario (e.g., set it to 10M), so that cached objects directly enter the JVM old generation, avoiding the STW (Stop The World) phenomenon caused by Minor GC and Full GC in the young generation, and reducing system lag and latency.

[0056] Implement a cache reuse mechanism: When cache data is read by the parsing engine, only the data pointer is reset, and the cache object is not destroyed. Subsequent newly received data packets directly overwrite the original data, reducing the overhead of memory allocation and reclamation. Add a cache overflow protection mechanism: When the data packet receiving speed exceeds the parsing speed, a cache full warning is triggered and synchronized to the state management module. At the same time, the method of overwriting old data is used to ensure the real-time performance of the cache.

[0057] Figure 3 This diagram illustrates the working principle of fixed-length audio caching. Audio multicast acts as the data source, continuously feeding AoIP packets into the JVM. Internally, the JVM is divided into a young generation and an old generation. The young generation stores temporary, short-lived objects, while the fixed-length audio cache is directly allocated to the old generation. Each audio stream corresponds to an independent fixed-length cache area. Large cache objects are directly promoted to the old generation using JVM parameters (such as -XX:PretenureSizeThreshold), avoiding stop-the-world (STW) pauses caused by frequent garbage collection in the young generation. This ensures the stability and low latency of the audio data cache, providing reliable data support for subsequent audio parsing calculations.

[0058] 3. Audio Calculation Multi-threaded Partitioning Module

[0059] The core function of the audio computing multi-threaded partitioning module is to allocate an independent computing thread to each monitored audio stream, and work with the fixed-length audio cache module, audio stream parsing engine, and state management module to complete data cache reading, parsing calculation, and state updating, thereby achieving parallel utilization of CPU resources and ensuring that the monitoring anomaly of a single audio stream does not affect the processing of other streams.

[0060] The technical implementation of multi-threaded partitioning for audio computation includes:

[0061] A thread management mechanism based on Java thread pool technology (ThreadPoolExecutor) is developed. Core threads are dynamically created according to the number of audio streams to be monitored. Each audio stream is bound to an independent core thread, and the thread priority is set to medium-high (such as Thread.NORM_PRIORITY+1) to ensure the real-time performance of audio calculation.

[0062] Implement a one-to-one mapping and isolation between threads and audio streams: Each thread is only responsible for reading cached data of the corresponding audio stream, calling the parsing engine, and pushing the parsing results to the state management module. There is no data sharing between threads to avoid thread safety issues. Add a thread exception monitoring mechanism. When a thread terminates due to an audio stream exception (such as data corruption or parsing failure), the thread is automatically restarted and an exception log is generated without affecting the normal operation of other threads.

[0063] Supports dynamic expansion of the thread pool: When a new audio stream is added to the system for monitoring, a new thread is automatically allocated to the new stream and added to the thread pool; when the audio stream stops being monitored, the corresponding thread is automatically recycled to improve CPU resource utilization.

[0064] 4. Audio stream parsing engine

[0065] The core function of the audio stream parsing engine is to read raw data packets from the fixed-length audio buffer module and parse the valid audio data in the RTP payload. It is the core module for achieving multi-protocol AoIP compatibility and supports two working modes: metadata-guided mode and manual configuration mode, which can automatically switch based on the presence or absence of metadata.

[0066] The technical implementation of the audio stream parsing engine includes:

[0067] Metadata-guided mode (preferred mode): Develop an SAP / SDP message parsing subroutine to automatically parse SAP / SDP broadcast messages in the network, or dynamically obtain metadata from the AoIP source device interface, extracting key parameters such as multicast address, port, sampling rate, sampling bit depth, number of channels, and RTP header length; based on the extracted metadata, accurately parse the RTP packet structure, skip the RTP header (usually 12 bytes), and perform deinterleaving, format conversion, and other processing on the payload to extract valid audio data.

[0068] Manual configuration mode (fallback mode): When metadata is missing (e.g., the source device does not send SAP / SDP messages, or message parsing fails), it supports reading manually configured audio stream parameters from the system configuration file (which are consistent with the parameters extracted from the metadata), and completing the parsing of RTP data packets based on the manually configured parameters to ensure the accuracy of the parsing.

[0069] Achieve multi-protocol compatibility parsing: To address the differences in packet structure between mainstream AoIP protocols such as AES67, SMPTE ST 2110-30, Dante, and Ravenna, a protocol adaptation subroutine was developed. Based on metadata or manually configured protocol types, the corresponding parsing logic is automatically invoked, enabling a single engine to be compatible with multiple protocols.

[0070] 5. Status Management Module

[0071] The core function of the status management module is to receive the output data of the audio stream parsing engine, calculate, update and maintain the status information of all audio streams in real time, actively push the real-time status to the client through WebSocket technology, and provide a unified status data access point for the alarm and event generation module and the northbound interface module.

[0072] The technical implementation of the state management module includes:

[0073] The audio stream state data model is designed, including basic information (stream name, multicast address, port, protocol type, bound thread), reception status (online / offline, data packet reception rate, packet loss rate), audio parameters (sampling rate, sampling bit depth, number of channels), audio quality (level of each channel, overall loudness LKFS), update timestamp, and other fields. It is stored using a Map data structure, where the key is a unique identifier for the audio stream and the value is an instance of the state data model, ensuring fast data query and update.

[0074] Real-time calculation of audio quality metrics: A loudness calculation subroutine was developed based on the ITU BS.1770 standard to calculate the overall loudness LKFS of the audio stream in real time; a channel level calculation subroutine was developed to calculate the level value (dBFS) of each channel in real time; based on the RTP packet reception timestamp and the number of lost packets, the packet loss rate and reception status were calculated (if no data packet is received for more than 500ms, it is marked as offline).

[0075] Real-time push is implemented based on Java WebSocket frameworks (such as Netty and Spring WebSocket): After the client establishes a long WebSocket connection with the server, when the audio stream status changes (such as level fluctuations, receiving status switching, or increased packet loss rate), the latest status data is immediately pushed to the client, with push latency controlled in milliseconds; it supports multiple clients connecting simultaneously, ensuring that the status data received by each client is consistent.

[0076] 6. Alarm and Event Generation Module

[0077] The core function of the alarm and event generation module is to obtain audio stream status information in real time from the status management module, detect abnormal states according to preset thresholds, generate alarm events and trigger audible and visual alarms. At the same time, memory barrier technology is used to prevent continuous alarms from impacting the buzzer. Alarm events are synchronized to the status management module and the northbound interface module.

[0078] The technical implementation of the alarm and event generation module includes:

[0079] Develop an anomaly detection rule engine that supports configurable settings for anomaly thresholds, including flow interruption thresholds (e.g., no data packets received for 500ms), level thresholds (e.g., below -60dBFS for 2 consecutive seconds), packet loss rate thresholds (e.g., exceeding 5%), and loudness LKFS thresholds. The rule engine polls the status data of the status management module in real time. When a status value is detected to exceed a preset threshold, an alarm event is immediately generated. The alarm event includes information such as flow identifier, anomaly type, anomaly value, trigger time, and duration.

[0080] Implement audible and visual alarm functions: Integrate a buzzer control interface. When an alarm event is generated, the buzzer is triggered to sound, and alarm information is pushed to the client. The client interface displays an alert box and provides a visual reminder. During continuous alarm triggering / closing, a memory barrier method (such as the volatile keyword and synchronized block in Java) is used to ensure the orderly execution of buzzer control instructions and prevent rapid instruction switching from impacting the buzzer hardware and causing alarm abnormalities.

[0081] Implement alarm event classification and handling: Supports classifying alarm events into Level 1 alarms (such as stream interruption), Level 2 alarms (such as low level), and Level 3 alarms (such as excessive packet loss rate), with different audible and visual alert methods corresponding to different alarm levels; supports alarm confirmation, clearing, and blocking operations, and the operation results are synchronized to the status management module.

[0082] 7. Northbound Interface Module

[0083] The core function of the northbound interface module is to provide a standardized interface for external systems (such as network management platforms, operation and maintenance automation platforms, and AIOps systems), support external systems in querying the real-time status of audio streams, and proactively push alarms and status change events to external systems to achieve cross-platform integration of the system.

[0084] The technical implementation of the northbound interface module includes:

[0085] Provides RESTful API interfaces: RESTful APIs are developed based on Spring Boot / Spring MVC, supporting GET, POST and other request methods. They provide interfaces for querying audio stream lists, single stream status, health status of all streams, and alarm events, returning response data in JSON format. The interface documentation follows the OpenAPI specification, facilitating integration with external systems.

[0086] Provides a WebSocket real-time event push interface: Reuses the WebSocket framework of the status management module to provide an independent WebSocket connection entry point for external systems. When the audio stream status changes or an alarm event is generated, it actively pushes the event to the connected external system to achieve real-time synchronization of alarms and status changes.

[0087] Enhance interface access control and security mechanisms: Use methods such as token authentication and IP whitelisting to restrict access permissions to external systems' interfaces; encrypt data transmitted through interfaces (e.g., HTTPS) to prevent data leakage.

[0088] Interface examples: GET / api / streams (query the basic status of all audio streams), GET / api / streams / {id} (query the detailed status of an audio stream with a specified identifier), GET / api / alerts (query unconfirmed alarm events).

[0089] II. Client

[0090] The client is designed as a pure web application, developed based on HTML5, CSS3, and JavaScript. It is compatible with all modern browsers (Chrome, Firefox, Safari, Edge, etc.) and requires no plugins or special software. It supports access from various terminal devices such as desktops, tablets, and mobile phones. The core functions are audio configuration and real-time status display.

[0091] The client-side front-end framework uses lightweight frameworks (such as Vue.js and React) to implement component-based page development, improving development efficiency and page compatibility. The client's communication protocol uses HTTP / HTTPS to obtain web pages and initialization data, and establishes a long-lived connection with the server via WebSocket to receive real-time status and alarm information. The client's visualization components utilize visualization chart libraries such as ECharts and Highcharts to achieve real-time graphical display of data such as audio stream level, loudness, and packet loss rate (e.g., waveforms, dashboards, and line charts).

[0092] The core functional modules of the client include:

[0093] Audio configuration module: Enables visual configuration of audio stream monitoring parameters, including stream name, multicast address, port, bound network interface card, protocol type, sampling parameters, alarm threshold, alarm activation / deactivation, and volume calculation channel. After configuration data is submitted, it is synchronized to the server via HTTP interface. The server automatically loads the new configuration and creates the corresponding buffer and thread, enabling dynamic addition, deletion, and modification of audio streams.

[0094] AMON Main Page: As the core display page of the client, it presents the real-time status of all monitored audio streams in a visual dashboard format, including the stream's online / offline status, protocol type, channel level waveforms, overall loudness LKFS, packet loss rate, update timestamps, etc. The AMON Main Page also provides real-time alerts for alarm events. When the server pushes an alarm event, a pop-up alert box appears, the corresponding audio stream's display area is highlighted, and an audio alert is played. It supports alarm event confirmation and blocking. Furthermore, the AMON Main Page supports sorting, filtering, and searching audio streams, allowing users to quickly locate target audio streams; it also supports multi-window and multi-tab display, adapting to different terminal device screen sizes.

[0095] III. System Deployment and Operation

[0096] The system of this invention is flexible in deployment and can be deployed on local servers, private clouds, or public clouds. It supports Windows / Linux operating systems and x86 / ARM architecture. Those skilled in the art can complete the system deployment and operation by following the steps below, taking a Linux x86 architecture server as an example:

[0097] (a) Preparations before deployment

[0098] Environment setup: Install JDK (version 1.8 or above) on the server and configure the JAVA_HOME environment variable; install a web server such as Tomcat / Nginx to deploy client web applications;

[0099] Hardware requirements: Configure hardware according to the number of audio streams being monitored. It is recommended to have a CPU with 4 cores or more, 8GB or more of memory, and a network card with gigabit speed or higher to ensure real-time data reception and processing.

[0100] Network configuration: Configure the IP address of the server's network card to ensure that the server can access the AoIP multicast network to be monitored, and open the multicast port, WebSocket port, and HTTP / HTTPS port (such as 80, 443, 8080).

[0101] (II) Server-side deployment

[0102] Package the completed server-side Java program into a JAR file (or WAR file) and upload it to the specified directory on the server;

[0103] Write a system configuration file to configure the multicast address, port, network card to be bound, alarm threshold, JVM parameters (such as -XX:PretenureSizeThreshold) of the audio stream to be monitored, and place it in the same directory as the JAR package;

[0104] Start the server program via command line: java -jar -XX:PretenureSizeThreshold=10485760 audio-monitor-server.jar (set PretenureSizeThreshold to 10M), check the startup log to confirm that all modules are loaded successfully and the multicast group is joined successfully.

[0105] (III) Client Deployment

[0106] Package the developed client-side web application into static resources (HTML / CSS / JS) and upload it to the web server root directory (such as Tomcat's webapps / ROOT directory).

[0107] Start the web server and confirm that the client page can be accessed via the server IP address and port (e.g., http: / / 192.168.1.100:8080).

[0108] (iv) System operation process

[0109] Server initialization: After the server starts, it loads the configuration file and completes the multicast group joining of the network receiving module, the buffer pre-allocation of the fixed-length audio buffer module, and the thread pool initialization of the audio calculation multi-threaded partitioning module.

[0110] Data reception and buffering: The network receiving module receives AoIP protocol data packets in real time and pushes the raw data packets to the fixed-length buffer of the corresponding audio stream;

[0111] Multi-threaded parsing and computation: The audio computation multi-threaded partitioning module allocates an independent thread for each audio stream, reads data from the buffer, calls the audio stream parsing engine to complete RTP packet parsing, and pushes the parsing results to the state management module;

[0112] Status Update and Push: The status management module calculates information such as the reception status, channel level, and loudness LKFS of the audio stream in real time, updates the status data, and pushes the latest status to the client via WebSocket;

[0113] Anomaly detection and alarm: The alarm and event generation module monitors status data in real time. When an anomaly is detected, an alarm event is generated and an audible and visual alarm is triggered. The alarm information is then pushed to the client.

[0114] External system integration: The northbound interface module provides RESTful API queries and WebSocket event push for external systems, enabling integration with network management platforms and operation and maintenance automation platforms;

[0115] Client-side interaction: Users access the client page through a browser to complete audio stream configuration, view the audio stream status in real time, receive and process alarm events, and achieve comprehensive monitoring.

[0116] Figure 2 An overall operational logic diagram of a system according to the present invention is shown. For example... Figure 2 As shown, the audio source provides multiple AoIP streams (source 1, source 2, etc.). The server-side network receiving module performs multicast reception, acquiring UDP data packets in real time. It then checks for timeouts; if a timeout occurs, the multicast status is changed to abnormal, initiating an alarm process. If no timeout occurs, memory synchronization is performed, writing the data packets to the corresponding audio stream's fixed-length buffer. Next, it checks if the packet count is sufficient; if not, it returns to multicast reception to continue accumulating data; if sufficient, it calls the audio stream parsing engine to calculate audio quality metrics such as channel level and loudness (LKFS). After calculation, it pushes data to the client, synchronizing the real-time status to the front-end page via WebSocket. Finally, it checks for alarms; if an abnormal status is detected (timeout, excessive level / loudness, high packet loss rate, etc.), the multicast status is changed to abnormal, and an alarm is pushed to the page. Simultaneously, depending on the audible / visual alarm configuration, a buzzer alarm is triggered for hardware-level alerting. If the status is normal, the process ends, looping back to the multicast reception step for continuous monitoring.

[0117] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

[0118] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. 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. However, these modifications or substitutions do not cause the corresponding technical solutions to depart from the protection scope defined by the claims of the present invention.

Claims

1. A multi-protocol AoIP audio stream monitoring system based on a B / S architecture, characterized in that: It includes a server and a client; the client communicates with the server and is used to receive and display real-time audio status and alarm information; The server-side includes a network receiving module, a fixed-length audio buffer module, an audio calculation multi-threading partitioning module, an audio stream parsing engine, a state management module, an alarm and event generation module, and a northbound interface module, wherein: The network receiving module is used to join the specified IP multicast group according to the configuration, receive various AoIP protocol data packets from the network, and send the received data packets to the fixed-length audio buffer module; The fixed-length audio buffer module is used to independently create and maintain a fixed-length reusable memory buffer for each monitored audio stream to buffer the received audio stream data and output the buffered data to the audio stream parsing engine. The audio computing multi-threaded partitioning module interacts with the fixed-length audio caching module, the audio stream parsing engine, and the state management module to create an independent thread for each audio stream and collaboratively complete data caching, parsing, and state updates. The audio stream parsing engine is used to obtain data from the fixed-length audio cache module, parse the audio data in the RTP payload, and send the parsing result to the status management module. The status management module is used to receive the output of the audio stream parsing engine, update the status information of the audio stream in real time, and push it to the client. At the same time, the status information is provided to the alarm and event generation module and the northbound interface module. The alarm and event generation module is used to obtain status information from the status management module, detect anomalies, and generate alarm events. The northbound interface module is used to obtain real-time status from the status management module, so that external systems can query and receive real-time events.

2. The multi-protocol AoIP audio stream monitoring system based on B / S architecture according to claim 1, characterized in that: The network receiving module is implemented based on UDPSocket, and multicast reception is performed by specifying the local network card through setting the SO_REUSEADDR parameter, and it supports the IGMPV3 protocol.

3. The multi-protocol AoIP audio stream monitoring system based on B / S architecture according to claim 1, characterized in that: The fixed-length audio cache module is implemented based on the JDK native array structure. During initialization, a fixed size is pre-allocated according to the audio stream parameters. By tuning the JVM parameter -XX:PretenureSizeThreshold, cached objects are controlled to directly enter the old generation, thereby reducing system pauses caused by garbage collection.

4. The multi-protocol AoIP audio stream monitoring system based on B / S architecture according to claim 1, characterized in that: The audio computing multi-threaded partitioning module allocates an independent thread to each audio stream, enabling parallel utilization of CPU resources and ensuring that the monitoring of anomalies in a single audio stream does not affect the real-time computing of other streams.

5. The multi-protocol AoIP audio stream monitoring system based on B / S architecture according to claim 1, characterized in that: The audio stream parsing engine includes two operating modes: Metadata-guided mode: Metadata is obtained dynamically by parsing SAP / SDP messages or from the source device interface, and the RTP packet structure is accurately parsed based on the metadata. The manual configuration mode enables accurate parsing by manually configuring audio parameters when metadata is missing.

6. The multi-protocol AoIP audio stream monitoring system based on B / S architecture according to claim 1, characterized in that: The status management module calculates the reception status, channel level, and overall loudness LKFS of the audio stream in real time, and actively pushes real-time status information to the client via WebSocket technology.

7. The multi-protocol AoIP audio stream monitoring system based on B / S architecture according to claim 1, characterized in that: The alarm and event generation module generates an alarm event when it detects a stream interruption or a signal below a set threshold, and combines it with buzzer control to achieve an audible and visual alarm; a memory barrier method is used during continuous alarm triggering to prevent impact on the buzzer.

8. The multi-protocol AoIP audio stream monitoring system based on a B / S architecture according to claim 1, characterized in that: The northbound interface module provides a RESTful API for external systems to query the real-time status of audio streams and channels. It also provides a WebSocket-based real-time event push interface to proactively push alarms and status change events to clients or external systems.

9. A multi-protocol AoIP audio stream monitoring method based on a B / S architecture, applied to the system described in any one of claims 1 to 8, characterized in that: Includes the following steps: Step 1: Start the server and load the audio stream configuration information; Step 2: The network receiving module joins the specified multicast group and receives AoIP protocol data packets; Step 3: The fixed-length audio buffer module stores the received data packets into a fixed-length reusable buffer area that is independently allocated for each audio stream; Step 4: The audio stream parsing engine parses the audio data in the RTP payload based on metadata or manual configuration; Step 5: The audio calculation multi-threading partitioning module allocates an independent thread for each audio stream for real-time calculation; Step 6: The state management module updates the audio stream state information and pushes it to the client via WebSocket; Step 7: The alarm and event generation module detects anomalies based on status information and triggers an alarm; Step 8: The northbound interface module responds to query requests from external systems or actively pushes real-time events.

10. The multi-protocol AoIP audio stream monitoring method based on B / S architecture according to claim 9, characterized in that: The audio stream parsing engine uses a manual configuration mode when metadata is missing, and automatically extracts SDP information for accurate parsing when metadata is available, achieving compatibility support for multiple AoIP protocols such as AES67, SMPTE ST 2110-30, Dante, and Ravenna.

Images