Bump decibri from 3.0.0 to 3.3.2

[dependabot]

Bumps decibri from 3.0.0 to 3.3.2.

Release notes

Sourced from decibri's releases.

v3.3.2

What's Changed

• Patch 3.3.2: build.rs hardening + cargo publish --dry-run coverage by @​rossarmstrong in decibri/decibri#22

Full Changelog: decibri/decibri@v3.3.1...v3.3.2

v3.3.0

What's Changed

Groundwork release for upcoming P3 Python bindings. Adds a stable-ID form for audio device selection (DeviceSelector::Id), fixes a long-standing direction bug in DecibriError::DeviceNotFound when resolving output devices, exposes both in the Node binding, and extends the reference documentation with a Cargo feature flag guide plus additional crate-level rustdoc. No Node.js or browser API break. Direct Rust crate consumers pattern-matching on DeviceSelector or struct-literal-constructing DeviceInfo / OutputDeviceInfo need to update for the new #[non_exhaustive] attributes (see Migration notes below).

Changed

• DeviceSelector, DeviceInfo, and OutputDeviceInfo are now #[non_exhaustive]. External Rust consumers pattern-matching on DeviceSelector must add a _ => catch-all arm. Consumers constructing DeviceInfo or OutputDeviceInfo via struct literal from outside the crate must switch to reading fields off instances returned by enumerate_input_devices / enumerate_output_devices. Field names and display strings are unchanged. This future-proofs the API, subsequent variant or field additions are source-compatible for consumers who include the catch-all.

Added

• DeviceSelector::Id(String) for selecting audio devices by stable per-host identifier (WASAPI endpoint ID on Windows, CoreAudio UID on macOS, ALSA pcm_id on Linux). Unlike DeviceSelector::Name (case-insensitive substring) and DeviceSelector::Index (positional), Id survives across enumerations, display names can shift when other devices are plugged in but per-host IDs do not.

• id: String field on DeviceInfo and OutputDeviceInfo, populated from cpal::DeviceId's Display output. Empty string if cpal cannot produce a stable ID for a given device (rare, some host backends cannot assign IDs to every enumerated device). Obtain the ID from these fields and pass to DeviceSelector::Id.

• DecibriError::OutputDeviceNotFound(String) variant, the output-device equivalent of DeviceNotFound. See Fixed below for the motivating bug.

• Node binding accepts device: { id: string } as a third form alongside device: <number> (index) and device: <string> (name substring). The JS wrapper passes it through to Rust unchanged, Rust resolves via cpal's DeviceId.

• DeviceInfoJs.id and OutputDeviceInfoJs.id fields on the Node binding types, mirroring the Rust DeviceInfo.id / OutputDeviceInfo.id additions. Visible in the auto-regenerated npm/decibri/index.d.ts and in the hand-authored npm/decibri/src/decibri.d.ts.

• npm/decibri/src/errors.js helper that re-wraps plain Error instances thrown from the native boundary as TypeError or RangeError, matching the JS wrapper's existing validation error classes. Brought in by decibri.js and decibri-output.js constructors to align Rust-originated errors with the JS wrapper's error class contract. Triggered only by code paths that reach Rust's to_napi_error (currently only device: { id: ... } selection). All other validation paths continue to throw from the JS wrapper directly with no behavior change.

• docs/features.md, comprehensive Cargo feature reference covering ORT distribution mode tradeoffs, execution-provider features, binding-author guidance, and feature compatibility constraints. Targeted at Rust crate consumers and FFI binding authors, lib.rs rustdoc now links to it for deep-dive reference.

Fixed

• DecibriError::DeviceNotFound display string hardcoded "No audio input device found matching..." regardless of whether the lookup was against input or output devices. Direct Rust consumers and the new device: { id: ... } Node path now receive the correct direction via DecibriError::OutputDeviceNotFound for output-device misses. No change visible through the Node binding for existing name- and index-based lookups, those are intercepted by the JS wrapper and always threw direction-correct messages from JS before reaching Rust.

Internal

• DeviceDirection trait gains a not_found_error(String) -> DecibriError method so resolve_device_generic Name and Id arms produce direction-correct errors via the Input and Output implementations.

• Unit tests for Arc<Mutex<CaptureStream>> confirming the wrapping is Send + Sync (compile-time assertion) and serializes concurrent access across two threads (runtime test with Barrier). Documents the wrapping strategy the P3 Python binding will apply to share !Sync capture streams across Python threads.

• Crate-level rustdoc additions in lib.rs, including a section on ORT error construction FFI side effects (the ortsys![CreateStatus] dylib-load trigger that motivates the OrtPathInvalid split from OrtLoadFailed) and a section on fork safety (guidance for Python multiprocessing consumers to use spawn start method).

• lib.rs rustdoc "Feature flags" section cross-references docs/features.md for deeper reference.

• Em dash cleanup across multiple code locations per CLAUDE.md rules.

• CLAUDE.md corrections updating validation commands and replacing stale version references.

... (truncated)

Changelog

Sourced from decibri's changelog.

[3.3.2] - 2026-04-26

Changed

• crates/decibri/build.rs rewrite to use Cargo.toml as primary source. The previous build script (introduced in 3.3.1 to source the cpal version from a single point of truth) read the workspace Cargo.lock via a path traversal that worked in workspace builds but panicked in cargo publish verify because the published tarball is flat (decibri-X.Y.Z/Cargo.toml and decibri-X.Y.Z/Cargo.lock are siblings, not in workspace structure). The traversal landed at target/Cargo.lock (nonexistent) and aborted the build. 3.3.1's crates.io publish failed on this defect; 3.3.1 shipped to npm but not to crates.io. 3.3.2 fixes the build.rs to read CARGO_MANIFEST_DIR / Cargo.toml directly, with belt-and-suspenders fallbacks: env-var override (DECIBRI_CPAL_VERSION), workspace Cargo.toml fallback for { workspace = true } inherit form, hardcoded "0.17" constant fallback (with cargo:warning=) for unforeseen build contexts. Cargo.toml is unambiguously present in every build context because cargo guarantees CARGO_MANIFEST_DIR always points at the manifest's directory.
• No functional change to user-visible API or error messages. All 5 message refinements from 3.3.1 (SampleRateOutOfRange, FramesPerBufferOutOfRange, AlreadyRunning, OrtInitFailed, OrtLoadFailed / OrtPathInvalid, PermissionDenied) are preserved unchanged.
• decibri::CPAL_VERSION byte-identity preserved across all four cargo-emitted dep forms. Verified 2026-04-26 by walking through find_cpal_in_dependencies + truncate_to_major_minor against on-disk Cargo.toml content: Form 1 (cpal = "0.17" workspace.dependencies) -> "0.17"; Form 2 (cpal = { version = "0.17", optional = true } hypothetical inline-table) -> "0.17"; Form 3 (cpal = { workspace = true, optional = true } source crate) -> workspace fallback -> "0.17"; Form 4 ([dependencies.cpal] version = "0.17" published normalized) -> "0.17". All four forms produce identical output to the v3.3.1 build.rs's Cargo.lock-resolved truncation because the workspace pin is at major.minor granularity already (cpal = "0.17" in [workspace.dependencies]).
• release-dryrun.yml extended to exercise cargo publish -p decibri --dry-run. The previous dryrun workflow ran the npm-side build matrix and verify_pack packaging gate but had no crates.io publish path coverage. The new step catches build.rs failures and any other publish-time issues that affect the Rust crate publish but not the npm packaging. Closes the procedural gap that allowed 3.3.1's defect to ship through CI green.

Migration notes

• Direct Rust crate consumers of decibri: 3.3.1 was never published to crates.io. crates.io's decibri version history is 3.3.0 -> 3.3.2; 3.3.1 is skipped entirely on this registry. npm consumers see the standard 3.3.0 -> 3.3.1 -> 3.3.2 progression (3.3.1 shipped successfully on npm; only the cargo publish step in release.yml failed). The asymmetry is documented here for archaeological clarity.
• All 3.3.1 message refinements (per [3.3.1] entry above) are preserved in 3.3.2. Consumer-side migration from 3.3.0 to 3.3.2 is the same as 3.3.0 to 3.3.1 from the user-visible API perspective.
• No npm migration required for 3.3.1 -> 3.3.2. 3.3.2 publishes a new wheel set with the same user-visible behavior; bump-and-rebuild is sufficient.

[3.3.1] - 2026-04-25

Changed

• Audience-neutral error message pass. Five DecibriError Display strings refined to remove cross-binding and platform-specific awkwardness. No variant identity, layout, or count change; no API-surface change. Strict patch release.
  • SampleRateOutOfRange: "sampleRate must be between 1000 and 384000" -> "sample rate must be between 1000 and 384000". The previous camelCase form was Node-API-targeting and matched no other field-name convention in the rest of the Rust crate (snake_case fields throughout, natural-language rustdoc voice).
  • FramesPerBufferOutOfRange: "framesPerBuffer must be between 64 and 65536" -> "frames per buffer must be between 64 and 65536". Same rationale.
  • AlreadyRunning: "Decibri is already running. Call stop() first." -> "audio stream is already running. Call stop() first.". Hardcoded class name was misleading when raised from DecibriOutput; "audio stream" matches the existing error.rs vocabulary ("capture stream", "output stream", "audio stream").
  • OrtInitFailed: "Either pass ort_library_path in VadConfig, ..." -> "Either pass ort_library_path when constructing the VAD, ...". Drops Rust-internal VadConfig type reference; phrasing now correct for Node, Python, and direct-Rust crate consumers alike.
  • OrtLoadFailed and OrtPathInvalid: "the bundled ORT may be missing from your platform package" -> "the bundled ONNX Runtime may be missing from your installation". Drops npm-internal "platform package" phrasing; "installation" works for npm platform packages, Python wheels, and direct-Rust crate use.
  • PermissionDenied: macOS-specific "Enable in System Preferences > Security & Privacy." replaced with attribute-gated per-platform guidance. macOS hint extended to specifically reference > Microphone. Windows hint references the modern Settings > Privacy & Security > Microphone UX. Linux hint references PulseAudio / PipeWire (the user-facing audio control layer over cpal's ALSA backend).
• Lockstep updates to bindings/node/src/lib.rs (one duplicate AlreadyRunning message in the napi start() pre-running check), npm/decibri/src/errors.js (two prefix-match strings in the typed-error shim), npm/decibri/src/decibri.js (two thrown messages in client-side validation; line 101's channels message is already natural-language and unchanged), npm/decibri/src/decibri-output.js (one thrown message), npm/decibri/src/browser/decibri-browser.js (two thrown messages in browser-side validation), tests/test-ci.js, tests/test-api.js, tests/test-output.js (15 hardcoded message-substring assertions).

Migration notes

Error message wording on shipped DecibriError variants has historically been stable across the 3.x line. 3.3.1 explicitly refines five messages to remove audience-leak issues identified during P3 Phase 2 planning: Node-API-targeted camelCase parameter names, class-name hardcoding in AlreadyRunning, a Rust-internal type reference (VadConfig) in OrtInitFailed, npm-internal phrasing ("platform package") in OrtLoadFailed / OrtPathInvalid, and macOS-only platform guidance in PermissionDenied. Future releases re-establish wording stability; 3.3.1 is the consolidation point.

• Direct Rust crate consumers asserting on DecibriError::Display strings should update assertions for the five refined messages. Type-level matching on DecibriError variants is unaffected; only string-text assertions need updating.
• Node consumers using e.message.includes(prefix) or e.message.startsWith(prefix) patterns should update for sampleRate -> sample rate, framesPerBuffer -> frames per buffer, and the AlreadyRunning message text. Type-level matching on RangeError / TypeError is unaffected.
• Python consumers: P3 Phase 2's first wheel (still pre-release) consumes decibri@3.3.1, so the messages it sees are the corrected forms from day one. No migration needed (Phase 1 wheel was scaffold-only with no error message surface).

[3.3.0] - 2026-04-23

Groundwork release for upcoming P3 Python bindings. Adds a stable-ID form for audio device selection (DeviceSelector::Id), fixes a long-standing direction bug in DecibriError::DeviceNotFound when resolving output devices, exposes both in the Node binding, and extends the reference documentation with a Cargo feature flag guide plus additional crate-level rustdoc. No Node.js or browser API break. Direct Rust crate consumers pattern-matching on DeviceSelector or struct-literal-constructing DeviceInfo / OutputDeviceInfo need to update for the new #[non_exhaustive] attributes (see Migration notes below).

Changed

... (truncated)

Commits

• f1b3537 Merge pull request #22 from decibri/development
• 823d0e7 chore(release): bump to 3.3.2
• a63cee5 ci: add cargo-publish-dryrun job to release-dryrun.yml
• 8336c98 fix(build): switch build.rs to Cargo.toml as primary source for cpal version
• f18c2a1 Merge pull request #21 from decibri/development
• 47d0d1b chore(release): bump to 3.3.1
• 8a3ff7a fix(error): update browser test assertions for refined messages
• 9d84b09 fix(error): audience-neutralize five DecibriError messages
• b3aaeef Merge pull request #20 from decibri/development
• ef3ece9 scaffold(deps): register uv ecosystem + uniform target-branch policy
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)