/**
 * AudioRenderer - Web Audio API based audio playback with precise clock synchronization
 * Uses AudioContext as the master clock for A/V sync (60Hz smooth playback)
 */
import type { PCMFrame } from "../decode/SoftwareAudioDecoder";
export declare class AudioRenderer {
    private audioContext;
    private inputNode;
    /** A tap for drawing the sound, not for hearing it — see getLevels. Built
     *  only when something asks, and hung off the gain node in parallel, so it
     *  never sits between the audio and the speakers. */
    private _analyser;
    private _analyserBins;
    private gainNode;
    private compressorNode;
    private scheduledTime;
    private isPlaying;
    private volume;
    private _playbackRate;
    private activeSources;
    /**
     * What each live source was made from, and when it is due.
     *
     * A scheduled source is a finished thing — post-stretch PCM with a start time
     * the audio thread already owns — and there is no reading back out of it. A
     * rate change needs to do exactly that: everything scheduled ahead of the
     * playhead is at the old rate and has to go, and up to SCHEDULE_LOOKAHEAD
     * seconds of media goes with it unless the buffer it was made from can be put
     * back. Keyed weakly so a source that has played out is collectable with its
     * entry.
     */
    private sourceOrigin;
    private _muted;
    private droppedWhileSuspended;
    private firstBufferScheduledAt;
    /**
     * The context time this RUN of sound starts at — the moment the picture has
     * to wait out before the first of it reaches the speakers. See
     * secondsUntilAudible().
     *
     * Not the same thing as firstBufferScheduledAt, which is the anchor the
     * media clock's arithmetic hangs off and is RE-BASED whenever that
     * arithmetic needs it to be — most importantly by a speed change, which
     * moves it to "now" so the old rate's elapsed time is not read at the new
     * one. Nothing about the sound restarts there; it is playing, and has been.
     * Reading that re-based anchor as a run start answers "how long until it is
     * audible" with the device's whole output latency, which on Bluetooth is a
     * quarter of a second of picture parked at every speed change.
     */
    private soundRunStartedAt;
    private firstBufferMediaTime;
    private hasFirstBuffer;
    private _lastUnderrunAt;
    private _ducked;
    /** Output held silent across the unmute re-read — see silenceForResync. */
    private _resyncSilenced;
    private static readonly DUCK_FADE_OUT;
    private static readonly DUCK_FADE_IN;
    private static readonly DUCK_CLEAR_MS;
    /** How often the duck re-asks whether it can lift — see duckForUnderrun. */
    private static readonly DUCK_POLL_MS;
    private _duckReleaseTimer;
    private _suppressDuckUntil;
    private currentMediaTime;
    private maxScheduledMediaTime;
    /**
     * The sound is over, and no more of it is coming.
     *
     * getAudioClock() clamps to maxScheduledMediaTime so a runaway clock cannot
     * outrun what has been scheduled. That is right while more audio is on its
     * way and wrong once there is none: an audio track SHORTER than the picture
     * leaves the clock parked at the last sample for good, and everything that
     * follows it — the master clock and the renderer's own presentation timing
     * both read this — stops with it. Measured on a 4K AV1 MKV whose Opus track
     * ends at 193.4s against a picture running to 243.8s: playback stopped dead
     * at 3:13 with fifty seconds of video left.
     *
     * Once the player says the stream has ended AND the head has reached it,
     * report no clock at all. Both readers already treat a negative time as
     * "time this yourself", which is exactly right: there is no sound left to
     * sync to, and the picture should play out on its own.
     */
    private _streamEnded;
    /**
     * A media-time origin that takes effect at a CONTEXT time still in the
     * future — how a gapless loop turns the corner.
     *
     * The audio clock is `firstBufferMediaTime + elapsed-since-the-anchor`, so
     * moving the origin back to zero for the next pass cannot be done when that
     * pass is SCHEDULED: its samples are queued a cushion ahead of the ones
     * being heard, and re-anchoring then would drop the clock to zero while the
     * end of the previous pass is still coming out of the speakers.
     *
     * So the new origin is armed with the context time its first sample begins
     * at, and getAudioClock()/getCurrentTime() adopt it once the output has
     * actually reached that point. Before the seam they read the old pass, after
     * it the new one, and the samples themselves were never interrupted.
     */
    private _pendingAnchor;
    /**
     * A loop pass the player has started reading, whose first buffer has not
     * arrived yet.
     *
     * The seam used to be armed at `scheduledTime` the moment the pass began.
     * That is only where the old pass ends when nothing of it is still waiting —
     * and buffers DO wait: they sit in `_pending` as data until they come within
     * the lookahead, so on a file with a soundtrack a second of the old pass was
     * still to be scheduled behind that point, and the clock wrapped to zero a
     * second before the sound did.
     *
     * So the seam is found in the audio itself. The first buffer whose timestamp
     * jumps back is where the new pass begins; it is marked on the way in, and
     * the anchor is armed with the context time it is actually started at.
     */
    private _loopArm;
    /**
     * The furthest media time scheduled for the NEXT pass while the old one is
     * still being heard. Kept apart because the clock clamps to
     * maxScheduledMediaTime, and letting the new pass's small numbers in early
     * would pin the old pass's clock at them.
     */
    private _nextPassMaxMediaTime;
    /** Called by the player when the demuxer has no more audio to give. */
    endOfStream(): void;
    /** Has the sound already been let go for this run? */
    isStreamEnded(): boolean;
    /** Fresh audio is coming (a seek, a new source): the sound is not over. */
    clearEndOfStream(): void;
    private lastDecodeTime;
    private scheduledCount;
    private isRebufferingForRateChange;
    private preservePitch;
    private signalsmith;
    private signalsmithLoading;
    private signalsmithSampleRate;
    /** Pending background build of the stretcher — see warmStretcherSoon(). */
    private stretcherWarmTimer;
    private _decodedSampleRate;
    private _stableAudio;
    /** The state the GRAPH is actually wired for, so a repeated request for the
     *  state we are already in doesn't tear the chain apart to rebuild it
     *  identically — see setStableAudio. */
    private _wiredStableAudio;
    private _sinkId;
    private static readonly GAIN_RAMP_TIME;
    /** …and how slowly a level nobody asked for is walked back, which wants to
     *  be gentle rather than quick: it is a correction to a mistake, not a
     *  response to the viewer, and it must not read as a jump. */
    private static readonly GAIN_RESTORE_TIME;
    private static readonly FADE_OUT_TIME;
    private contextStateHandler;
    /**
     * Latches sharedContextActivated the moment the context reaches "running".
     * Separate from contextStateHandler on purpose: that one is stable audio's
     * recovery monitor and is only wired when stable audio is on, while "audio
     * got unlocked this session" is a fact every path needs — see init().
     */
    private contextActivationHandler;
    private recoveryAttempts;
    private static readonly MAX_RECOVERY_ATTEMPTS;
    private starvationStartTime;
    private isStarved;
    private static readonly STARVATION_THRESHOLD;
    private keepaliveEl;
    private keepaliveUrl;
    constructor();
    /**
     * Lazily create a near-silent looping <audio> element used to keep the
     * OS audio session alive while AudioContext is suspended. Uses a tiny
     * generated WAV blob so resume from pause stays seamless and Bluetooth
     * speakers/headphones don't drop the connection.
     */
    private ensureKeepalive;
    private startKeepalive;
    private stopKeepalive;
    /**
     * Initialize audio context
     */
    init(): Promise<boolean>;
    /**
     * Route audio to a specific output device via AudioContext.setSinkId
     * (Chromium 110+). `deviceId` "" → the system default. Stored so it
     * survives the AudioContext re-creation in init(). Returns false when
     * unsupported or the device can't be selected (e.g. unplugged).
     */
    setSinkId(deviceId: string): Promise<boolean>;
    /** Current output device id ("" = system default). */
    getSinkId(): string;
    /** True when the running engine can route output to a chosen device. */
    static isSinkSelectionSupported(): boolean;
    private applySinkId;
    /**
     * Configure audio format (logs only, format is taken from AudioData)
     */
    /** Decoded source sample rate, from configure(). 0 until the decoder reports. */
    private _sourceSampleRate;
    /**
     * Until when a ramp we asked for owns the master gain (performance.now()).
     *
     * The drift check must not police a gain that is deliberately on its way
     * somewhere: a seek fades to zero and back, and a check landing inside that
     * window sees "far from target", cancels the fade and hauls the level up
     * mid-flight — which is the pumping a seek started doing the moment the
     * check was added.
     */
    private _gainHoldUntil;
    /** Consecutive health ticks that have seen the gain wrong. Restoring takes
     *  two, so nothing transient is ever touched. */
    private _gainDriftStrikes;
    /** Channels in the last buffer actually scheduled. A track that starts
     *  arriving as mono, or downmixed, is one of the ways "it went quiet" is
     *  true — see the health line. */
    private _lastChannels;
    configure(sampleRate: number, channels: number): void;
    /**
     * Maximum number of output channels the user's audio device + browser
     * combination supports. 2 (stereo) for typical laptop/phone setups,
     * 6 for a 5.1 receiver, 8 for 7.1. Returns 2 when the AudioContext
     * hasn't been created yet.
     */
    getMaxChannelCount(): number;
    /**
     * Ask the AudioContext destination to accept `n` discrete channels
     * instead of Web Audio's default 2. `channelCountMode: "explicit"` +
     * `channelInterpretation: "discrete"` together suppress the
     * automatic speaker-layout downmix the API would otherwise apply,
     * so a 7.1 AudioBuffer reaches the device with all 8 planes intact.
     * Caller is responsible for ensuring the OS / hardware actually has
     * that many output channels — read getMaxChannelCount() first and
     * clamp accordingly.
     */
    setOutputChannelCount(n: number): void;
    /**
     * Render AudioData with precise timing
     */
    render(audioData: AudioData): void;
    /**
     * Render a raw PCM frame (browser-agnostic path used by the software
     * decoder). Avoids constructing a WebCodecs AudioData, which Firefox on
     * Android does not implement.
     */
    renderPCM(frame: PCMFrame): void;
    /**
     * Schedule a populated AudioBuffer through the stretcher + A/V sync
     * pipeline. Shared by render() and renderPCM().
     */
    /**
     * Decode as far ahead as the pipeline likes; keep the graph narrow anyway.
     *
     * Every scheduled buffer is a live AudioBufferSourceNode, and WebAudio pulls
     * every connected node once per render quantum whether it has started or
     * not. Committing each buffer the moment it was decoded tied the width of
     * the graph to the depth of the buffer: software audio runs a 5s lead, AAC
     * frames are 23ms, so ~215 nodes. A desktop shrugs. A phone's audio thread
     * misses its deadline, and a missed deadline is a click — measured on mobile
     * Chrome as cushion=4199ms sources=181 with the context's own outputLatency
     * wandering between 600 and 770ms, and with no underrun and no late
     * schedule: the data was there, on time, and the graph was simply too wide
     * to render.
     *
     * So the two are separated. Buffers wait here as plain data, costing
     * nothing, and become nodes only once their turn is within LOOKAHEAD. The
     * lead is unchanged — getBufferedDuration counts what is waiting — so the
     * decode headroom the deep buffer was for is still there.
     */
    private scheduleAudioBuffer;
    /**
     * Hand over every buffer whose turn has come.
     *
     * Driven both by arriving audio and by a timer, because the queue has to
     * keep draining when nothing is arriving — which is exactly what happens
     * once the player hits its buffer cap and stops feeding.
     */
    private pumpSchedule;
    private commitAudioBuffer;
    /**
     * Render raw PCM samples
     */
    renderSamples(samples: Float32Array[], sampleRate: number): void;
    /**
     * Start playback
     */
    play(): Promise<void>;
    /**
     * Kick off Signalsmith stretcher construction. Single-flight; idempotent.
     * The movi WASM module is shared with FFmpeg, so this is fast once the
     * player has loaded — just an instance allocation.
     */
    /**
     * Build the pitch-preserving stretcher in the background, before anyone asks
     * for a speed change.
     *
     * It used to be built when the speed actually changed, and the speed changing
     * is the worst moment to start: the build is an async WASM load, and until it
     * lands every chunk is deliberately scheduled as silence rather than as
     * pitch-shifted audio (see commitAudioBuffer). That choice is right — a
     * chipmunk blip is worse than a gap — but it means the whole load time is
     * heard as a hole, which is the second of silence on the first speed change.
     * Nothing about that load needs the speed change to have happened.
     *
     * So it is built once playback is settled, at the DECODED sample rate, which
     * is only known after some audio has come through (the stretcher is
     * fixed-rate per instance, and building at the context rate instead means
     * destroying it and rebuilding at the real rate on the first chunk — the same
     * silence, just moved). One instance per session, off the startup path.
     */
    private warmStretcherSoon;
    private maybeInitSignalsmith;
    /**
     * Pitch-preserving time stretch through Signalsmith. Returns the stretched
     * AudioBuffer, or null if the stretcher isn't ready yet (caller falls back
     * to source.playbackRate scaling, which shifts pitch but keeps audio playing).
     */
    private processStretch;
    /**
     * Warmup AudioContext (Safari fix)
     */
    private warmupContext;
    /**
     * Pause playback
     */
    pause(): void;
    /**
     * Suspend audio output for buffering without stopping data acceptance.
     * Keeps isPlaying=true so render() still accepts AudioData and buffers fill up.
     * Suppresses auto-recovery so the context stays suspended until resumeFromBuffering().
     */
    suspendForBuffering(): void;
    /**
     * Prepare for the first-play / replay audio prime: mark the renderer playing
     * so render() accepts decoded audio and the buffer fills, but hold the
     * AudioContext suspended so nothing drains until resumeFromBuffering().
     *
     * Unlike play() + suspendForBuffering(), this NEVER issues an async resume().
     * That pair raced on replay: after `ended`, pause() leaves the context
     * suspended; the prime's fire-and-forget play() then kicks off an async
     * resume(), and the immediately-following suspendForBuffering() sees the
     * context still "suspended" (resume in flight) so its state===running guard
     * skips the suspend — the late resume then wins and the context stays
     * running for the whole prime, draining the primed audio and underrunning
     * the sub-realtime software decoder into a flood of gap-fills. Priming
     * without ever resuming removes the race entirely.
     */
    primeForBuffering(): void;
    /**
     * Resume audio after buffering. Clears the intentional suspend flag.
     */
    resumeFromBuffering(): void;
    /**
     * Set volume (0-1) with smooth ramping to prevent clicks/pops
     */
    setVolume(volume: number): void;
    /**
     * Get volume
     */
    getVolume(): number;
    /**
     * Set playback rate
     */
    setPlaybackRate(rate: number): void;
    /**
     * Get playback rate
     */
    getPlaybackRate(): number;
    /**
     * Set pitch preservation mode
     */
    setPreservePitch(preserve: boolean): void;
    /**
     * Get pitch preservation mode
     */
    getPreservePitch(): boolean;
    /**
     * Check if audio is rebuffering due to playback rate change
     */
    isRebuffering(): boolean;
    /**
     * Mute with smooth fade to prevent clicks/pops
     */
    mute(): void;
    /**
     * Unmute with smooth fade to prevent clicks/pops
     */
    unmute(): Promise<void>;
    /**
     * Reset timing and stop all scheduled audio with smooth fade-out
     */
    reset(): void;
    /**
     * Get current audio context time
     */
    getCurrentTime(): number;
    /**
     * How long from now until the audio we have scheduled is actually HEARD —
     * i.e. how long getAudioClock() will keep returning firstBufferMediaTime
     * unchanged before it starts advancing. Zero once sound is playing out, and
     * on every device whose latency is small enough not to matter.
     *
     * Two separate delays stack up at the start of every playback run, and both
     * are deliberate:
     *
     *  - the first buffer is placed one output-latency ahead (`deviceLead`, see
     *    render()) so the scheduler has a window to queue the buffers behind it
     *    instead of handing a deep device a single buffer and starving it;
     *  - and what is scheduled at context time T is heard at T + outputLatency,
     *    which getAudioClock() subtracts so video syncs to what is HEARD.
     *
     * On a wired or built-in output that is ~5-25ms twice over and nobody can
     * tell. On Bluetooth it is ~305ms twice over: for the first ~600ms after a
     * seek there is no sound yet, and the audio clock is flat by construction.
     *
     * The video side has to know that, because its own clock is wall-clock based
     * and would otherwise start advancing immediately from an anchor taken off
     * that flat value — running ~600ms ahead of the sound, until the drift
     * correction notices and yanks the presentation anchor backwards, which is
     * seen as the picture freezing a moment after every seek. Bluetooth only,
     * because on anything else the number is too small to cross the threshold.
     */
    /**
     * What secondsUntilAudible() will report once the next run's first buffer is
     * scheduled — the deviceLead render() is about to apply, plus the latency it
     * will then take to be heard.
     *
     * Callers that have to decide whether to hold playback need the figure BEFORE
     * any buffer exists: right after a seek the flush has cleared hasFirstBuffer,
     * so secondsUntilAudible() honestly reports zero and would talk them out of a
     * wait that is coming regardless.
     */
    expectedStartLead(): number;
    /**
     * How long until sound is actually coming out — measured once there is a
     * buffer to measure, predicted before there is.
     *
     * The two halves answer the same question at different moments and must not
     * be mixed up: after a seek's flush there is no scheduled buffer, so the
     * measurement honestly reports zero, and a caller that acts on it starts the
     * picture with no lead at all. Past the first buffer the prediction is
     * stale — the live figure counts down to zero as the sound approaches, and
     * must be allowed to reach it, or the drift correction it gates never runs.
     */
    startLead(): number;
    secondsUntilAudible(): number;
    /**
     * Can a speed change be carried on the audio this renderer already holds?
     *
     * setPlaybackRate() does not throw the scheduled audio away any more — it
     * stops the sources that have not begun and pushes their ORIGINAL buffers
     * back onto the pending queue to be re-stretched at the new tempo and
     * rescheduled behind whatever is playing. Nothing is skipped and no hole is
     * opened, so the media from the playhead forward is still in hand and the
     * source does not have to be re-read to get it back.
     *
     * This reports whether that reclaim is actually available: the branch's own
     * preconditions (a running context past its first buffer) plus a material
     * amount of audio to reclaim. Read it BEFORE setPlaybackRate() — afterwards
     * the sources have already been taken back into the queue.
     */
    canCarryRateChange(minSeconds?: number): boolean;
    /**
     * Get the audio clock - THE MASTER TIME SOURCE FOR A/V SYNC
     * Returns accurate time based on when audio actually started playing
     * Returns -1 if audio hasn't started yet
     * Clamps to maxScheduledMediaTime when audio has ended
     */
    /**
     * Take up an armed origin once the output has actually reached it. Called
     * from both clock readers rather than on a timer: the only moment that
     * matters is the one being asked about.
     */
    private adoptPendingAnchor;
    /**
     * The next pass of a looping file starts here.
     *
     * Everything about the sound carries on untouched — the scheduler keeps
     * placing buffers at `scheduledTime`, so the first sample of the new pass
     * abuts the last sample of the old one and there is no seam to hear. What
     * changes is only the BOOKKEEPING: the media time those samples are labelled
     * with wraps back to the start of the file, and the clock has to wrap with
     * them, but not until they are heard.
     *
     * Call BEFORE the new pass is read. Its first buffer is recognised by its
     * timestamp stepping back (see _loopArm) and the seam is armed when that
     * buffer is started.
     */
    beginLoopPass(): void;
    /**
     * True from beginLoopPass until the output has reached the new pass. The
     * player turns the picture over when this goes false, so both halves of the
     * loop share one boundary.
     */
    isLoopSeamPending(): boolean;
    /** Drop an armed loop seam that is not going to happen after all. */
    cancelLoopPass(): void;
    getAudioClock(): number;
    /**
     * True when an AudioContext exists but the browser is keeping it suspended
     * despite us asking to play unmuted — i.e. autoplay-with-sound was blocked
     * because no user gesture has unlocked audio yet. resume() resolves without
     * throwing in this case (Chromium silently leaves the context suspended),
     * so callers can't detect the block from play()'s promise; they poll this
     * instead. Returns false when muted (we intentionally don't resume) or when
     * the context is genuinely running.
     */
    isBlockedSuspended(): boolean;
    /**
     * True once the shared AudioContext has run (been unlocked by a gesture) at
     * any point this session — see the module-level sharedContextActivated latch.
     * After that, a gesture-free resume() will succeed on its own, so a suspended
     * state seen right after init() is just the async resume still in flight and
     * WILL recover. Callers use this to wait it out instead of falling back to
     * muted autoplay (which would flash the "tap to unmute" pill on every
     * auto-advanced track).
     */
    wasEverActivated(): boolean;
    /** See audioStartRefused(). */
    isStartRefused(): boolean;
    /**
     * Check if audio has healthy buffers (not in underrun state)
     * Used by video renderer to decide whether to sync to audio
     */
    hasHealthyBuffer(): boolean;
    /**
     * Check if audio is actively playing
     */
    isAudioPlaying(): boolean;
    /**
     * Get filtered buffered duration (seconds ahead of current time)
     */
    /**
     * True when audio frames are being thrown away rather than scheduled: muted
     * with a context the browser won't let us start (the autoplay-blocked state,
     * before any gesture). Only then is audio genuinely absent from the pipeline
     * — a muted context that IS running still schedules everything, at gain 0,
     * and still drives the clock.
     *
     * An intentional suspend (a prime / buffering hold) is explicitly NOT this
     * state: we suspended the context ourselves precisely so decoded audio
     * accumulates against a frozen clock, and it resumes on our own call.
     */
    isDroppingAudio(): boolean;
    getBufferedDuration(): number;
    /**
     * True if we patched a hole with silence within `withinMs`. A run of these
     * means the decode pipeline has fallen behind realtime — the audio the user
     * hears is already broken, so the player surfaces its buffering state rather
     * than claiming to play. High packet-rate codecs (TrueHD/MLP/DTS) are what
     * hit this: they read far more often than AAC, so anything that adds latency
     * per read shows up here first — the same file decodes clean from a local
     * file and stutters over HTTP.
     */
    isUnderrunning(withinMs?: number): boolean;
    /**
     * Fade the input out to cover a run of underruns.
     * Rides on inputNode, never gainNode: gainNode carries the user's volume and
     * boost, and stomping it here would fight setVolume() and leave the ducked
     * level behind as the user's own setting.
     */
    /**
     * Suppress ducking for the next `ms` and release any current duck. Called by
     * the player around a background→foreground recovery, whose decoder flush +
     * re-seek briefly starves audio — a transient underrun that must not mute.
     */
    suppressDuckFor(ms: number): void;
    /** Immediately restore the input gain and clear the duck (no fade). */
    private forceUnduck;
    /**
     * Put silence across a gap in the schedule, so the seam is joined rather
     * than torn.
     *
     * WebAudio does not play "nothing" between two buffer sources — it plays
     * whatever the graph last had, then the next buffer starts abruptly. That
     * step is the click. A silent buffer laid over the gap gives the output
     * something continuous to run through, which is what the underrun path has
     * always done; these two callers are the seams that were missing it.
     *
     * Logged, because a click that leaves no trace is a bug nobody can find
     * twice: the reason mobile-only clicking survived several rounds of looking
     * is that neither of these paths said anything at all.
     */
    private fillSeam;
    /** Throttle for the once-a-second output line above. */
    private _lastHealthLogAt;
    /** Decoded audio waiting for its turn to become a node — see
     *  scheduleAudioBuffer. Plain data; costs nothing until committed. */
    private _pending;
    private _pendingDuration;
    private _pumpTimer;
    /** How far ahead of the output a buffer may be turned into a node. Wide
     *  enough that jank cannot starve the graph, narrow enough that the node
     *  count stays in the dozens rather than the hundreds. */
    private static readonly SCHEDULE_LOOKAHEAD;
    /** How often the queue drains itself while no audio is arriving. */
    private static readonly PUMP_INTERVAL_MS;
    /**
     * How long after audio starts flowing the stretcher is built.
     *
     * Long enough to stay off the opening of a video, where the decode, the fetch
     * and the first frames are already competing; far shorter than it takes
     * anyone to open the speed menu.
     */
    private static readonly STRETCHER_WARM_DELAY_MS;
    private duckForUnderrun;
    /**
     * Fade back in, but only once no underrun has landed for DUCK_CLEAR_MS.
     * Called on every scheduled buffer, so recovery needs no external signal.
     */
    /**
     * Hold the output silent WITHOUT touching the mute flag.
     *
     * Tap-to-unmute has to resume the AudioContext inside the tap — the browser
     * won't allow it a task later — but the audio that resume makes audible is
     * whatever the decoder holds, which is not where the picture is. So the
     * viewer heard a second of the wrong moment, then a seek, then the right one.
     * Resuming stays on the tap; this keeps it inaudible until the re-read lands.
     *
     * Same gain node the underrun duck uses, its own flag, and the duck can't
     * lift it — see unduckIfClean.
     */
    silenceForResync(): void;
    private stopDuckPolling;
    /** Fade back in once the re-read has landed. Safe to call unconditionally. */
    releaseResyncSilence(): void;
    private unduckIfClean;
    /**
     * Get the furthest media time (seconds) already scheduled in Web Audio.
     */
    getMaxScheduledMediaTime(): number;
    /**
     * (Re)connect the audio graph for the current stable-audio state.
     *   stable ON : sources → input → compressor → gain(makeup) → destination
     *   stable OFF: sources → input → gain(volume)  → destination
     *
     * The volume/makeup gainNode is ALWAYS the final node before destination, so
     * a >100% boost is applied *after* the limiter instead of being cancelled by
     * it. Measured: with the old gain-before-limiter order, 100%→200% yielded
     * only ~+0.6dB; with gain after the limiter it's the full ~+6dB. Because the
     * limiter has already tamed peaks to ≈-15dBFS, a 2× makeup still lands well
     * under 0dBFS, so it does not re-introduce clipping.
     */
    private wireGraph;
    /**
     * The sound as levels, for drawing.
     *
     * `bars` bands from the spectrum, each 0..1, weighted so the low end does
     * not swamp everything (music has most of its energy there and a plain
     * average leaves every bar but the first two flat). Returns null when there
     * is nothing to read — no context, no sound running — and the caller can
     * draw its resting state.
     */
    getLevels(bars: number): Float32Array | null;
    /**
     * Enable/disable stable audio mode (dynamic range compression / loudness normalization)
     */
    setStableAudio(enabled: boolean): void;
    /**
     * Get stable audio mode state
     */
    getStableAudio(): boolean;
    /**
     * Smoothly ramp gain to target value to prevent clicks/pops
     */
    /**
     * Convert a linear slider value (0-1) to a perceptual gain value.
     *
     * Human loudness perception is logarithmic, so a linear gain feels like
     * "almost everything happens in the first 10%" and the top 90% feels flat.
     * We map the slider through an exponential (dB-based) curve so that equal
     * slider movement produces a roughly equal perceived loudness change across
     * the whole range. 0 -> silence, 1 -> unity gain.
     */
    private perceptualGain;
    /**
     * Put the master gain back if it has been wrong for long enough that
     * nothing legitimate can explain it.
     *
     * While playing, unmuted and unducked, the gain IS perceptualGain(volume).
     * It was found parked at 0.001 against a target of 0.436 and still there
     * twelve seconds later — the "it went quiet after a seek" report — with no
     * way back for the viewer except reloading. The cause of that is still
     * open; this does not need it.
     *
     * What it does need is to never fight. Every deliberate move of this param
     * — a seek's fade down and back, a volume change, a mute — is short, and
     * while one is in flight the level is MEANT to be somewhere other than the
     * target. Correcting it there is the fault this net was supposed to prevent,
     * turned upside down: the first version of it hauled the gain up mid-fade
     * and made a seek pump audibly. So it stands down for the length of any ramp
     * we asked for, forgets what it saw while standing down, waits for three
     * consecutive seconds of a wrong level, and then moves slowly enough that
     * being wrong about it is inaudible.
     */
    private policeMasterGain;
    /**
     * Take the sound down a slope and leave it there.
     *
     * For a player that is going away — the desktop window closing, a page
     * unloading — where the alternative is the sound stopping dead on whatever
     * sample it was on. That cliff is what makes closing an app feel like
     * pulling a plug out; a fifth of a second of slope is all it takes to feel
     * like a door closing instead.
     *
     * Nothing raises it again on the way down: the drift net restores a gain
     * that is wrong, and this one is wrong on purpose. There is no fade back —
     * whatever asked for this is not expecting to play again.
     */
    fadeOut(durationMs?: number): void;
    /** Set once fadeOut has run: the level is on its way to zero and stays there. */
    private _fadingOut;
    private rampGain;
    /**
     * Monitor AudioContext state changes and auto-recover from interruptions
     * Handles cases like: phone calls, other audio sources, OS-level interruptions
     */
    private setupContextStateMonitoring;
    /**
     * Attempt to recover AudioContext from interrupted/suspended state
     */
    private attemptContextRecovery;
    /**
     * Check if audio is in starvation state (no new data for extended period)
     * Used by Clock/MoviPlayer to decide whether audio clock is reliable
     */
    isAudioStarved(): boolean;
    /**
     * Get duration of current starvation period in ms (0 if not starved)
     */
    getStarvationDuration(): number;
    /**
     * Destroy renderer
     */
    destroy(): Promise<void>;
}
//# sourceMappingURL=AudioRenderer.d.ts.map