Capturing audio from a video conference directly in a browser on Linux is a challenge that still intrigues many users. The lack of simple native solutions often leads to tinkering with bots or external tools. However, there is a smoother method, avoiding these complications, that is absolutely worth knowing.
Why capturing audio from a video conference is so tricky on Linux
In such cases, it’s better to first understand what the system and the browser offer. Linux does not manage system audio capture as simply as Windows. For example, on Windows, sharing an entire screen with audio is a fairly common and reliable feature. On Linux, this option is simply absent in Chromium. This complicates capturing when using the desktop application of Zoom or Teams.
For audio capture to work, the browser must receive the audio stream directly. Here’s the catch: when sharing a window of a desktop video application, the browser does not capture the associated audio. The audio track is missing even though the video preview is there. This is not a bug, it’s a technical limitation.
This specific aspect explains why some people get into a complex setup with PulseAudio or PipeWire to create a “null-sink” that reroutes the sound. It’s clean, but requires a mastery of the system that not all users necessarily have.
How Chromium’s tab sharing partially solves the problem
Chromium offers three screen sharing surfaces: a tab, a window, or the entire screen. In these three cases, audio is captured differently depending on the system and the selected surface.
On Linux, sharing a Chromium tab is the only reliable method to capture audio from the video conference. The audio box is often checked by default in this context, which includes the sound emitted by the tab. In short, a video conference on Google Meet or Teams web in the Chromium tab will be fully captured sound-wise without requiring external tools.
On the other hand, sharing a window or even the entire screen will not yield any audio on Linux. This nuance can be tricky at first, especially since it is common practice on Windows to check audio capture for the entire screen.
Setting up audio capture for real-time recognition and recording
Once the audio track is available, the process relies on the Web Audio API in Chromium and the use of MediaRecorder. Instead of recording a file, this method involves chopping the stream into small mono PCM16 chunks at 16 kHz, which are then sent to a server via WebSocket.
This forms the basis for a meeting assistant that analyzes speech in real-time and triggers suggestions or instant summaries. An efficient system that does not disrupt participants because it does not involve any bots in the video conference. It is a local browser extension that only processes the audio captured by the user.
The key here is the property systemAudio: “include” passed to getDisplayMedia(), recommended in the official Chromium documentation. On Linux, it does not create a new capability but confirms the integration of the sound from the shared tab.
Linux, Chromium, and the absence of solutions for Firefox or Safari
Unfortunately, the situation becomes more complicated with other browsers. Firefox cannot capture the audio from a tab, nor can Safari. In 2026, Chromium remains the essential reference for this type of operation, whether on Debian, Arch, or Fedora.
Of course, one can tinker with PulseAudio or PipeWire, but beware, these are technical setups, more suited for system administrators than average users. This method is clean but requires fine configuration, often documented in specialized tutorials.
For those who would like to experiment, there is a clear overview on how to manage your microphone and audio output on Linux, with tips tested by the community on this resource. For a more general approach to the subject of audio recording in the browser, the Chromium documentation remains a must-read: how to manage video and audio capture.
Best practices for undisturbed audio recording
Doing anything other than sharing a WebRTC tab in Chromium can quickly become a headache or result in zero audio. Common sense dictates that one should leverage what is available rather than complicate things for an uncertain effect. Sharing the tab where the video conference is taking place ensures sound quality and avoids surprises.
Care must also be taken not to trigger capture without the participants’ knowledge. Transparency and consent remain essential principles, especially in a professional or institutional context. Finally, audio stream latency often divides the user experience, but with proper configuration of the MediaRecorder and WebSocket, this delay can be easily limited.
In 2026, capturing audio in a web video conference without installing a bot or third-party software remains a subtle feat, requiring a keen technical understanding and a trusty browser ally.
Is it possible to capture audio from a desktop video conferencing application on Linux?
No, the browser does not have access to the audio stream from desktop applications like Zoom or Teams. Capture is limited to the content shared in a Chromium tab.
Why share a Chromium tab rather than the entire screen to capture audio?
On Linux, only sharing a tab provides reliable audio capture. Sharing the entire screen or a window does not transmit sound.
Is there an alternative to Chromium for recording audio from a video conference?
Currently, Firefox and Safari do not offer this functionality. Chromium remains the best technical option.
How can the quality and latency of audio capture be improved?
Using lightweight audio formats like PCM16 mono at 16 kHz via MediaRecorder and sending via WebSocket reduces latency while maintaining the necessary quality for effective recognition.
Can suggestions be automated during a meeting via captured audio?
Yes, systems can process audio streams in real-time and trigger interactions or suggestions without manual intervention or bots present in the video conference.
Source: linuxfr.org
