IKANDY Smart Auto:
Per-Process Audio Dominance Detection
with Metadata Backend Arbitration

Abstract

This document describes a method implemented in IKANDY — a music visualizer application — for detecting which audio-producing process on a Windows host is the dominant source and switching the application's metadata-retrieval backend to an appropriate provider for that process, with hysteresis to prevent rapid switching. This method is referred to internally as Smart Auto.

Background & Problem Statement

Music visualizer applications that display track metadata (title, artist, album art) face a fundamental challenge: a user's listening environment is rarely uniform. A user may listen via Spotify, MusicBee, VLC, foobar2000, or a browser. Each source exposes metadata through a different mechanism:

* MusicBee support through MBXHub was added to current builds after the original May 2026 disclosure. It is shown for current-product accuracy and is not presented as part of the original dated implementation.

The approaches reviewed, including SMTC, last.fm scrobbling, and unified Now Playing widgets, generally read from a single source or poll sources without using per-process audio dominance as the routing signal. This description is limited to the sources reviewed.

Method Overview

Smart Auto operates as follows:

Step 1 — Per-Process Audio Enumeration

A native Node.js addon (compiled via node-addon-api) calls the Windows ApplicationLoopback API family via WASAPI (IAudioSessionManager2, IAudioSessionEnumerator) to enumerate all active audio sessions. For each session, it retrieves the owning process ID and current audio level (peak meter value). This list is polled on an interval of approximately 1 second.

Step 2 — Dominance Detection

Sessions are filtered against an audio threshold (e.g., peak > 0.01) to exclude silent or idle processes. The producing process with the highest sustained peak level is identified as the dominant source. Process name is resolved from PID using QueryFullProcessImageName.

// Pseudocode — dominance detection
function getDominantSource(sessions, threshold = 0.01) {
  const active = sessions.filter(s => s.peak > threshold);
  return active.sort((a, b) => b.peak - a.peak)[0] ?? null;
}

Step 3 — Metadata Backend Mapping

The dominant process name is matched against a priority map of known producing applications:

* Current-build integration added after the original May 2026 disclosure; see the note above.

If the selected backend's prerequisite is not configured (e.g., VLC HTTP API is disabled), the system falls back to SMTC automatically and surfaces a non-blocking UI hint.

Step 4 — Hysteresis (Anti-Thrash)

A new dominant source must sustain dominance for a minimum dwell period (approximately 3 seconds) before a backend switch is committed. This prevents rapid toggling when two apps produce audio simultaneously (e.g., a notification sound during VLC playback).

// Pseudocode — hysteresis guard
let candidate = null;
let candidateSince = 0;
const DWELL_MS = 3000;

function evaluateSwitch(dominant, now) {
  if (dominant?.pid !== candidate?.pid) {
    candidate = dominant;
    candidateSince = now;
  }
  if (now - candidateSince >= DWELL_MS) {
    commitBackendSwitch(candidate);
  }
}

Step 5 — Silent Switch + UI Indicator

Backend switches are performed without interrupting playback or visualization. A transient UI indicator briefly surfaces to inform the user (e.g., "Now following: VLC"), then auto-dismisses. The user does not need to manually select a source.

Technical Characteristics

The method combines these elements:

1 Per-process audio session enumeration via WASAPI
2 Peak-level dominance detection with configurable threshold
3 Priority-mapped metadata backend selection per process identity
4 Hysteresis guard preventing thrash on transient audio events
5 Silent backend switch with non-blocking user feedback

Implementation Context

Smart Auto is implemented in IKANDY, an Electron 30-based music visualizer running on Windows. The native audio session enumeration layer is built with node-addon-api and compiled against the Electron runtime. The metadata backend layer communicates via IPC between the Electron main process and renderer. The visualizer renders via Butterchurn WebGL (MilkDrop-compatible).

This technical disclosure was published at ikandy.app on its effective date.

Prior Art Search Summary

A limited search of npm, GitHub, and general web sources conducted in May 2026 did not identify a publicly available implementation combining per-process audio-dominance detection with metadata-backend arbitration in the sources reviewed. This is a research note, not a comprehensive patent search or legal conclusion.