Offline Real-Time Multilingual Broadcasting Using WebRTC and Local AI Services: Architecture, Performance, and Institutional Evaluation

Abstract

Real-time multilingual communication (RTMC) is increasingly important in academic, governmental, defense, and clinical settings, where cloud-based speech processing may raise privacy, data sovereignty, connectivity, and cost concerns. This study presents Yapzek Stream, a fully offline multilingual broadcasting and speech-translation platform that performs speech recognition, translation, and text-to-speech synthesis within institution-owned infrastructure. The system integrates Web Real-Time Communication (WebRTC)-based broadcasting with locally hosted artificial intelligence (AI) services and provides multilingual audio delivery, browser-based access, recording, transcript and subtitle export, and institutional authentication. The platform was evaluated through an implementation-oriented analysis and a university pilot involving two live sessions with 10 and 50 participants and 12 semi-structured interviews. Estimated end-to-end processing latency was 1.8–4.1 s, while pilot observations ranged from approximately 2 s for short utterances to 4.5–5 s for longer speech. The results indicate the feasibility of offline multilingual broadcasting for privacy-preserving and institution-controlled communication. Deployment-specific accuracy and translation evaluation, controlled scalability and GPU-utilization measurements, robustness testing, and larger-scale user-acceptance studies remain for future work.

1. Introduction

Automated multilingual communication has matured from research aspiration into deployable technology, driven by advances in automatic speech recognition [1], neural machine translation [2], and neural speech synthesis [3]. The prevailing engineering model is cloud-centric: audio is captured locally and transmitted to remote inference services. This model is incompatible with a significant class of operational environments. Defense and critical-infrastructure facilities enforce policies that restrict outbound transmission. Universities and hospitals operate under data-residency frameworks such as the GDPR and Türkiye’s Personal Data Protection Law (KVKK, Law No. 6698), under which speech can carry biometric significance, and many settings face cost pressure or unreliable connectivity. In each case, local control is not merely preferable but required.

In higher education the cloud model carries a further, less visible cost. The internationalization of universities has produced linguistically diverse classrooms [4,5] in which real-time translation and captioning serve both linguistic inclusion and disability accessibility. Yet delivering these services through commercial clouds transmits student and faculty speech to external, often extraterritorial, infrastructure, creating a tension between pedagogical inclusion and institutional data sovereignty. A satisfactory solution must therefore be evaluated not only for technical adequacy but for its economic, accessibility, and governance implications.

This paper presents Yapzek Stream, a platform that performs the full broadcasting and speech-translation chain offline, within institution-owned infrastructure. The system’s central contribution is not a single algorithm but the integration of a low-latency WebRTC broadcasting architecture with local AI services and per-language audio delivery.

We make the following contributions:

• A fully offline multilingual broadcasting architecture operating within institution-owned infrastructure.
• A custom-fork WebRTC SFU extended with language-specific media routing, per-language RTP audio management, and recording logic.
• A local AI pipeline integrating GGML large-v3-turbo speech-to-text, a quantized neural translation model, and local TTS voice models.
• A multilingual delivery model in which original and translated audio are carried as separate, selectable channels.
• A browser/PWA viewer with QR-code onboarding, WebRTC primary delivery, and HLS fallback.
• A security and access-control design combining token-based access, JWT admin login, license validation, IP-to-room assignment, and university room/card-service integration.
• A practical institutional evaluation covering latency budget, bandwidth estimation, pilot stakeholder feedback, data sovereignty, and total-cost-of-ownership implications.

The study is guided by six research questions:

• RQ1. Can a fully offline WebRTC-SFU-based multilingual broadcasting platform support real-time classroom and presentation scenarios without cloud services?
• RQ2. What is the end-to-end latency budget of the local STT → translation → TTS → WebRTC delivery pipeline, and which components dominate perceived latency?
• RQ3. How does the system support multilingual delivery through per-language audio tracks while minimizing unnecessary media delivery to viewers?
• RQ4. What are the bandwidth implications of delivering video, original audio, and multiple synthesized translation channels in representative classroom scenarios?
• RQ5. What authentication, authorization, recording, transcript, and institutional integration mechanisms are required for real-world university deployment?
• RQ6. What are the institutional implications of offline deployment in terms of privacy, data sovereignty, accessibility, cost, and stakeholder acceptance?

The remainder of this paper is organized as follows. Section 2 reviews the related work and background on local speech recognition, neural machine translation, speech synthesis, and the institutional implications of offline AI deployment. Section 3 presents the system architecture and its main components. Section 4 describes the AI processing pipeline, including voice activity detection, speech-to-text, translation, text-to-speech synthesis, and multilingual audio-track management. Section 5 explains the methodology and deployment environment. Section 6 reports the technical results, including latency, bandwidth, model-level accuracy benchmarks, scalability projections, and pilot observations. Section 7 discusses the institutional implications of the system in terms of cost, accessibility, data sovereignty, connectivity, and stakeholder feedback. Section 8 discusses the findings, threats to validity, and future research directions, followed by the conclusions in Section 9.

2. Related Work and Background

2.1. Speech Recognition and Local Inference

Speech recognition has progressed from HMM systems [6] and deep hybrids [7] to end-to-end models using CTC [8] and attention [9]. Whisper [1] established robust multilingual recognition, including for Turkish, via large-scale weak supervision. The implemented system uses a large-v3-turbo variant of this model family in GGML format, executed via bindings to an optimized C++ inference runtime rather than a Python 3.12 framework, using mixed FP16 precision internally. This reflects a broader trend toward efficient local inference of transformer models on commodity hardware.

2.2. Neural Machine Translation and Quantized Local Models

The transformer [2] underlies modern NMT. Compact bilingual systems such as MarianMT [10] and broad-coverage multilingual models such as NLLB-200 [11] represent two poles of the design space; they are discussed here as the background rather than as components of the implemented system. Recent progress in quantized large-model inference has made it feasible to run multi-billion-parameter translation models locally: low-bit (e.g., 4-bit) K-quantization substantially reduces memory and latency at a modest quality cost, enabling offline deployment on a single consumer GPU. The implemented translation layer follows this approach, using a locally hosted quantized Gemma-class general-purpose language model prompted for translation into all active target languages in a single-batch inference call. Using a general LLM for translation, rather than a dedicated NMT model such as MarianMT or NLLB-200, is itself a deployment choice: it consolidates multilingual translation and contextual/terminology handling within a single locally hosted model. More broadly, recent edge-AI and privacy-preserving speech-processing approaches have demonstrated the feasibility of moving inference closer to the data source, reducing dependence on remote cloud services. However, these approaches typically address individual components such as speech recognition, translation, or edge inference rather than the combined problem of offline multilingual broadcasting, selective per-language media delivery, local AI processing, and institution-level access and data-control mechanisms addressed by Yapzek Stream. The contribution of the present work therefore lies primarily in the integration and deployment architecture rather than in proposing a new speech-recognition or translation model.

2.3. Neural Speech Synthesis

Synthesis has advanced from WaveNet [3] and Tacotron-2 [12] to fast end-to-end systems [13]. For offline broadcasting the relevant requirement is local, cross-lingual synthesis with per-language voice models. The implemented system uses a local open-source TTS engine with downloadable voice models rather than a cloud synthesis service.

2.4. Institutional Implications of Offline AI

Three frameworks inform the impact analysis. Digital sovereignty concerns an institution’s control over its data and infrastructure [14,15]; under GDPR Article 9 and KVKK, voice data is protected, making the locus of processing a governance decision [16]. Universal Design for Learning (UDL) holds that environments should be designed for learner variability through multiple means of representation [17,18], which real-time captioning and translation operationalize for both deaf/hard-of-hearing and non-native-language learners. The Technology Acceptance Model and its unified extension [19,20] attribute adoption to perceived usefulness and ease of use, framing the stakeholder feedback reported in Section 7.

3. System Architecture

Yapzek Stream comprises twelve main components, all executing within institution-owned infrastructure with no dependence on external cloud services: (1) a publisher web application; (2) a custom-fork WebRTC implemented as a streaming server; (3) an audio-extraction and voice-activity-detection stage; (4) an STT service using a whisper model through optimized C++ runtime bindings; (5) a translation service using a quantized ~4 B neural model with an optional ~1.8 B secondary engine; (6) a TTS service using local voice models; (7) a per-language RTP audio registry; (8) a browser/PWA viewer; (9) an HLS fallback playback path; (10) recording and transcript storage; (11) a backend Web API for admin, room/user/machine data, and integrations; and (12) an authentication and authorization layer, as illustrated in Figure 1.

3.1. Ingest and Transport

The publisher uses WebRTC exclusively; there is no native RTMP support, and FFmpeg is not used for ingest or egress transcoding. FFmpeg version 7.0.2 was used for recording conversion and for a sample-audio TTS loop-back. The WebRTC-based streaming server is extended with custom media routing, language-track management, and recording logic. Primary viewer delivery uses the WebRTC subscriber mechanism; HLS exists as a secondary, fallback live-playback path for clients or networks where WebRTC subscription is unavailable. This fallback mechanism is intended to support service continuity when the primary WebRTC subscription path is unavailable; however, its effectiveness under controlled failure conditions was not experimentally evaluated in the present study.

3.2. Publish Modes

The publisher supports three modes: an audio-only mode with a placeholder logo; a camera-plus-audio mode using a webcam and microphone; and a screen-plus-audio mode capturing the screen with microphone audio. The camera mode supports real-time background blur via a selfie-segmentation model, and the screen mode supports a picture-in-picture camera overlay.

3.3. AI Processing Tier

Speech recognition uses the GGML large-v3-turbo model through optimized C++ runtime bindings; no Python inference runtime is used. Voice activity is detected by a WebRTC VAD wrapper preceded by an RMS amplitude threshold pre-filter that discards low-energy frames before VAD. Translation uses a locally hosted quantized Gemma-class large language model of approximately four billion parameters in a 4-bit K-quantized medium-size format, prompted for translation, with a secondary approximately 1.8-billion-parameter model available as an alternative engine; translation into the eight active target languages is performed in a single-batch inference call rather than sequentially. Synthesis uses local TTS voice models. No external message broker (e.g., RabbitMQ or Kafka) is used; inter-service communication relies on WebSocket, HTTP, Server-Sent Events, and in-memory channels, with internal job queues coordinating the flow between stages.

3.4. Distribution and Client Access

The viewer is browser-based and installable as a Progressive Web Application (PWA) through a Web App Manifest. Onboarding uses a QR code encoding a URL of the form https://{hostname}/viewer-flow?join_code={CODE} (accessed on 16 August 2026). A viewer may select the original audio, a specific translation language, or mute both. Because the system maintains separate per-language RTP audio channels, a viewer receives only the selected language audio rather than all synthesized channels. HLS provides a secondary, fallback delivery path.

3.5. Recording, Transcript, and Archive

Transcripts are persisted as JSONL, with source and translated transcripts stored separately per session and per language; API endpoints provide transcript download, and the viewer can build SRT subtitle files for download. Recording uses two mechanisms: client-side recording in the publisher browser and server-side stream-to-filesystem recording. Recordings are browsable through a dedicated page with search, filtering, and pagination. Storage is a hybrid of filesystem and database: audio/video recordings and transcript files are stored under a recordings directory, broadcast metadata is stored in a database, machine/user/room data are stored in a separate database via the backend Web API, and TLS certificates are stored on the filesystem.

3.6. Security and Access Control

There is no direct LDAP or Active Directory integration in the current implementation. Authentication and authorization combine several mechanisms: the Go streaming server uses a configurable authentication token; the translation service expects its own token; the backend Web API provides JWT-based admin authentication with admin setup and token-based login; and license-key validation gates access. Role assignment is partly IP-based: publisher IP addresses are mapped to room IDs, and the login page checks the client IP through an API endpoint—if the IP matches an assigned room the user is directed to publisher mode, otherwise the viewer mode is presented. A REST-based integration with an external university card/room service provides additional authorization. The join code is session-bound and stored in browser localStorage. There is no dedicated QR-revocation endpoint; publisher access can instead be blocked by updating the room/IP assignment.

4. The AI Pipeline

4.1. Voice Activity Detection and Speech-to-Text

The system uses a WebRTC Voice Activity Detection wrapper, preceded by an RMS amplitude threshold pre-filter that removes low-energy frames before VAD. Speech recognition uses an open-source large-v3-turbo speech-to-text transformer model in GGML format, executed via bindings to an optimized C++ inference runtime. The model uses mixed FP16 precision internally in the GGML format; INT8 quantization and the CTranslate2 runtime are not used. Recognized segments carry timing information that is used for downstream subtitle and synthesized-audio alignment; however, subtitle alignment accuracy was not independently quantified in the present study.

4.2. Translation Layer

The translation layer uses a locally hosted quantized Gemma-class large language model of approximately four billion parameters, stored in a 4-bit K-quantized medium-size format to balance quality, memory usage, and local inference speed, and prompted to translate the recognized text. A secondary approximately 1.8-billion-parameter model is available as an alternative engine. The production configuration enables eight target languages—Turkish, English, German, French, Spanish, Italian, Arabic, and Russian—while Chinese, Japanese, and Korean are defined as optional languages not active in the production configuration. The service performs batch translation into all active target languages in a single inference call, reducing per-language overhead relative to sequential translation.

4.3. Translation Context and Terminology

Because translation is performed by a prompted general-purpose language model, terminology consistency and contextual quality are handled within the prompt construction and session-level processing logic of the local translation service rather than by a separate post-editing module. Glossary- or prompt-level terminology handling is treated here as a design consideration for domain-specific deployments; a dedicated, separately evaluated terminology-adaptation stage is identified for future work rather than claimed as a discrete implemented component.

4.4. Text-to-Speech Synthesis

The system uses a local open-source TTS engine with local voice models. Voice data exists for Arabic, German, English, Spanish, French, Italian, Japanese, Korean, Russian, and Turkish, and the active set of TTS languages is controlled by server configuration. Synthesized speech is emitted as separate per-language audio streams aligned to the broadcast timeline.

4.5. Per-Language Audio Track Management

The server maintains a registry of language-specific RTP audio tracks, each identified by a naming convention that includes the language code. Viewers subscribe only to the selected language audio stream, which avoids forcing every viewer to receive every synthesized language channel and bounds per-viewer bandwidth to the selected language plus, optionally, the original audio.

4.6. Service Orchestration and Internal Messaging

No external message broker such as RabbitMQ or Kafka is used. Inter-service communication uses WebSocket, HTTP, Server-Sent Events, and in-memory channels, with internal job queues coordinating the flow between the recognition, translation, and synthesis stages. These decoupled communication mechanisms provide architectural support for isolating processing stages, but they should not be interpreted as experimentally validated fault-tolerance mechanisms because service-failure recovery was not tested under controlled fault-injection conditions. The current implementation does not include a priority-weighted GPU batch scheduler; concurrency is managed at the service and job-queue level. Formal characterization of multi-session GPU scheduling is identified for future work.

5. Methodology

5.1. Deployment Environment

The current implementation and deployment are Windows-based; Windows 11 is confirmed by native executable build artifacts. The system is architecturally cross-platform but currently targets Windows, and does not use Docker or Kubernetes. The current deployment was evaluated on an RTX 5090-based system. Although the architecture is designed around locally hosted and quantized models that may support deployment on lower-end consumer GPUs, the present study does not provide controlled performance measurements across GPU tiers. Therefore, the minimum hardware requirements and performance trade-offs on lower-end GPUs remain to be established. The present study therefore does not claim a minimum GPU specification or a specific performance level for lower-end hardware.

5.2. Pilot Evaluation and Data Collection

The platform was evaluated through a university pilot deployment conducted in real educational and presentation-oriented scenarios. The pilot comprised two live sessions involving 10 and 50 participants, respectively, together with 12 semi-structured oral interviews conducted with academic and institutional stakeholders. The live sessions were conducted in real educational and presentation-oriented settings using the deployed multilingual broadcasting workflow, with a single speaker transmitting to multiple listeners and eight active target languages configured in the production setup. The pilot was used to observe end-to-end interaction latency, assess the practical usability of multilingual audio delivery, and obtain qualitative stakeholder feedback on the suitability of the system for educational and institutional use. The evaluation therefore considered both technical observations during live operation and stakeholder perceptions obtained through the semi-structured interviews.

For the latency observations, the end-to-end delay was assessed during live operation by comparing the timing of the speaker’s utterance with the corresponding translated audio becoming available to the listener. Observations were made across short utterances and longer, paragraph-length speech segments during the two live sessions. The resulting range reflects observed minimum-to-maximum behavior across these live demonstrations rather than an average computed from a formally logged sample set. Because no synchronized timestamp log was maintained during the field pilot, an exact observation count cannot be reconstructed reliably; the reported latency range therefore represents the observed minimum-to-maximum behavior across the live demonstrations rather than a formally sampled latency dataset.

Data collection was observational and implementation-oriented rather than a controlled laboratory experiment. The two live sessions were conducted under the deployed institutional configuration rather than under artificially controlled hardware, network, or workload conditions. Accordingly, the pilot was intended to assess practical operation and deployment suitability rather than to provide statistically controlled performance comparisons. The evaluation therefore focused on whether the complete broadcasting workflow could operate in realistic educational and presentation settings and on identifying practical usability and deployment observations.

The 12 oral interviews followed a semi-structured format and were conducted with academic and institutional stakeholders who had direct exposure to the pilot deployment. The interview discussions focused on practical aspects of the system, including perceived latency, usability of multilingual audio delivery, suitability for educational and institutional communication, and the potential relevance of offline processing for institutional control and data sovereignty. The semi-structured format allowed participants to comment on these topics while also permitting additional deployment-related observations to be raised during the discussions.

The pilot did not employ a statistically designed participant-sampling procedure or a formal TAM/UTAUT questionnaire. Participant demographic characteristics and formal recruitment criteria were not systematically documented as part of the original pilot protocol. Consequently, the participant group is treated as a stakeholder-informed pilot sample rather than as a statistically representative sample of the university population. Instead, the participants were treated as stakeholder informants whose observations provided preliminary qualitative evidence regarding practical usability and institutional suitability.

Interview responses were reviewed qualitatively to identify recurring observations relevant to system usability, latency, multilingual delivery, and institutional applicability. No formal quantitative coding, inter-rater reliability procedure, or inferential statistical analysis was applied. The qualitative observations were therefore used as contextual evidence supporting the implementation and deployment findings rather than as statistically generalizable measures of user acceptance.

The pilot observations were complemented by implementation-derived latency analysis and analytical bandwidth estimation. Component-level latency was estimated from the processing characteristics of the deployed pipeline, while end-to-end observations were obtained during live demonstrations. Bandwidth requirements were calculated for a representative classroom scenario based on the configured video and audio bitrates. Published benchmark results of the integrated recognition and translation models were treated separately from deployment-specific performance and were not interpreted as measurements obtained from the present institutional deployment.

To provide a clear link between the research questions and the evidence generated in the study, each research question was mapped to the corresponding source of evidence and its main finding. This mapping was used to distinguish implementation evidence, analytical estimates, pilot observations, and qualitative stakeholder feedback when interpreting the findings and drawing the study conclusions. The study combines system implementation analysis, analytical performance estimation, pilot observations, and qualitative stakeholder feedback. This structure also distinguishes measured or observed evidence from analytical estimates and identifies areas that require further controlled evaluation.

Table 1. Alignment between research questions and study evidence.

RQ	Evidence Used	Main Finding	Conclusion/Interpretation
RQ1	System implementation and pilot	Offline multilingual broadcasting was feasible in the evaluated university scenarios.	The implemented architecture can support the evaluated offline broadcasting scenarios.
RQ2	Latency analysis and pilot observations	The analytical latency budget estimates 1.8–4.1 s; speech accumulation is the largest assumed component.	The analytical budget and pilot observations indicate that speech accumulation is the main latency contributor.
RQ3	Architecture analysis	Separate language-specific RTP tracks enabled selective audio delivery.	Selective language delivery is supported architecturally.
RQ4	Bandwidth estimation	Estimated outbound bandwidth was approximately 20.76 Mbps for the representative 10-listener scenario.	Bandwidth requirements increase with listener count and require empirical validation.
RQ5	System and deployment analysis	Authentication, recording, transcription, and institutional integration mechanisms were implemented.	The implemented mechanisms support institutional deployment requirements.
RQ6	Institutional analysis and stakeholder feedback	Offline deployment provided potential benefits for data sovereignty, accessibility, connectivity, and institutional control.	These benefits are preliminary and context-dependent rather than statistically generalizable.

shows the alignment between the research questions, the evidence used to address them, and the main findings of the study.

6. Technical Results

Consistent with the architectural and deployment focus of this work, this section reports an implementation-derived latency budget, language coverage, a representative bandwidth estimate, and pilot-deployment observations. It deliberately does not report controlled recognition or translation-quality metrics or multi-session performance benchmarks; these were not measured and are identified for future work in Section 8.2. All values below are estimates or pilot observations, not statistically measured means. For clarity, the evidence reported in this section is categorized into three types: implementation-derived analytical estimates, direct observations from the university pilot deployment, and published benchmarks of the integrated component models. Only the pilot observations represent evidence obtained during operation of the complete deployed platform. The analytical estimates and published model benchmarks are not treated as measurements of complete-system performance.

6.1. Latency Budget Analysis

Table 2. Estimated component-level processing-latency budget.

Pipeline Component	Estimated Latency
RMS pre-filter + VAD	20–50 ms
Speech-to-text (STT)	500–800 ms
Translation	50–200 ms
Text-to-speech (TTS)	100–400 ms
AI pipeline total	670–1450 ms

reports the estimated component-level processing-latency budget of the AI pipeline, totaling approximately 670–1450 ms.

6.2. End-to-End Latency Estimation

Table 3. Estimated end-to-end latency.

Pipeline Component	Estimated Latency
Speech accumulation/segmentation	1000–2500 ms
AI processing	700–1500 ms
RTC delivery (LAN)	50–100 ms
Total expected end-to-end	≈1.8–4.1 s

combines the implementation-derived AI processing budget with assumed speech accumulation and local-network delivery components, yielding an estimated end-to-end latency of approximately 1.8–4.1 s.

This value is an analytical budget rather than a directly measured complete-system latency. Within this analytical budget, speech accumulation and segmentation constitute the largest assumed component, whereas local-network RTC delivery contributes comparatively little. This interpretation should therefore be understood as a budget-based inference rather than a statistically measured decomposition of observed latency.

6.3. Language Coverage

The production configuration enables eight active target languages: Turkish, English, German, French, Spanish, Italian, Arabic, and Russian. Chinese, Japanese, and Korean are defined as optional languages and are not active in the production configuration. The translation model produces all active target languages in a single-batch inference call.

6.4. Bandwidth Estimation

Table 4. Representative classroom outbound-bandwidth estimate.

Component	Per Unit	Total
Video (1.5 Mbps × 10 listeners)	1.5 Mbps	15 Mbps
Original audio (64 kbps × 10)	64 kbps	0.64 Mbps
TTS audio (8 × 64 kbps × 10)	512 kbps/user	5.12 Mbps
Total estimated outbound	—	≈20.76 Mbps

presents a representative classroom estimate—one video stream, original audio, eight synthesized target-language audio streams, and ten simultaneous listeners—assuming a video bitrate of 1.5 Mbps and Opus audio at 64 kbps per language. The estimated outbound bandwidth requirement is approximately 20 Mbps.

The RTC configuration includes a per-peer bandwidth limit of 5 Mbps. Actual bandwidth depends on the selected language, audio bitrate, video resolution, and whether all tracks or only selected tracks are delivered; this estimate should be validated through measurement. Because a viewer on the WebRTC subscriber path receives only the selected translation-language audio, the per-viewer figure is substantially lower than this worst-case aggregate.

6.5. Component Model Accuracy (Published Benchmarks)

The recognition and translation accuracy of the platform is determined primarily by its integrated component models. Rather than re-deriving these from scratch, we summarize the models’ published benchmark performance to establish the expected accuracy envelope of the deployed system; deployment-specific evaluation on the institution’s own Turkish academic data is identified as future work (Section 8.2).

Recognition: The system uses whisper-large-v3-turbo, a distilled variant of Whisper large-v3 that attains accuracy close to the full model while running substantially faster. As reported in its published evaluation [1], the model achieves the multilingual word-error rates summarized in

Table 5. Published multilingual word-error rate of the integrated recognition model.

Benchmark/Metric	Whisper-Large-v3-Turbo (WER)
Multilingual average	7.8–8.4%
Male speaker	8.4%
Female speaker	8.0%
Across 99+ languages	~12%

.

Translation: The system uses a Gemma model. In the published WMT24++ evaluation across 55 languages, the 4 B model attains a MetricX score of 5.32, rivaling the standard Gemma 3 12 B baseline (4.86), while the 12 B TranslateGemma variant reaches 3.60.

Table 6. Published translation-quality figures for the integrated translation model.

Metric	TranslateGemma 4 B	Note
MetricX (WMT24++)	5.32	Rivals Gemma 3 12 B baseline (4.86); lower is better
BLEU	≈6.95	Artificially low for LLM output (see below)
ChrF	≈33.28	More representative of fluency

lists the principal reported figures.

A methodological caveat applies to the translation metrics. Like other large language models used for translation, TranslateGemma produces non-literal, lexically diverse output. Because BLEU penalizes any deviation from a strict reference, its absolute values appear artificially low (e.g., ≈6.95 in frozen institutional Arabic tests) even when human raters judge the meaning to be adequate. Character-level ChrF (≈33.28) better reflects morphological fluency, and neural metrics such as MetricX and COMET are now generally preferred over BLEU for evaluating LLM-based translation [21,22]. We therefore report MetricX as the primary translation-quality indicator and treat BLEU as a lower-bound surface-overlap measure rather than a faithful adequacy score. Deployment-specific MetricX/COMET and human evaluation on institutional content remain for future work.

6.6. Projected Scalability and GPU Utilization

Listener scaling and AI processing load are governed by different mechanisms, and conflating them overstates the compute cost of large audiences. The AI pipeline (recognition, translation, synthesis) executes once per active broadcast and is invariant to the number of listeners; adding listeners is a media-fan-out problem handled by the SFU, not an additional inference cost. Consequently, the binding constraint for large audiences is outbound bandwidth, not GPU compute.

Table 7. Projected outbound bandwidth by listener count for a single broadcast.

Listeners (Single Broadcast)	Selected-Track (Est.)	Worst-Case All-Track (Est.)
10	≈15.6 Mbps	≈20.1 Mbps
50	≈78.2 Mbps	≈100.6 Mbps
100	≈156.4 Mbps	≈201.2 Mbps

projects outbound bandwidth for 10, 50, and 100 listeners of a single broadcast under two assumptions: the implemented selected-track path (each viewer receives one video stream plus one selected audio channel) and a worst-case all-track scenario (video plus all eight synthesized channels).

These projections suggest that audiences in the tens may be supportable on a sufficiently provisioned local-area network under the stated bitrate assumptions; however, this inference has not been experimentally validated under increasing concurrent viewer loads. The per-peer 5 Mbps RTC limit further bounds per-viewer consumption. These are calculated estimates and require network-level validation under real conditions.

On the GPU side, the deployment target is a single consumer accelerator. On an NVIDIA RTX 5090 (32 GB), the estimated resident footprint for one broadcast is approximately 6–8 GB—whisper-large-v3-turbo in FP16 (≈1.6 GB), the 4-bit K-quantized Gemma 4 B model (≈3 GB), local TTS voice models (≈0.5–1 GB), and runtime buffers—corresponding to roughly 20–25% of available VRAM. This estimated footprint suggests that additional VRAM capacity remains available for other workloads; however, it does not establish that several concurrent broadcasts can be supported at a given performance level, because controlled multi-broadcast GPU-utilization measurements were not conducted.

6.7. Pilot Deployment Observations

The platform was demonstrated in a university setting using real lecture scenarios, with eight target languages active and a single speaker broadcasting to multiple listeners. Academic stakeholders evaluated the system during these demonstrations. Observed end-to-end latency during the live demonstrations was typically perceived within the 3–4 s range, with shorter utterances producing lower delays and longer paragraph-length utterances producing delays of approximately 4.5–5 s. These observations are qualitative pilot observations rather than statistically aggregated latency measurements. Several participants compared the experience favorably with professional simultaneous interpretation, particularly when domain terminology was preserved, and consistently cited the fact that speech data never leaves institutional infrastructure as the system’s strongest advantage. These observations are qualitative; no formal test scenario is documented in code.

7. Institutional Impact Analysis

Addressing RQ6, we extend the evaluation beyond technical performance to the economic, accessibility, governance, and equity consequences that determine institutional value.

7.1. Total Cost of Ownership

We frame total cost of ownership analytically rather than asserting precise figures. Cloud-based speech services accrue recurring costs that scale with processed minutes, bandwidth, storage, and per-API pricing, and they place a sensitive data stream under external control. Offline deployment instead carries front-loaded costs—hardware acquisition and maintenance—after which the marginal cost of an additional classroom session is comparatively low, and the institution retains both infrastructure and data control. For institutions with sustained, recurring multilingual needs, the predictable, internally controlled cost structure of offline deployment is itself a planning advantage independent of any single cost estimate; precise comparison requires institution-specific accounting and vendor quotations.

7.2. Accessibility and Universal Design for Learning

Real-time captioning and translation operationalize the UDL principle of multiple means of representation [17,18] in two directions at once: synchronized captions render spoken content perceptible for deaf and hard-of-hearing students, while real-time translation reduces the linguistic load on students whose first language differs from the language of instruction. A single offline infrastructure thus serves disability accessibility and linguistic accessibility together, embedding inclusion in the environment by design rather than as retrofitted accommodation.

7.3. Data Sovereignty, Regulatory Compliance, and Connectivity

Because speech can constitute biometric data under GDPR Article 9 and KVKK, the locus of processing is a governance decision [14,15,16]. In Yapzek Stream all speech processing, translation, TTS synthesis, transcript generation, and recording storage remain within institution-owned infrastructure; audio, transcripts, translations, and synthesized speech never leave the institutional network. This architecture can support data-minimization and security-of-processing objectives by keeping speech and related processing within institution-owned infrastructure; however, architectural locality alone does not establish GDPR or KVKK compliance, which also depends on institutional policies, access controls, retention practices, legal bases, consent where applicable, and other organizational and technical safeguards. For institutions handling sensitive research, clinical, or governmental discourse, this property may represent an important governance advantage, although its practical significance depends on the institution’s specific regulatory and operational requirements.

Because the platform operates over a local network without external connectivity, it can support institutions where reliable internet is unavailable or undesirable—including rural and under-resourced universities that cloud-dependent solutions effectively exclude, and secure facilities where external connectivity is prohibited. The same architectural choice that secures sovereignty for well-resourced institutions extends multilingual and accessibility provision to connectivity-constrained ones.

7.4. Pilot Demonstrations and Stakeholder Feedback

In addition to the technical evaluation, the pilot field study described in Section 6.7—two live sessions with 10 and 50 participants and 12 semi-structured oral interviews—provided preliminary stakeholder feedback on the practical use of the system in institutional settings. These sessions used real-time multilingual lecture scenarios, allowing participants to assess latency, translation usefulness, usability, and operational fit within institutional workflows.

Qualitative feedback from the academic and institutional stakeholders who participated in the pilot highlighted the offline deployment model, multilingual capabilities, and operational simplicity as perceived advantages. Participants also highlighted data sovereignty and institutional control as important considerations when comparing offline institutional deployment with cloud-based alternatives, particularly in environments where speech recordings, classroom discussions, research activities, or administrative meetings contain sensitive information.

User feedback suggested that the observed end-to-end latency, typically perceived within the 3–4 s range during live demonstrations, was acceptable for educational and presentation-oriented use cases. Several participants compared the overall experience favorably with professional simultaneous interpretation services, particularly when domain-specific terminology was preserved correctly throughout the translation process.

Stakeholders also emphasized the importance of maintaining all speech processing within institution-owned infrastructure. The fact that audio streams, transcripts, translations, and synthesized speech never leave the institutional network was frequently cited as a key differentiator compared with commercial cloud-based solutions.

Although these findings are based on pilot demonstrations and qualitative stakeholder feedback rather than a formal TAM/UTAUT survey instrument, they provide preliminary stakeholder perceptions regarding the platform’s practical usability and potential usefulness in the evaluated educational settings. A larger-scale quantitative user-acceptance study remains part of future work.

8. Discussion

The architecture demonstrates that real-time multilingual broadcasting can be delivered offline by composing a WebRTC as the core low-latency media layer with local AI inference as the privacy-preserving processing layer. The per-language RTP track design is the principal scalability mechanism for multilingual audio, since it lets each viewer receive only the selected language rather than every synthesized channel; WebRTC serves as the primary low-latency delivery path with HLS as fallback. The analytical latency budget suggests that speech accumulation and segmentation constitute the largest assumed component of end-to-end latency rather than media transport, suggesting that future latency reductions may benefit from improvements in segmentation strategy. More broadly, offline deployment functions simultaneously as an engineering architecture and an institutional governance strategy: it keeps sensitive speech within the institutional boundary while matching the responsiveness expected of live interpretation. The current deployment is Windows-based and architecturally cross-platform, and the present evaluation—latency budgeting, bandwidth estimation, and pilot feedback—motivates but does not substitute for the controlled benchmarking identified below.

8.1. Threats to Validity

This work focuses on architecture, deployment, and institutional evaluation. The accuracy figures in Section 6.5 are published benchmarks for the integrated component models and characterize an expected envelope; they are not a controlled evaluation on the authors’ institutional data. Latency, bandwidth, scalability, and GPU-utilization figures are analytical estimates and projections rather than statistical measurements. Deployment-specific WER, MetricX/COMET, human evaluation, and large-scale concurrency measurement remain future work. The study also does not include controlled robustness, fault-tolerance, subtitle-alignment, or cross-architecture benchmarking experiments. These omissions limit the extent to which system resilience, subtitle synchronization accuracy, and comparative performance can be inferred from the present results.

Several limitations bound these conclusions. The pilot field study, while conducted under real conditions with 10- and 50-participant sessions and 12 interviews, is small and observational rather than a controlled experiment with logged instrumentation; latency values are direct observations rather than statistically aggregated measurements. No formal multi-session benchmark is documented in code; existing recordings indicate realistic classroom use but do not constitute a controlled experimental corpus. Latency values are implementation-derived estimates and pilot-observation ranges, not statistical measurements. Bandwidth values are calculated estimates requiring network-level validation. A controlled quantitative comparison with alternative cloud-based or local architectures was not performed under identical hardware, network, speech-input, and workload conditions. Accordingly, the latency, bandwidth, and model-level accuracy values reported in this study are not intended to demonstrate superiority over alternative architectures. Controlled cross-architecture benchmarking remains an important direction for future work. Stakeholder feedback is qualitative and preliminary rather than a formal TAM/UTAUT survey. Translation and recognition quality have not yet been quantified and require future WER, BLEU/ChrF, and human evaluation. Subtitle alignment accuracy was also not independently evaluated. Future work should quantify temporal alignment error between recognized segments, generated subtitles, and synthesized audio under different speech rates and segmentation conditions.

8.2. Future Work

Several quantitative evaluations were outside the scope of this architecture- and deployment-focused study and are planned as future work:

• Controlled, deployment-specific WER evaluation on Turkish academic speech (beyond the published model-level WER of ≈7.8–8.4%).
• MetricX/COMET, ChrF, and BLEU evaluation on institutional content for the eight active target languages.
• Human translation-quality evaluation with qualified raters.
• Measured GPU-utilization profiling on the RTX 5090 deployment target under multi-broadcast load (beyond the estimated 20–25% single-broadcast footprint).
• Benchmarking across lower-end GPU tiers to quantify the trade-offs among VRAM capacity, inference latency, throughput, and deployment cost.
• Multi-session concurrency benchmarking under controlled load.
• Empirical scalability testing at 10, 50, and 100 simultaneous listeners to validate the bandwidth projections of Table 6.
• Network stress testing under varied bandwidth and loss conditions.
• Robustness evaluation under speech noise, packet loss, bandwidth degradation, and long-utterance conditions.
• Fault-injection experiments involving temporary STT, translation, TTS, and WebRTC service interruptions to quantify recovery behavior and service continuity.

Further engineering directions include a larger-scale TAM/UTAUT user-acceptance study, an explicit QR/session-revocation endpoint, optional LDAP/Active Directory integration, multi-GPU scaling, Linux deployment validation, and extension beyond the eight active production languages.

9. Conclusions

This paper presented Yapzek Stream, a fully offline multilingual broadcasting platform built around a custom-fork WebRTC SFU and local AI services. The system integrates large-v3-turbo speech recognition, a quantized Gemma-class language model prompted for translation, and local TTS voice models to generate selectable per-language audio streams within institution-owned infrastructure. The platform supports WebRTC publisher input, WebRTC viewer subscription, HLS fallback, PWA access, QR-code onboarding, local recording, JSONL/SRT transcript export, and institutional authentication and authorization mechanisms. Implementation-derived latency budgeting indicates an expected end-to-end latency of approximately 1.8–4.1 s, with pilot demonstrations reporting user-perceived latency around 3–4 s. The architecture offers potential institutional advantages in privacy, data control, accessibility, and predictable cost by eliminating external cloud dependency for speech processing; the magnitude of these advantages remains context-dependent and requires institution-specific assessment.

Future work should provide deployment-specific recognition and translation evaluation, controlled multi-session and scalability measurements, GPU-utilization profiling, robustness and fault-tolerance testing, and larger-scale user-acceptance studies. These evaluations are necessary before broader claims about accuracy, scalability, comparative performance, or general institutional effectiveness can be made.