# How to Debug Audio Pipeline Issues Using RUST_LOG Environment Variables in Meetily

> Debug Meetily audio pipeline problems by setting RUST_LOG to debug. Capture granular Rust diagnostics in your terminal for faster troubleshooting. Learn how now.

- Repository: [Zackriya Solutions/meetily](https://github.com/Zackriya-Solutions/meetily)
- Tags: how-to-guide
- Published: 2026-07-10

---

**Set the `RUST_LOG` environment variable to `debug` or `app_lib::audio=debug` before launching Meetily to capture granular diagnostics from the Rust audio pipeline directly in your terminal.**

Meetily’s audio pipeline is built in Rust and runs inside a Tauri desktop application. Understanding how to debug audio pipeline issues using RUST_LOG environment variables and the Developer Console helps you trace buffer overflows, latency problems, and mixing errors in real time. This guide walks through the initialization code in [`main.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/main.rs), explains how to filter log noise with granular levels, and shows you exactly which diagnostic statements to monitor in [`pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/pipeline.rs).

## How RUST_LOG Is Initialized in the Codebase

The logging infrastructure is bootstrapped in [[`frontend/src-tauri/src/main.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/main.rs)](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/main.rs). By default, the application sets the `RUST_LOG` level to `info` and initializes `env_logger` before the Tauri app starts:

```rust
std::env::set_var("RUST_LOG", "info");
env_logger::init();

```

This configuration means that any module using the standard `log` crate macros (`debug!`, `info!`, `warn!`, `error!`) will emit output to the terminal, but only at the `info` level or higher by default.

## Configuring Log Levels for Audio Debugging

To debug audio pipeline issues using RUST_LOG environment variables, override the default level before launching the application. The most reliable method is to prepend the variable to your launch command in the terminal.

**Global debug output** (verbose, includes all modules):

```bash
RUST_LOG=debug ./frontend/clean_run.sh

```

**Granular audio-only debugging** (recommended for pipeline issues):

```bash
RUST_LOG=app_lib::audio=debug ./frontend/clean_run.sh

```

The second approach filters output to only the `app_lib::audio` module, keeping the signal-to-noise ratio manageable while you trace specific audio flow issues.

## Diagnostic Output in the Audio Pipeline

The core mixing logic resides in [[`frontend/src-tauri/src/audio/pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/pipeline.rs)](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/pipeline.rs) and contains strategic logging statements that trace every critical step:

- **Ring-buffer initialization** – At approximately line 37, `AudioMixerRingBuffer::new` emits an `info!` log reporting the configured window size and maximum buffer capacity.
- **Periodic health checks** – Around line 55, the `add_samples` function logs a `debug!` message every 200 samples showing current mic and system buffer lengths.
- **Overflow warnings** – Lines 68 and 73 contain `warn!` and `error!` macros that fire when either the microphone or system audio buffer exceeds its safety limit, outputting the exact sample counts and nature of the overflow.

When you run with `RUST_LOG=app_lib::audio=debug`, you will see output resembling:

```text
[2024-01-15T10:30:45Z INFO  app_lib::audio] Initializing AudioMixerRingBuffer with window_size=1024, max_buffer_size=16384
[2024-01-15T10:30:45Z DEBUG app_lib::audio] 📊 Ring buffer status: mic=512 samples, sys=480 samples (max=16384)

```

## Viewing Logs: Terminal vs. Developer Console

You have two primary interfaces for viewing diagnostics when debugging audio pipeline issues using RUST_LOG environment variables and the Developer Console:

**Terminal Output (Primary)**

The terminal where you launched the application is the most reliable destination. All `log` crate output appears there prefixed with the module name (e.g., `app_lib::audio`). This is where you will see the `debug!`, `info!`, `warn!`, and `error!` statements from [`pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/pipeline.rs).

**Tauri Developer Console (Secondary)**

Open the Chromium DevTools inside the Meetily window to view frontend JavaScript logs:

- **macOS:** `Cmd + Shift + I`
- **Windows/Linux:** `Ctrl + Shift + I`

Rust logs do not automatically appear in the console tab. To forward them, you must explicitly emit a Tauri event from Rust and handle it in the frontend, but for most audio pipeline debugging, the terminal view is sufficient and avoids the overhead of event bridging.

## Step-by-Step Debugging Workflow

Follow this workflow to isolate and resolve audio pipeline issues:

1. **Set a granular log level** – Use `RUST_LOG=app_lib::audio=debug` to isolate audio messages and reduce noise from other modules.

2. **Start a recording session** – Trigger the UI action that initializes the audio pipeline. You will see the `info!` line from `AudioMixerRingBuffer::new` (line 37) reporting the ring-buffer settings.

3. **Monitor buffer health** – Watch the terminal for periodic `debug!` logs (line 55) appearing approximately every 200 samples, showing mic and system buffer statuses.

4. **Identify overflows** – If buffers exceed limits, `warn!` (line 68) or `error!` (line 73) will appear with specific sample counts and overflow types (e.g., "Microphone buffer overflow" or "System audio buffer overflow").

5. **Tune and repeat** – Adjust constants like sample rate, window size, or `max_buffer_size` in `AudioMixerRingBuffer::new`, then restart the app to see updated `info!` logs reflecting the new parameters.

## Key Source Files

- **[[`frontend/src-tauri/src/main.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/main.rs)](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/main.rs)** – Sets the default `RUST_LOG=info` and initializes `env_logger`.
- **[[`frontend/src-tauri/src/audio/pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/pipeline.rs)](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/pipeline.rs)** – Core mixing logic with extensive logging at lines 37, 55, 68, and 73.
- **[[`frontend/src-tauri/src/audio/diagnostics.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/diagnostics.rs)](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/diagnostics.rs)** – Optional helper utilities for emitting structured diagnostic events.
- **[[`frontend/src-tauri/src/console_utils/console_utils.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/console_utils/console_utils.rs)](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/console_utils/console_utils.rs)** – Demonstrates programmatic manipulation of `RUST_LOG` settings.

## Summary

- **Set `RUST_LOG`** before launching Meetily to control verbosity; use `app_lib::audio=debug` to isolate audio pipeline messages.
- **Monitor [`pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/pipeline.rs)** at lines 37, 55, 68, and 73 for initialization info, health checks, and overflow warnings.
- **Use the terminal** as your primary debug view; Rust logs appear there automatically when `env_logger` is initialized.
- **Follow the 5-step workflow** to systematically identify buffer overflows and latency issues by correlating log timestamps with UI actions.

## Frequently Asked Questions

### Why don't Rust logs appear in the Tauri Developer Console?

Rust logs emitted via the `log` crate write to stdout/stderr, which appears in your terminal, not the Chromium DevTools console. The Developer Console only displays JavaScript `console.log` output from the frontend. To see Rust logs there, you must explicitly emit Tauri events from Rust and handle them in the frontend TypeScript code, though for debugging audio pipelines, the terminal output is more direct and efficient.

### How do I reduce log noise when debugging only the audio subsystem?

Instead of setting `RUST_LOG=debug`, which enables verbose output from every crate, use a module-specific filter: `RUST_LOG=app_lib::audio=debug`. This targets only the audio module in [`pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/pipeline.rs), suppressing logs from Tauri internals, HTTP clients, or other dependencies while preserving the diagnostic signals you need.

### What do the overflow warnings in pipeline.rs indicate?

The `warn!` and `error!` macros at lines 68 and 73 in [`pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/pipeline.rs) fire when the internal ring buffers—used to store microphone or system audio samples—exceed their configured `max_buffer_size`. This typically indicates that the consumer is not processing samples fast enough, causing latency or data loss. The log messages include the exact sample counts and buffer names, allowing you to determine whether the bottleneck is in the microphone stream or system audio capture.

### Can I change the log level without restarting Meetily?

No. The `RUST_LOG` environment variable is read once during `env_logger::init()` execution in [`main.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/main.rs) at application startup. To change verbosity, you must exit the application, set the new level (e.g., `export RUST_LOG=trace`), and relaunch. For runtime adjustments, you would need to implement a custom logging subscriber that responds to Tauri events, which is not included in the default Meetily configuration.