Mobile terminal audio acquisition and playing method and device in intranet environment

Abstract

The application discloses an inner network environment mobile terminal audio acquisition and playing method and device, relates to the technical field of audio processing, and comprises the following steps: detecting the running environment of a current application; matching a corresponding target execution path according to the running environment; obtaining a real-time audio media stream based on the target execution path; in response to a user's recording instruction, instantiating a recording processing module, taking the real-time audio media stream as an input source, capturing and encoding the real-time audio media stream to generate discrete audio data segments; encapsulating the audio data segments and uploading the audio data segments to a backend service layer through an HTTP protocol to perform speech recognition, obtaining a recognized text result; determining a text to be played based on the recognized text result, and playing the text to be played after processing the text to be played. Through dynamic detection of the running environment, different inner network conditions can be flexibly adapted, and the stability of audio acquisition and playing is ensured. In the playing link, the text is preprocessed according to the user's demand, and the accuracy and fluency of the playing content are improved.

Description

Technical Field

[0001] This application relates to the field of audio processing technology, and in particular to a method and apparatus for mobile audio acquisition and playback in an intranet environment. Background Technology

[0002] With the development of mobile internet technology, web-based audio capture and playback functions, such as speech recognition and speech synthesis, are widely used in various business systems. However, for security reasons, current browsers require access to sensitive resources such as microphones and cameras to run under HTTPS or a local host environment. This security strategy can be easily met in public network environments by deploying SSL certificates, but it faces serious challenges in special internal networks such as public security intranets, government intranets, and military networks.

[0003] Currently, implementing web applications with audio functionality in an intranet environment typically involves two methods: Method 1: Deploying an HTTPS certificate within the intranet. This requires building your own Certificate Authority (CA) or applying for a dedicated certificate, and installing and trusting the root certificate on each terminal device. Method 2: Developing a pure native app, i.e., implementing audio functionality entirely using native Android development, with the backend communicating with the intranet server via HTTP. Both methods have high maintenance costs and long development cycles, and cannot flexibly adapt to the needs of different intranet environments. Summary of the Invention

[0004] The main purpose of this application is to provide a method and device for mobile audio acquisition and playback in an intranet environment, which aims to solve the technical problem that the current intranet environment cannot stably call the device microphone to record and smoothly play synthesized audio.

[0005] To achieve the above objectives, this application proposes a method for mobile audio acquisition and playback in an intranet environment, the method comprising: Detect the current application's runtime environment; Match the corresponding target execution path based on the described operating environment; Obtain the real-time audio media stream based on the target execution path; In response to the user's recording command, the recording processing module is instantiated and the real-time audio media stream is used as the input source to capture and encode discrete audio data segments in real time. The audio data segment is encapsulated and uploaded to the backend service layer via HTTP protocol for speech recognition, resulting in the recognized text. Based on the identified text results, the text to be played is determined, and the text to be played is processed and then played.

[0006] In one embodiment, the step of processing the text to be played and then playing it includes: The text to be played is segmented to generate a text queue; Construct an audio pre-cache pool, and initiate an HTTP request to a preset text in the text queue to obtain audio playback data and cache it in the audio pre-cache pool; The audio playback data is read from the audio pre-cache pool and played in the order of storage.

[0007] In one embodiment, the step of reading the audio playback data from the audio pre-buffer pool in storage order for playback includes: Before starting the playback task of any text segment, read the current playback status flag. If the playback status flag indicates that playback is currently in progress, the current playback start request is blocked or discarded to prevent audio overlay concurrency conflicts. If the playback status flag indicates that the device is idle, update the playback status flag to indicate that the device is playing, and read the audio playback data from the audio pre-buffer pool in the storage order for playback.

[0008] In one embodiment, the method further includes: Listen for the end of playback event of the current text sub-segment in the audio playback data; If the playback of the current text segment ends, the object URL release interface is called to destroy the temporary URL address corresponding to the current text segment, and the data reference of the current text segment is removed from the audio pre-cache pool to release memory; Using the playback end event as a trigger signal, detect whether there are any subsequent unbuffered text segments in the playback queue; If there are uncached text fragments, an HTTP request is initiated to retrieve subsequent audio data and store it in the audio pre-cache pool for asynchronous pre-fetching; After completing the immediate release of resources and asynchronous pre-fetching, the playback status flag is reset to idle to allow the next cached segment to start playback.

[0009] In one embodiment, the step of segmenting the text to be played to generate a text queue includes: The text to be played is scanned using regular expressions, and punctuation marks are identified as natural semantic breakpoints. A maximum text length threshold is set. When the accumulated text segment length exceeds the maximum text length threshold, the text is truncated at the current character according to the natural semantic breakpoint to obtain multiple text sub-segments. The multiple text segments are added to the playback queue in sequence to generate a text queue.

[0010] In one embodiment, the step of instantiating a recording processing module in response to a user's recording command and using the real-time audio media stream as an input source to capture and encode discrete audio data segments in real time includes: In response to the user's recording command, the recording processing module is instantiated and the real-time audio media stream is used as the input source; Configure the audio encoding format for the recording processing module; The audio sampling rate and number of channels are set. Based on the audio sampling rate and the number of channels, data is extracted from the real-time audio media stream according to a preset time slice or data block size and encoded in the audio encoding format to generate continuous discrete audio data segments.

[0011] In one embodiment, the step of obtaining the real-time audio media stream based on the target execution path includes: When the target execution path is the native priority two-level authorization path, the native bridging interface is called to pop up a system-level permission request dialog box to request microphone recording permission; Listen for user authorization confirmation callbacks, and upon receiving a successful authorization signal, call the browser's standard media device interface; Acquire real-time audio media streams in an intranet environment without an HTTPS certificate.

[0012] In one embodiment, the step of matching the corresponding target execution path according to the runtime environment includes: When the runtime environment is a wrapper environment with native capability calls, the native priority two-level authorization path is matched as the target execution path; When the operating environment is a Web operating environment, the Web direct connection authorization path is matched as the target execution path.

[0013] In one embodiment, the step of detecting the current application's operating environment includes: Check if a preset native bridging namespace exists in the global object and / or resolve whether the user agent string contains a preset client identifier; When a preset native bridging namespace or a preset client identifier is detected, the current application's runtime environment is determined to be an encapsulated environment in which the current application runs with native capability calls. If no preset native bridging namespace is detected and no preset client identifier is contained, the current application's runtime environment is determined to be a web runtime environment.

[0014] Furthermore, to achieve the above objectives, this application also proposes a mobile audio acquisition and playback device for an intranet environment, the mobile audio acquisition and playback device for an intranet environment comprising: The detection module is used to detect the current application's operating environment; The matching module is used to match the corresponding target execution path based on the operating environment; The acquisition module is used to acquire real-time audio media streams based on the target execution path; The processing module is used to respond to the user's recording command, instantiate the recording processing module and use the real-time audio media stream as the input source to capture and encode discrete audio data segments in real time; The upload module is used to encapsulate the audio data segment and upload it to the backend service layer via HTTP protocol for speech recognition, so as to obtain the recognized text result. The processing module is further configured to determine the text to be played based on the identified text result, and to process the text to be played before playing it.

[0015] In addition, to achieve the above objectives, this application also proposes a mobile audio acquisition and playback device for an intranet environment. The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the mobile audio acquisition and playback method for an intranet environment as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the mobile terminal audio acquisition and playback method in the intranet environment described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the mobile terminal audio acquisition and playback method in an intranet environment as described above.

[0018] One or more technical solutions proposed in this application have at least the following technical effects: By dynamically detecting the operating environment, it can flexibly adapt to different intranet conditions, ensuring the stability of audio acquisition and playback. Simultaneously, using the HTTP protocol for data transmission effectively solves the security issues of data interaction in intranet environments. Furthermore, by encapsulating and uploading audio data segments, it achieves efficient speech recognition processing, reducing the consumption of local computing resources. During playback, text preprocessing is performed according to user needs, improving the accuracy and smoothness of the playback content. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the mobile audio acquisition and playback method in the intranet environment of this application. Figure 2 This is a schematic diagram of the device structure provided in an embodiment of the mobile terminal audio acquisition and playback method in the intranet environment of this application; Figure 3 This is a flowchart illustrating the second embodiment of the mobile audio acquisition and playback method in the intranet environment of this application. Figure 4 This is a schematic diagram of the interface structure and operation flow of the HBuilderX distribution configuration window provided in an embodiment of the mobile terminal audio acquisition and playback method in the intranet environment of this application. Figure 5 This is a schematic diagram of the visual editing interface of the manifest.json configuration file in the HBuilderX project, provided as an embodiment of the mobile terminal audio acquisition and playback method in the intranet environment of this application. Figure 6 A simplified flowchart is provided for an embodiment of the mobile audio acquisition and playback method in the intranet environment of this application; Figure 7 This is a schematic diagram of the module structure of a mobile audio acquisition and playback device in an intranet environment according to an embodiment of this application. Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the mobile terminal audio acquisition and playback method in the intranet environment in this embodiment of the application.

[0022] Explanation of icon numbers: Web front-end application layer 10, H5+ bridging layer 20, native capability layer 3, back-end service layer 40; Module 101: Environmental Detection; Module 102: Access Control; Module 103: Audio Acquisition; Module 104: Audio Playback; Module 105: Resource Release. plus object bridge interface 201; Microphone hardware 301, audio player 302; Speech recognition interface 401, speech synthesis interface 402.

[0023] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0024] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] The main solution of this application embodiment is as follows: detect the current application's operating environment; match the corresponding target execution path according to the operating environment; obtain a real-time audio media stream based on the target execution path; respond to the user's recording command, instantiate a recording processing module and use the real-time audio media stream as the input source to capture and encode discrete audio data segments in real time; encapsulate the audio data segments and upload them to the backend service layer via HTTP protocol for speech recognition to obtain the recognized text result; determine the text to be played based on the recognized text result, process the text to be played, and then play it.

[0027] Because existing technology cannot reliably access the device's microphone for recording and smoothly play synthesized audio in internal network environments where HTTPS certificates cannot be deployed, mobile applications developed based on web technologies are unable to do so.

[0028] This application provides a solution that enables out-of-the-box audio functionality in an intranet environment through a localized encapsulation + native bridging architecture, combined with intelligent environment detection, dual-path permission adaptation, precise resource release, and streaming TTS optimization.

[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, such as a mobile audio acquisition and playback device in an intranet environment. The following description uses a mobile audio acquisition and playback device in an intranet environment as an example to illustrate this embodiment and the subsequent embodiments. All actions involving the acquisition of signals, information, or data in this application are performed in accordance with the relevant data protection regulations of the country where the application is located and with authorization from the owner of the corresponding device.

[0030] Based on this, this application provides a method for mobile audio acquisition and playback in an intranet environment, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the mobile audio acquisition and playback method in the intranet environment of this application.

[0031] In this embodiment, the mobile terminal audio acquisition and playback method in the intranet environment includes steps S10~S60: Step S10: Detect the current application's runtime environment.

[0032] It should be noted that the execution subject in this embodiment is a mobile audio acquisition and playback device in an intranet environment, such as... Figure 2 As shown, Figure 2 This diagram illustrates the structure of a mobile audio capture and playback device within an intranet environment. It includes a Web front-end application layer (10), an H5+ bridging layer (20), a native capability layer (30), and a back-end service layer (40). The Web front-end application layer (10) primarily develops business interfaces based on frameworks such as HTML / JavaScript / Vue, containing recording and audio playback logic. The H5+ bridging layer (20) mainly provides JavaScript interfaces for calling the device's native capabilities through the HTML5 Plus (H5+) extension specification. The native capability layer (30) includes the device's microphone hardware (301), audio player (302), and file system. The back-end service layer (40) provides HTTP API services for speech recognition (STT) and speech synthesis (TTS) (running under the intranet HTTP protocol). The Web front-end application layer 10 includes an environment detection module 101, a permission management module 102, an audio acquisition module 103, an audio playback module 104, and a resource release module 105. The audio playback module 104 is used to send audio playback requests to the plus object bridge interface 201 in the H5+ bridge layer 20. The audio acquisition module 103 is used to send audio acquisition requests to the plus object bridge interface 201 in the H5+ bridge layer 20. The plus object bridge interface 201 is used to call the native microphone hardware 301 and audio player 302. The back-end service layer 40 includes a speech recognition interface 401 and a speech synthesis interface 402. The speech recognition interface 401 is used to recognize the audio data uploaded by the microphone hardware 301, and the speech synthesis interface 402 is used to return the synthesized audio to the audio player 302.

[0033] In practice, the web application bypasses browser restrictions on HTTPS by calling the native audio interface through the H5+ bridging layer; simultaneously, the backend service uses the HTTP protocol, avoiding the need for HTTPS certificate deployment. The PlusHelper class detects the current runtime environment based on factors including the existence of the window.plus object and whether navigator.userAgent contains the html5plus or streamapp identifier.

[0034] In one feasible implementation, step S10 may include steps A11 to A13: Step A11: Check if a preset native bridging namespace exists in the global object and / or whether the user agent string contains a preset client identifier; It should be noted that this embodiment accurately distinguishes whether an application is running in a "packaged environment with native capability calls" (such as a hybrid development App, a mini-program container, or an enterprise security browser) or in a "standard web runtime environment" (such as a regular Chrome or Safari browser) by detecting information in two dimensions: "native bridging capabilities" and "client characteristics".

[0035] First, attempt to access a JavaScript global object, such as the `window` object, to check if a pre-defined native bridging namespace object exists within it. In hybrid app development or specific encapsulation environments, the native layer typically injects specific JavaScript objects into the WebView so that the web page can call native functions, such as camera, recording, and file system.

[0036] If the application is built on a mainstream hybrid development framework, such as HBuilderX / Uni-app, it can check if the `plus` namespace exists in the global object, i.e., check if `window.plus` is not `undefined`. If the application is embedded in an enterprise security container, it checks if a specific bridge object exists, such as `window.NativeBridge`, `window.AppInterface`, or `window.JsBridge`. If the application runs in a WeChat Mini Program or a similar container, it checks if a `wx` object exists, i.e., `window.wx`. As long as any of the above-mentioned preset native bridge namespaces are detected, it can be inferred that the current environment has the ability to call native permission interfaces, and it is initially determined to be a wrapper environment with native capability calls.

[0037] As a supplement to or independent basis for the first dimension detection, the current browser's user-agent string can be obtained and its contents can be parsed to determine whether it contains a preset client identifier.

[0038] Different packaging containers or custom browsers typically carry specific identification fields in the User-Agent to indicate their identity.

[0039] A pre-defined identifier library can be established, containing strings such as "MyCompanyApp", "SecureBrowser / 1.0", "Electron", "MicroMessenger" (WeChat), and "AlipayClient" (Alipay). Regular expressions or string inclusion matching algorithms are used to iterate through the User-Agent string. For example, if the User-Agent contains "Electron", it is determined to be an Electron wrapper environment; if it contains "MyCompanyApp", it is determined to be an internal enterprise custom app environment. If the parsing result matches any item in the pre-defined client identifier library, it is determined to be a wrapper environment with native capability calls.

[0040] Step A12: When a preset native bridging namespace or a preset client identifier is detected, determine that the current application's runtime environment is an encapsulated environment in which the current application runs with native capability calls; Understandably, if a preset native bridging namespace or a preset client identifier is detected, it indicates that the current application is running in a wrapper environment with native capability calls, i.e., the App environment. The App environment is the local application packaged using HBuilderX.

[0041] Step A13: If no preset native bridging namespace is detected and no preset client identifier is contained, determine that the current application is running in a web runtime environment.

[0042] If no preset native bridging namespace is detected and no preset client identifier is found, the system will further analyze the characteristics of the current environment. If neither a specific namespace object is found nor a relevant identifier is found in the user agent string, it can be inferred that the current application is running in a standard web runtime environment, i.e., a browser environment. In this environment, the browser typically only supports basic HTML5 functions and cannot directly call the device's native capabilities, such as the microphone or audio player.

[0043] Step S20: Match the corresponding target execution path according to the operating environment.

[0044] Understandably, different execution paths can be set in different operating environments. The target execution paths include encapsulated environments with native capability calls and web operating environments.

[0045] In one feasible implementation, step S20 may include steps A21-A22: Step A21: When the runtime environment is a wrapper environment with native capability calls, match the native priority two-level authorization path as the target execution path; Understandably, if the runtime environment is a wrapper environment with native capability calls, it waits for the plusready event to trigger, establishing a channel to bridge with the native functionality. At this point, it can call the device's native capability interfaces to ensure the stability and efficiency of audio capture and playback functions. By dynamically loading native modules, functional components can be flexibly switched according to actual needs, thereby optimizing resource utilization efficiency. Furthermore, under this path, the permission management module automatically detects and requests necessary device permissions, such as microphone access permissions and audio playback permissions, to ensure the normal operation of the functions.

[0046] Step A22: When the operating environment is a Web operating environment, match the Web direct connection authorization path as the target execution path.

[0047] In practice, if the operating environment is a Web environment, the standard Web API will be used instead, that is, the Web direct connection authorization path will be matched as the target execution path.

[0048] Step S30: Obtain the real-time audio media stream based on the target execution path.

[0049] It should be noted that after determining the target execution path, the real-time audio media stream can be obtained according to the specific execution path.

[0050] If the target execution path is a native-preferred two-level authorization path, then when the target execution path is a native-preferred two-level authorization path, the native bridging interface is called to pop up a system-level permission request dialog box to request microphone recording permission; the user authorization confirmation callback is listened for, and after receiving the authorization success signal, the browser's standard media device interface is called; and real-time audio media stream is obtained in an intranet environment without an HTTPS certificate.

[0051] Understandably, if the target execution path is a native-first two-tier authorization path, the native bridging interface plus.android.requestPermissions (Android platform) is called to pop up a system-level permission dialog box, thereby requesting the microphone recording RECORD_AUDIO permission, and listening for user confirmation of authorization in real time, i.e. listening for user authorization confirmation callback. If a signal of successful user authorization is received, the browser's standard media device interface is called through navigator.mediaDevices.getUserMedia, so that real-time audio media streams can be obtained in an intranet environment without HTTPS certificates. This takes advantage of the permission exemption feature of native apps, that is, in native apps, when loading local resources through WebView, the browser's security policy allows the call to getUserMedia (even if the page is an HTTP protocol).

[0052] In another feasible implementation, if the target execution path is a Web direct authorization path, then the user is requested to authorize access to the microphone device through the standard Web API. That is, when the target execution path is a Web direct authorization path, the browser's standard media device interface is directly called to request microphone permission; if a trusted root certificate has been configured in the current intranet environment, the real-time audio media stream is directly obtained.

[0053] Understandably, in a browser environment, one can directly call `navigator.mediaDevices.getUserMedia` to request microphone permissions, and if a trusted root certificate is configured in both the internal and external environments, the real-time audio media stream can be obtained directly through the standard Web API. This method relies on the browser's security policy to ensure that the microphone function can be used normally under HTTPS or a specific trusted environment. If the current environment does not meet the trust conditions, the user will be prompted to make corresponding settings or switch to other supported operating modes.

[0054] Step S40: In response to the user's recording command, instantiate the recording processing module and use the real-time audio media stream as the input source to capture and encode discrete audio data segments in real time.

[0055] In practice, after successfully obtaining permissions, an AudioContext instance and a Recorder instance can be created to initialize the recording function and detect whether the user has triggered the recording.

[0056] When a user triggers recording, `Recorder.start()` can be called to begin acquiring audio data. Specifically, a recording processing module can be instantiated, using the acquired real-time audio media stream as the input source, and an encoder is used to segment the audio data. Each acquired audio segment is temporarily stored in a buffer and initially encapsulated using a preset encoding format (such as PCM or WAV). This process ensures the continuity and integrity of the audio data while reducing the risk of data loss due to network fluctuations.

[0057] In one feasible implementation, step S40 may include steps A31 to A33: Step A31: In response to the user's recording command, instantiate the recording processing module and use the real-time audio media stream as the input source; It should be noted that after a user initiates a recording command, the system automatically instantiates the recording processing module and uses the acquired real-time audio media stream as the input source. This process is completed by calling preset interfaces, ensuring that the audio data can be accurately captured and transmitted to subsequent processing stages. The core functions of the recording processing module include receiving the audio stream, segmenting it, and temporarily storing it. Its design aims to improve data processing efficiency while reducing resource consumption.

[0058] Step A32: Configure the audio encoding format of the recording processing module; It should be understood that when configuring the recording processing module, a suitable audio encoding format must be selected based on actual needs. Common encoding formats include PCM, WAV, MP3, and AAC, each with its specific applicable scenarios and advantages and disadvantages. For example, PCM is a lossless encoding format, suitable for scenarios with high sound quality requirements, but the file size is large; while MP3 or AAC significantly reduces file size through compression algorithms, suitable for network transmission or situations with limited storage space. Encoding parameters can be dynamically adjusted according to the target execution path and operating environment to ensure a balance between performance and quality. For example, this embodiment uses WAV format as an example for illustration.

[0059] Step A33: Set the audio sampling rate and the number of channels. Based on the audio sampling rate and the number of channels, extract data from the real-time audio media stream according to the preset time slice or data block size and encode it in the audio encoding format to generate continuous discrete audio data segments.

[0060] In specific implementation, the audio sampling rate and number of channels can be set, specifically 16000Hz, mono, and 16-bit quantization. Then, the original audio data is extracted from the real-time audio media stream according to the preset time slice or data block size using this audio sampling rate and number of channels, and encoded directly into discrete audio data segments. This avoids acquisition failure due to encoder limitations in non-HTTPS environments and reduces transcoding delay before backend recognition.

[0061] Understandably, when the user ends the recording operation, the system will automatically stop the audio stream capture, stop the recording processing module, close the audio context, and traverse and stop all audio tracks in the real-time audio media stream to release microphone usage, that is, execute in sequence: rec.destroy() (destroy the Recorder instance and release the ScriptProcessor node) → audioCtx.close() (close the AudioContext) → localStream.getTracks().forEach(track => track.stop()) (stop and release the microphone track).

[0062] Step S50: After encapsulating the audio data segment, upload it to the backend service layer via HTTP protocol for speech recognition to obtain the recognized text result.

[0063] Understandably, after obtaining the audio data segment, it can be encapsulated and uploaded to the backend service layer via HTTP for speech recognition processing. During the upload process, the system performs necessary format checks and compression optimizations on the audio data segment to ensure transmission efficiency and stability. Upon receiving the audio data, the backend service layer parses and processes it based on a pre-defined speech recognition model, ultimately outputting the corresponding text result. This process relies on efficient network communication mechanisms and reliable backend algorithm support, ensuring a seamless workflow from audio acquisition to text generation.

[0064] In one feasible implementation, step S50 can be further refined into the following steps: encapsulating the generated discrete audio data segments according to preset rules to form a data packet that meets the requirements of the backend interface; uploading the encapsulated data packet to the backend service layer via the HTTP protocol and monitoring the upload status in real time; and receiving the recognition text result returned by the backend.

[0065] It's important to note that during the encapsulation process, the system adds necessary metadata to the audio data segments according to the backend service layer's interface specifications, such as sampling rate, number of channels, and encoding format. This metadata helps the backend service quickly parse the audio data and select an appropriate speech recognition model for processing. Furthermore, the encapsulation process also limits the size of data packets to avoid network congestion or timeouts caused by excessively large single data transmissions.

[0066] It should be understood that the upload process uses the standard HTTP protocol to ensure compatibility and universality. Simultaneously, the system monitors the upload status in real time, and if a network anomaly or upload failure is detected, a retry mechanism is triggered to improve data transmission reliability. For mission-critical scenarios, a resume capability can also be introduced to further enhance the system's fault tolerance.

[0067] In practice, after the backend service completes speech recognition, it returns the results to the frontend in JSON or other standardized formats. Upon receiving the returned data, the frontend system parses it and extracts the target text content. Specifically, it can upload the WAV file to the backend speech recognition interface (HTTP protocol) via the fetchAPI to obtain the recognized text.

[0068] Step S60: Determine the text to be played based on the identified text result, and then process and play the text to be played.

[0069] In practice, the final text content to be played can be determined based on the text recognition results, and necessary preprocessing operations can be performed on it to adapt to the playback environment. For example, word segmentation, punctuation repair, or semantic analysis can be performed on the text to ensure that it can be accurately conveyed during subsequent playback.

[0070] This embodiment provides a method for mobile audio acquisition and playback in an intranet environment. By dynamically detecting the operating environment, it can flexibly adapt to different intranet conditions, ensuring the stability of audio acquisition and playback. Simultaneously, using the HTTP protocol for data transmission effectively solves the security issues of data interaction in an intranet environment. Furthermore, by encapsulating and uploading audio data segments, efficient speech recognition processing is achieved, reducing the consumption of local computing resources. During playback, text preprocessing is performed according to user needs, improving the accuracy and smoothness of the playback content.

[0071] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S60 includes steps S601 to S604: Step S601: Determine the text to be played based on the identified text results.

[0072] It should be noted that when determining the text to be played, the results of the text recognition can be filtered and optimized. First, natural language processing technology is used to perform semantic analysis on the recognized text, extract key information, and combine it with the context to generate text to be played that meets the user's needs. This process not only removes redundant or erroneous information, but also adjusts the text expression according to the actual application scenario, making it more in line with the understanding habits of the target audience.

[0073] In one feasible implementation, step S601 may include steps B11 to B13: Step B11: Send the identified text result as a business query instruction to the intranet business server; Understandably, after sending the recognized text result as a business query command to the intranet business server, one can wait for the server to return response data related to that command. This process relies on the stability of the intranet environment and the server's processing power to ensure the accuracy and timeliness of the query results.

[0074] Step B12: Receive the service response data returned by the intranet service server based on the service query command; After receiving the data returned by the server, the data is parsed and filtered to extract the core content related to user needs, thereby determining the final text to be played.

[0075] Step B13: Extract natural language feedback content from the business response data and determine the natural language feedback content as the text to be played.

[0076] Specifically, natural language feedback content can be extracted from the business response data, and this natural language feedback content is identified as the text to be played. This process involves parsing the structured data returned by the server, identifying the natural language portion, and reorganizing the content based on user needs to ensure the accuracy and usability of the text to be played. During the extraction process, the system automatically filters out irrelevant or redundant information, retaining core content highly relevant to the user's intent, thereby improving the effect of subsequent playback stages.

[0077] In one feasible implementation, step S601 may further include: directly using the identified text result as the text to be played.

[0078] It should be noted that in some scenarios, if the recognized text is clear enough and meets the user's needs, it can be directly used as the text to be played without additional processing or querying. This approach is suitable for situations with high real-time requirements and where the text content itself already possesses high accuracy, effectively reducing the complexity and latency of system processing.

[0079] Step S602: Segment the text to be played to generate a text queue.

[0080] In practice, a streaming TTS intelligent segmentation algorithm can be used to segment the text to be played, thereby generating multiple text queues.

[0081] In one feasible implementation, step S602 may include steps C11-C13: Step C11: Use regular expressions to scan the text to be played and identify punctuation marks as natural semantic breakpoints; Understandably, the segmentation uses the regular expression ` / ([。!?;\n]) / ` to divide the accumulated textBuffer, thus dividing the text to be played into multiple semantically complete segments. Each segment retains punctuation marks as breakpoints during segmentation to ensure accurate restoration of semantic boundaries in subsequent processing. This approach not only improves segmentation efficiency but also ensures the coherence of text logic, avoiding semantic ambiguity or information loss due to improper segmentation.

[0082] Step C12: Set a maximum text length threshold. When the accumulated text segment length exceeds the maximum text length threshold, truncate and segment the text at the current character according to the natural semantic breakpoint to obtain multiple text sub-segments. In practice, a maximum text length threshold can be set, such as 50 or 100 characters, to match the processing capabilities of the speech synthesis engine. When the accumulated text segment length exceeds this threshold, the system will truncate the text at the current character based on the recognized natural semantic breakpoints. This strategy ensures that each text segment is both semantically complete and does not exceed the input limits of the speech synthesis module, thereby improving the smoothness and accuracy of subsequent playback.

[0083] Step C13: Add the segmented text fragments to the playback queue in sequence to generate a text queue.

[0084] It's important to note that multiple segmented text pieces can be added to the playback queue sequentially according to their order in the original text, thus generating a complete text queue. This process ensures the logical coherence of the playback content and provides a clear execution path for subsequent speech synthesis and playback operations. The system dynamically adjusts the queue priority based on the length and semantic boundaries of each text piece to optimize the playback experience. For example, shorter text pieces may be processed first to reduce user waiting time, while longer pieces will be appropriately allocated to subsequent playback sequences.

[0085] In practice, for example, the accumulated textBuffer can be split using the regular expression / ([。!?;\n]) / , and a complete sentence (including punctuation) can be extracted and added to the queue at a time. The remaining part is kept in the buffer. If the accumulated textBuffer exceeds 30 characters (i.e., the maximum text length threshold), the entire buffer is forcibly added to the queue as a single sentence, thus summarizing the text sequence.

[0086] Step S603: Construct an audio pre-cache pool, initiate an HTTP request to the preset text in the text queue to obtain audio playback data and cache it in the audio pre-cache pool.

[0087] It's important to note that when building the audio pre-caching pool, the system initiates HTTP requests to preset texts in the text queue to retrieve the corresponding audio playback data. This process is implemented by calling the backend speech synthesis interface, ensuring that each text segment is accurately converted into an audio stream. The retrieved audio data is temporarily stored in the pre-caching pool for rapid response in subsequent playback operations. The pre-caching pool is designed to reduce latency caused by real-time synthesis, while optimizing resource utilization and avoiding performance bottlenecks caused by frequent calls to the speech synthesis service. The preset texts are the first N texts in the queue.

[0088] In practice, the system dynamically adjusts the caching order of audio data based on the priority of the text queue. For example, audio data corresponding to high-priority text segments will be loaded into the pre-cached pool first to ensure that critical content can be played in a timely manner.

[0089] Specifically, by creating a cache mapping (ttsCache), i.e. an audio pre-caching pool, for the first N (N can be 3) texts in the queue that have not yet been cached, an HTTP request is initiated in advance to obtain the corresponding audio Blob data, and the Promise is stored in the cache.

[0090] Step S604: Read the audio playback data from the audio pre-buffer pool in the storage order and play it.

[0091] It should be noted that during playback, audio playback data is read from the audio pre-buffer pool in the order it is stored and then passed to the audio playback module for real-time playback. Specifically, Blob data is retrieved from the cache, and an Audio object is created for playback.

[0092] In one feasible implementation, step S604 may include steps D11~D13: Step D11: Before starting the playback task of any text sub-segment, read the current playback status flag; It should be noted that before initiating playback of any text segment, the system first reads the current playback status flag to ensure the accuracy and continuity of the playback operation. This flag indicates the current working state of the audio playback module, such as whether it is idle, playing, or paused. By monitoring this flag in real time, the system can avoid playback anomalies caused by state conflicts, such as repeated playback or interruptions.

[0093] Step D12: If the playback status flag indicates that playback is currently in progress, block or discard the current playback start request to prevent audio overlay concurrency conflicts; Understandably, if the playback status flag indicates that playback is currently in progress, the system will automatically block or discard new playback start requests to avoid audio overlap or concurrent conflicts. This mechanism ensures the stability and smoothness of the playback process, while improving the user experience and preventing content chaos or auditory interference caused by multiple audio segments playing simultaneously.

[0094] Step D13: If the playback status flag indicates that the playback status flag is idle, update the playback status flag to play, and read the audio playback data from the audio pre-buffer pool in the storage order for playback.

[0095] Understandably, when the playback status flag indicates that the audio playback module is idle, the corresponding audio playback data is retrieved from the audio pre-buffer pool, and the actual playback task is triggered by creating an Audio object or other playback mechanisms. This process ensures the efficiency and accuracy of the playback operation, while making full use of the resources in the pre-buffer pool and reducing the latency issues caused by real-time synthesis.

[0096] In practice, the playback task for each text segment is dynamically scheduled to optimize the overall playback effect. For example, if a user manually pauses or stops playback, the system immediately updates the playback status flag and pauses the current audio output. Simultaneously, it records the already played portion so that playback can be seamlessly resumed without reloading or processing audio data.

[0097] Specifically, this embodiment also provides the functions of mute switching and skipping the current playback, which can be achieved by modifying the muted property of the Audio object or by directly pause() and playing the next item.

[0098] In one possible implementation, after step S604, the method further includes: Listen for the end of playback event of the current text sub-segment in the audio playback data; If the playback of the current text segment ends, the object URL release interface is called to destroy the temporary URL address corresponding to the current text segment, and the data reference of the current text segment is removed from the audio pre-cache pool to release memory; Using the playback end event as a trigger signal, detect whether there are any subsequent unbuffered text segments in the playback queue; If there are uncached text fragments, an HTTP request is initiated to retrieve subsequent audio data and store it in the audio pre-cache pool for asynchronous pre-fetching; After completing the immediate release of resources and asynchronous pre-fetching, the playback status flag is reset to idle to allow the next cached segment to start playback.

[0099] It's important to note that in practical applications, a series of resource management and scheduling operations can be triggered based on the playback end event. When the current text segment is detected as finished playing, not only are the temporary URL address and data references associated with that segment released, but the system also actively checks the playback queue for any uncached text segments. If an uncached segment exists, an HTTP request is immediately initiated to retrieve the corresponding audio data, which is then stored in the audio pre-cache pool, thus achieving asynchronous pre-fetch functionality. This mechanism effectively avoids playback interruptions due to insufficient resources or latency, while ensuring that memory usage remains within a reasonable range.

[0100] Furthermore, after completing resource release and asynchronous pre-fetching, the playback status flag is automatically reset to the idle state to prepare for the next text segment to be played. This dynamic adjustment strategy makes the playback process smoother and more efficient, especially when handling long texts or multi-tasking scenarios. By combining real-time monitoring, resource reclamation, and asynchronous loading, the system can maximize performance while ensuring playback quality.

[0101] Furthermore, to enhance the user experience, flexible management of the playback queue is supported. For example, users can insert new text content or adjust the order of existing queues through a specific interface without interrupting the currently playing content. This design not only enhances the system's interactivity but also meets diverse needs in complex scenarios. Simultaneously, all newly added or modified text content is re-segmented, cached, and rescheduled according to a predetermined process to ensure the consistency and accuracy of the overall logic.

[0102] For example, this application's solution is integrated into a mobile policing application used by the municipal public security bureau. Development environment: HBuilderX 4.85, front-end framework Vue 2.6, target device: Android 10 police terminal.

[0103] The specific steps are as follows: Package the web project containing the code of this application into a local app using HBuilderX (select "Cloud Packaging" or "Local Packaging"). Configure the "Permission Configuration" in manifest.json, check the "Recording" permission, and add the "AudioManager" plugin, setting the streamType to music. Figure 4 As shown, Figure 4 This diagram illustrates the interface structure and operation flow of the HBuilderX distribution configuration window. The left-hand configuration bar, also known as the navigation area, includes basic configuration, icon configuration, startup screen configuration, module configuration, permission configuration, and other settings. The right-hand configuration area (taking "Basic Configuration" as an example) includes the application entry page (homepage) address, resource source options for online HTTP resources and local files, and the input box `dist / index.html`, which is the path to the currently selected entry file, typically output to the `dist` directory by the build tool. For full-screen application display, the specific setting is `portrait-primary` for landscape mode.

[0104] When the application starts, PlusHelper detects the App environment and, after waiting for plusready, automatically requests recording permission.

[0105] When a user clicks the voice search button, the speech() function is called to start recording. When the user finishes speaking, they click to stop. The recording file is then uploaded to the intranet HTTP speech recognition server, and the search is automatically performed after the recognized text is returned.

[0106] Search results are returned in text form. The appendTextForTts method is used to segment the response text and add it to the TTS queue to enable voice broadcasting.

[0107] like Figure 5 As shown, Figure 5 This is a visual editing interface diagram of the manifest.json configuration file in an HBuilderX project, focusing on two key parts: "Permission Configuration" and "Module Configuration". The left-hand configuration panel (navigation menu) includes: Basic Configuration, Icon Configuration, Startup Interface Configuration, Module Configuration, Permission Configuration, and Source Code View; "Permission Configuration" / "Module Configuration" is located in the right-hand configuration area, including a list of permission configurations: Record (recording), RECORD_AUDIO (audio), Share (sharing), and Payment (payment). Module configuration includes plugin configuration, specifically: plugins: { AudioManager: { streamType: 'music' } } By combining localized packaging with H5 and bridging architecture, along with the aforementioned methods of environment detection, permission management, resource release, and TTS optimization, the problem of mobile audio acquisition and playback under intranet conditions without HTTPS can be solved.

[0108] This embodiment determines the text to be played based on the identified text results; segments the text to be played to generate a text queue; constructs an audio pre-cache pool; initiates HTTP requests to preset texts in the text queue to obtain audio playback data and caches it in the audio pre-cache pool; and reads the audio playback data from the audio pre-cache pool in storage order for playback. By subdividing the text to be played into multiple text segments and only initiating HTTP requests to the preset text at the front of the queue, the system does not need to wait for the synthesis results of subsequent long texts. Once the audio data of the first segment is returned and filled into the pre-cache pool, playback can be started immediately. This streaming mechanism of simultaneous synthesis, transmission, and playback reduces the user-perceived waiting time from the full synthesis time to the single-segment synthesis time, greatly improving the system's real-time responsiveness and naturalness of interaction.

[0109] For example, to help understand the implementation flow of the mobile audio acquisition and playback method in an intranet environment obtained by combining this embodiment with the above embodiment one, please refer to... Figure 6 , Figure 6 This document provides a simplified flowchart of a mobile audio capture and playback method for an intranet environment. Specifically: Step S1: Environment detection and initialization, including: PlusHelper detects the runtime environment; if it's an App environment, it waits for plusready; if it's a browser environment, it performs a fallback adaptation. Step S2: Dual-path audio permission acquisition; if it's an App environment, it requests a REC using the native API; if it's a browser environment, it directly calls the Web API and then initializes AudioContext / Recol. Step S3: Audio capture and upload, including starting recording (Recorder.start) and stopping recording. Recorder.stop() is encapsulated in WAV format (16000Hz, mono) and then uploaded to the backend speech recognition API. Step S4: Streaming TTS speech synthesis and playback, including: intelligent text segmentation (punctuation / 30 characters), loading the first N text audios into the pre-buffer pool, playing them in sequence in the playback queue, and supporting mute / skip playback control; Step S5: Precise resource release, including: recording resources: destroying Recorder, closing AudioContext, stopping and releasing the microphone track, TTS resources: releasing BlobURL. If any abnormality exists in steps S1-S4, proceed to step S5.

[0110] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the mobile terminal audio acquisition and playback method in the intranet environment of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0111] This application also provides a mobile audio acquisition and playback device for an intranet environment; please refer to [reference needed]. Figure 7 The mobile audio acquisition and playback device in the intranet environment includes: The detection module 100 is used to detect the current application's operating environment.

[0112] The matching module 200 is used to match the corresponding target execution path according to the operating environment.

[0113] The acquisition module 300 is used to acquire real-time audio media streams based on the target execution path.

[0114] The processing module 400 is used to respond to the user's recording command, instantiate the recording processing module and use the real-time audio media stream as the input source to capture and encode discrete audio data segments in real time.

[0115] The upload module 500 is used to encapsulate the audio data segment and upload it to the backend service layer via HTTP protocol for speech recognition, so as to obtain the recognized text result.

[0116] The processing module 400 is further configured to determine the text to be played based on the identified text result, and to process and play the text to be played.

[0117] The mobile audio acquisition and playback device for intranet environments provided in this application adopts the mobile audio acquisition and playback method for intranet environments described in the above embodiments. This solves the technical problem that current intranet environments cannot stably utilize the device's microphone for recording and smoothly play synthesized audio. Compared with the prior art, the beneficial effects of the mobile audio acquisition and playback device for intranet environments provided in this application are the same as those of the mobile audio acquisition and playback method for intranet environments provided in the above embodiments. Furthermore, other technical features of the mobile audio acquisition and playback device for intranet environments are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0118] This application provides a mobile audio acquisition and playback device for an intranet environment. The mobile audio acquisition and playback device for an intranet environment includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the mobile audio acquisition and playback method for an intranet environment as described in Embodiment 1 above.

[0119] The following is for reference. Figure 8 This document illustrates a structural diagram of a mobile audio acquisition and playback device suitable for implementing an intranet environment according to embodiments of this application. The mobile audio acquisition and playback device in the intranet environment of this application can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The mobile audio acquisition and playback device shown in the intranet environment is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0120] like Figure 8 As shown, a mobile audio acquisition and playback device in an intranet environment may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to programs stored in ROM (Read Only Memory) 1002 or programs loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the mobile audio acquisition and playback device in the intranet environment. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, LCDs (Liquid Crystal Displays), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows mobile audio acquisition and playback devices in an intranet environment to exchange data wirelessly or via wired communication with other devices. Although the figure shows mobile audio acquisition and playback devices in an intranet environment with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0121] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0122] The mobile audio acquisition and playback device for intranet environments provided in this application, employing the mobile audio acquisition and playback method for intranet environments described in the above embodiments, can solve the technical problem that current intranet environments cannot stably utilize the device's microphone for recording and smoothly play synthesized audio. Compared with the prior art, the beneficial effects of the mobile audio acquisition and playback device for intranet environments provided in this application are the same as those of the mobile audio acquisition and playback method for intranet environments provided in the above embodiments, and other technical features of this mobile audio acquisition and playback device for intranet environments are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0123] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0125] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the mobile terminal audio acquisition and playback method in the intranet environment described in the above embodiments.

[0126] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory or Flash Memory), optical fibers, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0127] The aforementioned computer-readable storage medium may be included in a mobile audio acquisition and playback device in an intranet environment; or it may exist independently and not be installed in a mobile audio acquisition and playback device in an intranet environment.

[0128] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a mobile audio acquisition and playback device in an intranet environment, the mobile audio acquisition and playback device in the intranet environment performs the following actions: detects the current application's operating environment; matches a corresponding target execution path based on the operating environment; acquires a real-time audio media stream based on the target execution path; responds to a user's recording command, instantiates a recording processing module and uses the real-time audio media stream as an input source to capture and encode discrete audio data segments in real time; encapsulates the audio data segments and uploads them to the backend service layer via HTTP protocol for speech recognition to obtain recognized text results; determines the text to be played based on the recognized text results, processes the text to be played, and then plays it.

[0129] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0130] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0131] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0132] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the mobile audio acquisition and playback method in the above-described intranet environment. This solves the technical problem that current intranet environments cannot stably utilize the device microphone for recording and smoothly play synthesized audio. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the mobile audio acquisition and playback method in the intranet environment provided in the above embodiments, and will not be elaborated upon here.

[0133] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the mobile terminal audio acquisition and playback method in the intranet environment described above.

[0134] The computer program product provided in this application can solve the technical problem that it is currently impossible to stably call the device microphone for recording and smoothly play synthesized audio in an intranet environment. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the mobile terminal audio acquisition and playback method in an intranet environment provided in the above embodiments, and will not be repeated here.

[0135] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for mobile audio acquisition and playback in an intranet environment, characterized in that, The method for mobile audio acquisition and playback in the intranet environment includes: Detect the current application's runtime environment; Match the corresponding target execution path based on the described operating environment; Obtain the real-time audio media stream based on the target execution path; In response to the user's recording command, the recording processing module is instantiated and the real-time audio media stream is used as the input source to capture and encode discrete audio data segments in real time. The audio data segment is encapsulated and uploaded to the backend service layer via HTTP protocol for speech recognition, resulting in the recognized text. Based on the identified text results, the text to be played is determined, and the text to be played is processed and then played.

2. The method as described in claim 1, characterized in that, The steps for processing and playing the text to be played include: The text to be played is segmented to generate a text queue; Construct an audio pre-cache pool, and initiate an HTTP request to a preset text in the text queue to obtain audio playback data and cache it in the audio pre-cache pool; The audio playback data is read from the audio pre-cache pool and played in the order of storage.

3. The method as described in claim 2, characterized in that, The step of reading the audio playback data from the audio pre-buffer pool in storage order and playing it includes: Before starting the playback task of any text segment, read the current playback status flag. If the playback status flag indicates that playback is currently in progress, the current playback start request is blocked or discarded to prevent audio overlay concurrency conflicts. If the playback status flag indicates that the device is idle, update the playback status flag to indicate that the device is playing, and read the audio playback data from the audio pre-buffer pool in the storage order for playback.

4. The method as described in claim 3, characterized in that, The method further includes: Listen for the end of playback event of the current text sub-segment in the audio playback data; If the playback of the current text segment ends, the object URL release interface is called to destroy the temporary URL address corresponding to the current text segment, and the data reference of the current text segment is removed from the audio pre-cache pool to release memory; Using the playback end event as a trigger signal, detect whether there are any subsequent unbuffered text segments in the playback queue; If there are uncached text fragments, an HTTP request is initiated to retrieve subsequent audio data and store it in the audio pre-cache pool for asynchronous pre-fetching; After completing the immediate release of resources and asynchronous pre-fetching, the playback status flag is reset to idle to allow the next cached segment to start playback.

5. The method as described in claim 2, characterized in that, The step of segmenting the text to be played and generating a text queue includes: The text to be played is scanned using regular expressions, and punctuation marks are identified as natural semantic breakpoints. A maximum text length threshold is set. When the accumulated text segment length exceeds the maximum text length threshold, the text is truncated at the current character according to the natural semantic breakpoint to obtain multiple text sub-segments. The multiple text segments are added to the playback queue in sequence to generate a text queue.

6. The method as described in claim 1, characterized in that, The steps of responding to a user's recording command, instantiating a recording processing module, and using the real-time audio media stream as an input source to capture and encode discrete audio data segments in real time include: In response to the user's recording command, the recording processing module is instantiated and the real-time audio media stream is used as the input source; Configure the audio encoding format for the recording processing module; The audio sampling rate and number of channels are set. Based on the audio sampling rate and the number of channels, data is extracted from the real-time audio media stream according to a preset time slice or data block size and encoded in the audio encoding format to generate continuous discrete audio data segments.

7. The method as described in claim 1, characterized in that, The step of obtaining the real-time audio media stream based on the target execution path includes: When the target execution path is the native priority two-level authorization path, the native bridging interface is called to pop up a system-level permission request dialog box to request microphone recording permission; Listen for user authorization confirmation callbacks, and upon receiving a successful authorization signal, call the browser's standard media device interface; Acquire real-time audio media streams in an intranet environment without an HTTPS certificate.

8. The method as described in claim 1, characterized in that, The step of matching the corresponding target execution path according to the operating environment includes: When the runtime environment is a wrapper environment with native capability calls, the native priority two-level authorization path is matched as the target execution path; When the operating environment is a Web operating environment, the Web direct connection authorization path is matched as the target execution path.

9. The method according to any one of claims 1 to 8, characterized in that, The steps for detecting the current application's operating environment include: Check if a preset native bridging namespace exists in the global object and / or resolve whether the user agent string contains a preset client identifier; When a preset native bridging namespace or a preset client identifier is detected, the current application's runtime environment is determined to be an encapsulated environment in which the current application runs with native capability calls. If no preset native bridging namespace is detected and no preset client identifier is contained, the current application's runtime environment is determined to be a web runtime environment.

10. A mobile audio acquisition and playback device for an intranet environment, characterized in that, The device includes: The detection module is used to detect the current application's operating environment; The matching module is used to match the corresponding target execution path based on the operating environment; The acquisition module is used to acquire real-time audio media streams based on the target execution path; The processing module is used to respond to the user's recording command, instantiate the recording processing module and use the real-time audio media stream as the input source to capture and encode discrete audio data segments in real time; The upload module is used to encapsulate the audio data segment and upload it to the backend service layer via HTTP protocol for speech recognition, so as to obtain the recognized text result. The processing module is further configured to determine the text to be played based on the identified text result, and to process the text to be played before playing it.

Images