HTMLMediaElement.setSinkId多音频输出冲突及远程流Web Audio适配问题咨询

First: Fixing Cross-Audio Element SinkId Interference #

Your initial issue—where setting setSinkId on a second audio element overrides the first one's output—is likely due to browser-specific handling of shared audio contexts. Here's what you can do:

• Update adapter.js first: Yes, upgrading to the latest version of adapter.js is a good first step. It patches inconsistencies across browsers for WebRTC and media APIs, including edge cases with setSinkId where multiple media elements might inadvertently share output settings if not properly isolated.
• Isolate audio contexts for each element: If updating adapter.js doesn't resolve the issue, using the Web Audio API to create a dedicated context for each audio element ensures their output devices stay independent. This is the more reliable long-term fix, as it explicitly separates each audio stream's processing pipeline.

Second: Fixing No Audio with Remote Streams in Web Audio API #

Your remote stream code isn't working likely due to one or more common autoplay policy or stream initialization pitfalls. Let's walk through the fixes:

Key Issues in Your Current Code #

• AudioContext suspension: Modern browsers require audio contexts to be activated via a user gesture (like a click) due to autoplay policies. If your context is in a suspended state, no audio will play.
• Unused stream clone: You cloned the stream but didn't use it—while cloning isn't always mandatory, working with a dedicated clone avoids interfering with the original stream's tracks.
• Missing error handling: You're not catching errors from setSinkId or audio playback, which makes debugging hard.

Corrected Code Example #

// Wrap this in a user-triggered function (e.g., a button click handler)
async function setupRemoteAudio(stream, audioElement, targetDeviceId) {
  try {
    // Initialize or resume AudioContext (critical for autoplay compliance)
    const audioCtx = new (window.AudioContext || window.webkitAudioContext)();
    if (audioCtx.state === 'suspended') {
      await audioCtx.resume();
    }

    // Clone the remote stream to avoid modifying the original track
    const clonedStream = stream.clone();
    const audioTrack = clonedStream.getAudioTracks()[0];
    
    // Validate the audio track is active
    if (!audioTrack || !audioTrack.enabled) {
      throw new Error("Remote stream has no active audio track");
    }

    // Build the Web Audio processing chain
    const sourceNode = audioCtx.createMediaStreamSource(clonedStream);
    const destinationNode = audioCtx.createMediaStreamDestination();
    sourceNode.connect(destinationNode);

    // Attach processed stream to audio element and start playback
    audioElement.srcObject = destinationNode.stream;
    await audioElement.play();

    // Set the target output device
    await audioElement.setSinkId(targetDeviceId);
    console.log(`Successfully switched output to device: ${targetDeviceId}`);
  } catch (error) {
    console.error("Failed to set up remote audio:", error);
  }
}

Additional Checks #

• Verify remote stream health: Use console.log(stream.getAudioTracks()) to confirm the remote stream has an active audio track with readyState set to live.
• Enforce user gesture: Make sure the code runs in response to a user action (e.g., a button click). Browsers block audio context initialization and playback without this trigger.
• Check browser support: Ensure the target browser supports setSinkId (most modern browsers do, but double-check for legacy versions).

Final Notes #

If you still run into issues, use your browser's dev tools (Console and Media tabs) to inspect error messages—they'll often point to track state problems, context suspension, or device access permissions.

内容的提问来源于stack exchange，提问作者DustInTheSilence