Voice Laravel Package

Product Decisions This Supports

• Language/runtime strategy for Discord voice. The real decision this package forces is not "which library" but "is PHP the right runtime for our Discord voice surface?" If voice is a core feature, adopting this is a commitment to ReactPHP's event loop, long-running workers, and native C dependencies inside a PHP codebase.
• Buy vs. build for the voice gateway. The alternative to this package is not a competitor package; it is implementing Discord's voice gateway, Opus framing, and the mandatory DAVE (MLS-based E2EE) protocol yourself. That is months of specialist crypto and real-time audio work. This package collapses that to an integration task — treat it as build-vs-buy with one viable buy option.
• Feature scope for the voice use case. The README's surface area maps directly to product bets: playFile() for music/TTS/announcement bots, record() with RecordingFormat::PCM for custom pipelines, WAV for turnkey per-user files, OGG for storage-efficient archival. Recording per-user is a meaningful unlock for transcription, meeting notes, moderation evidence, and accessibility features.
• Compliance roadmap blocker. Discord has required DAVE on all voice/video connections since March 1, 2026. Any roadmap item involving voice must account for ext-ffi + libdave being non-negotiable at runtime — with no fallback to protocol version 0. This is a hard gate, not a nice-to-have, and it should be reflected in infra planning rather than discovered in QA.
• Hosting/infrastructure decisions. Voice requires a persistent daemon (Supervisor, container, long-running worker), not request/response PHP. It effectively rules out Laravel Vapor, shared hosting, and FFI-disabled environments. That is a hosting-cost line item.
• Prioritization signal for "Discord integration" epics. If voice is a someday item, defer. If it is a differentiator, this package should be the reference implementation and the decision becomes staffing (do we have someone who genuinely understands event loops and promises?) rather than sourcing.

When to Consider This Package

Consider it when all of the following hold:

• The product is already built on DiscordPHP — this is a companion module, not standalone. Without DiscordPHP in the stack, adoption means adopting both.
• Voice is in-scope and differentiating, not a checkbox. The native-dependency tax is only justified if voice is a real feature.
• You control the deployment environment: containers or VMs where you can enable ext-ffi, vendor libdave (the bundled setup-libdave.sh handles Linux/macOS/Windows on x64 and ARM64), and install ffmpeg / libsodium.
• You have (or will hire) engineers comfortable with event loops and promises. The README is unusually blunt about this: without that knowledge "you will only suffer." Believe it.
• You can tolerate a young package in a small ecosystem. Low stars and zero dependents are partly an artifact of it being split out of the much larger DiscordPHP project — but it still means few external users have stress-tested it in production, and the release history shows small-team and bot-assisted contributions.
• Documentation quality matters to your team: this is a genuine strength. Mermaid architecture guides for DAVE, the audio pipeline, and protocol opcodes, plus a troubleshooting doc, a VoiceException marker interface for unified error handling, and CI running PHPStan, mutation testing, and coverage — that is a better engineering hygiene story than most 3-star repositories.

Look elsewhere when:

• You are free to choose the language. Node.js (@discordjs/voice), Python, or Go have orders of magnitude more production voice usage, tutorials, and community answers. Choosing PHP for a greenfield voice product is a decision that needs a strong reason.
• You need serverless, shared hosting, or FFI-restricted environments. This is architecturally incompatible.
• You need enterprise support, SLAs, or a vendor to escalate to. MIT-licensed, small-maintainer, community-supported.
• You need video, not just voice. Despite the DAVE name covering audio/video, the documented surface is voice playback and recording.
• You need multi-guild high-scale fanout with strict uptime. No load-testing evidence, no published production references, no fallbacks.
• Video/voice is a peripheral nice-to-have. The dependency surface is too heavy for a low-value feature.

How to Pitch It (Stakeholders)

To executives: This is the only maintained path to Discord voice channels in PHP, and it handles the hard part — the newly mandatory DAVE end-to-end encryption protocol — so we don't build cryptography and real-time audio from scratch. That is a substantial avoided engineering cost and a compliance box we cannot skip. The trade-off is real: it adds native runtime dependencies, constrains where we can host, and comes from a small maintainer community with limited production track record. Recommendation: adopt it if voice is a genuine differentiator and we already run DiscordPHP; otherwise, either defer the voice roadmap or treat the language choice as the decision to revisit.

To engineering: It's an async, event-loop library — not a Laravel-style package with service providers or facades. Plan for a long-running worker process, ext-ffi + a vendored libdave built via setup-libdave.sh, ffmpeg and libsodium in the image, and PHP 8.3+. Pin versions aggressively; the package moves in small patch releases aligned to DiscordPHP v8. Wrap all voice calls in a single VoiceException handler, and add monitoring around the LibDaveNotFoundException path — that failure mode is environmental, not logical, and it will bite us in deploy, not in tests. Budget real onboarding time for promises and the event loop before anyone writes voice code.