# How to Debug Audio Capture Issues on Windows Using WASAPI in Meetily: A Complete Guide

> Fix Windows audio capture problems in Meetily by debugging WASAPI. Learn to enable logging, inspect device capabilities, and resolve configuration or latency issues with this comprehensive guide.

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

---

**Enable verbose logging with `RUST_LOG=meetily::audio=debug` and inspect the device capabilities output from `log_device_capabilities` in [`audio/diagnostics.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/diagnostics.rs) to identify configuration mismatches, buffer latency issues, and device enumeration failures.**

Meetily relies on the `cpal` crate's **WASAPI** backend to capture microphone and system audio on Windows. When recordings fail silently or capture the wrong device, systematic debugging tools help trace issues from device enumeration through stream configuration. This guide walks through the exact source code paths in the `Zackriya-Solutions/meetily` repository that handle Windows audio discovery, configuration, and diagnostics, showing you how to enable detailed logs and interpret the output to resolve capture problems.

## Understanding WASAPI Device Enumeration in Meetily

Meetily builds its device list through a two-stage process that queries the Windows Audio Session API (WASAPI) host and resolves compatible stream configurations.

### The Entry Point: configure_windows_audio

Device enumeration begins in [`audio/devices/platform/windows.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/devices/platform/windows.rs) at line 7, where the `configure_windows_audio` function constructs a vector of `AudioDevice` structs.

```rust
// https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/devices/platform/windows.rs#L7-L45
pub fn configure_windows_audio(host: &cpal::Host) -> Result<Vec<AudioDevice>> {
    // Attempts cpal::host_from_id(cpal::HostId::Wasapi)
    // Falls back to default host if enumeration fails
    // Adds default input/output as last resort when no devices found
}

```

The function first attempts to initialize the dedicated WASAPI host. If this fails, it falls back to the default host. When enumeration returns no devices, Meetily automatically injects the system default input and output devices to ensure the UI never presents an empty list.

### Resolving Stream Configurations with get_windows_device

Once a user selects a device from the UI, `get_windows_device` (lines 96-156 in the same file) resolves the abstract `AudioDevice` into a concrete `cpal::Device` with a compatible `SupportedStreamConfig`.

```rust
// https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/devices/platform/windows.rs#L96-L156
pub fn get_windows_device(
    audio_device: &AudioDevice
) -> Result<(cpal::Device, cpal::SupportedStreamConfig)> {
    // Prefers default input/output configs
    // Falls back to first F32 stereo config
    // Final fallback to first available config entry
}

```

This function prioritizes the device's default configuration. If unavailable, it iterates through supported configs, selecting the first **F32 stereo** configuration, then falling back to the first entry regardless of format.

## Enabling Verbose Diagnostics Logging

Meetily uses the `log` crate for structured diagnostics. To capture WASAPI-specific debug information, set the environment variable before launching the application:

```powershell

# Windows PowerShell

$env:RUST_LOG="meetily::audio=debug,meetily::audio::diagnostics=info"
.\clean_run_windows.bat

```

- **`debug`** level shows device enumeration traces, including `debug!("Using WASAPI host …")` and `debug!("Found Windows input device …")` statements.
- **`info`** level prints the formatted diagnostic box from `log_device_capabilities`.

Logs appear in the terminal running the Tauri process. You can also view them in the Tauri DevTools console (Ctrl + Shift + I) by opening the Console tab.

## Interpreting Device Capability Reports

After device selection, Meetily invokes `log_device_capabilities` in [`audio/diagnostics.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/diagnostics.rs) (lines 24-88) to emit a structured diagnostic report.

```rust
// https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/diagnostics.rs#L24-L88
pub fn log_device_capabilities(
    device: &AudioDevice,
    config: &SupportedStreamConfig,
    detected_kind: InputDeviceKind
) {
    // Prints formatted box containing:
    // - Platform (std::env::consts::OS)
    // - Device name, type, sample rate, channels
    // - Buffer size, sample format, calculated latency
    // - Adaptive timeout ranges (InputDeviceKind::buffer_timeout())
    // - Platform-specific hints (Bluetooth vs. USB)
}

```

Key metrics to verify in this output include:
- **Sample rate**: Should ideally be 48000 Hz for optimal performance.
- **Buffer size**: Indicates latency; unusually high values suggest driver issues.
- **Timeout ranges**: Bluetooth devices show different adaptive timeouts than wired USB devices.
- **Warnings**: The internal `check_for_issues` function flags low-latency Bluetooth configurations or non-standard sample rates.

For a concise overview, use `log_detection_summary` instead of the full capabilities report.

## Step-by-Step Debugging Workflow

Follow this systematic approach to isolate Windows audio capture failures:

1. **Verify device enumeration**: Check terminal output for `debug!("Found Windows input device …")` lines from `configure_windows_audio`. Confirm your target microphone or loopback device appears in the list.

2. **Inspect chosen configuration**: Look for `info!("Using default input config …")` or fallback messages from `get_windows_device`. If you see fallback logic triggered, the explicit device name may not match any WASAPI entry—verify spelling in the UI dropdown.

3. **Review the diagnostics box**: Examine the `log_device_capabilities` output for sample rate, buffer size, and latency values. Ensure the configuration matches your hardware capabilities.

4. **Spot configuration warnings**: Check for diagnostic warnings about Bluetooth low latency, high wired latency, or non-48000 Hz sample rates in the `check_for_issues` output within [`diagnostics.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/diagnostics.rs).

5. **Monitor pipeline health**: The audio mixing pipeline in [`audio/pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/pipeline.rs) calls `log_buffer_health`, `log_mixer_status`, and `log_performance_summary` to report buffer utilization and overflow warnings in real-time.

6. **Test with minimal UI**: Rule out frontend issues by invoking the Tauri command `start_recording` directly from the DevTools console with explicit device names to verify backend functionality.

## Practical Debugging Commands

### Manual Device Inspection via Temporary Command

Add this helper to [`src-tauri/src/audio/debug_commands.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/src-tauri/src/audio/debug_commands.rs) to diagnose specific devices without starting a full recording:

```rust
#[tauri::command]
pub async fn debug_wasapi_device(name: String) -> Result<(), String> {
    // 1. Load all devices
    let host = cpal::default_host();
    let devices = crate::audio::devices::platform::windows::configure_windows_audio(&host)
        .map_err(|e| e.to_string())?;

    // 2. Find requested device
    let device = devices.into_iter()
        .find(|d| d.name == name)
        .ok_or_else(|| format!("Device '{}' not found", name))?;

    // 3. Resolve stream config
    let (cpal_dev, cfg) = crate::audio::devices::platform::windows::get_windows_device(&device)
        .map_err(|e| e.to_string())?;

    // 4. Emit diagnostics
    crate::audio::diagnostics::log_device_capabilities(
        &device,
        &cfg,
        crate::audio::device_detection::detect_input_device_kind(&device),
    );
    Ok(())
}

```

Register the command in [`lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/lib.rs):

```rust
.invoke_handler(tauri::generate_handler![
    // ... existing handlers ...
    debug_wasapi_device,
])

```

Then test from the frontend console:

```javascript
await invoke('debug_wasapi_device', { name: 'Microphone (Realtek Audio)' });

```

### Using Existing Recording Commands

Alternatively, trigger diagnostics through the standard recording flow:

```javascript
await invoke('start_recording', {
  mic_device_name: "Microphone (Realtek Audio)",
  system_device_name: null,
  meeting_name: "Debug Session"
});

```

The [`recording_manager.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/recording_manager.rs) orchestrator automatically calls `log_device_capabilities` when initializing the audio pipeline, printing the diagnostic box to your terminal.

## Key Source Files for Reference

| File | Role |
|------|------|
| **[`audio/devices/platform/windows.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/devices/platform/windows.rs)** | Enumerates WASAPI devices and resolves stream configurations via `configure_windows_audio` and `get_windows_device`. |
| **[`audio/devices/discovery.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/devices/discovery.rs)** | Calls platform-specific enumeration and populates the UI device list with `AudioDevice` structs. |
| **[`audio/diagnostics.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/diagnostics.rs)** | Contains `log_device_capabilities`, `log_detection_summary`, and `check_for_issues` for detailed capability reporting. |
| **[`audio/pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/pipeline.rs)** | Manages audio mixing and emits buffer health metrics via `log_buffer_health` and `log_mixer_status`. |
| **[`audio/recording_manager.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/recording_manager.rs)** | Orchestrates device selection and ties diagnostics into the recording lifecycle. |
| **[`audio/recording_commands.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/recording_commands.rs)** | Exposes Tauri commands that the frontend invokes to start or stop recording sessions. |

## Summary

- **Enable debug logging** by setting `RUST_LOG=meetily::audio=debug` before launching Meetily to capture WASAPI enumeration traces.
- **Trace the code path** from `configure_windows_audio` through `get_windows_device` to verify your hardware appears in the device list and resolves to a valid `SupportedStreamConfig`.
- **Inspect diagnostic output** from `log_device_capabilities` to confirm sample rates (target 48000 Hz), buffer sizes, and latency values match your hardware specifications.
- **Check for warnings** about Bluetooth latency or configuration mismatches in the diagnostics box emitted by [`audio/diagnostics.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/diagnostics.rs).
- **Monitor real-time performance** through pipeline logs in [`audio/pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/pipeline.rs) to identify buffer overruns or mixing issues during active recordings.

## Frequently Asked Questions

### How do I enable debug logging for WASAPI in Meetily?

Set the `RUST_LOG` environment variable to include `meetily::audio=debug` before running the application. In PowerShell, execute `$env:RUST_LOG="meetily::audio=debug,meetily::audio::diagnostics=info"` then run `.\clean_run_windows.bat`. This exposes device enumeration traces and the capabilities diagnostic box in your terminal output.

### Why isn't my microphone appearing in the Meetily device list?

Check the `configure_windows_audio` function in [`audio/devices/platform/windows.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/devices/platform/windows.rs) for `debug!("Found Windows input device …")` lines. If your device doesn't appear, WASAPI enumeration may have failed and Meetily fell back to default devices. Verify the microphone is not disabled in Windows Sound settings and that no other application has an exclusive lock on the device.

### What sample rate should Windows audio devices use for optimal Meetily performance?

Meetily prefers **48000 Hz** sample rates for optimal performance. The `log_device_capabilities` function in [`audio/diagnostics.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/audio/diagnostics.rs) flags non-48000 Hz configurations with warnings. While the software supports other rates through `cpal`'s format negotiation, 48000 Hz ensures the lowest latency and compatibility with the internal mixing pipeline.

### How can I check if Meetily is using the correct buffer size for my Bluetooth headset?

Call `debug_wasapi_device` with your headset name or start a recording to trigger `log_device_capabilities`. The diagnostic output includes calculated buffer latency and adaptive timeout ranges specific to the detected `InputDeviceKind`. Bluetooth devices show different timeout characteristics than wired USB devices, and the diagnostics box highlights potential latency mismatches that could cause audio dropouts.