- From: Ivy Fae via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Aug 2020 07:32:06 +0000
- To: public-webrtc-logs@w3.org
> "that it best solves". I think those are compelling use cases for web speech to solve cleanly. I'm not sure what the etiquette is for commenting on closed issues, so let me know if this would be better posted elsewhere, but I have a use case that has not been considered and is completely unrelated to web speech: music production, video editing, and other similar work. Many music producers record or stream the music production process for educational purposes, or for live performances. This is even more common now that so many musicians aren't able to perform live due to COVID. In these cases, there doesn't appear to be any viable substitute for capturing the main output of an external audio interface/sound card. > Why does this need special treatment? > Wouldn't a sound card just be another input device? If you want the sound card **input**, yes. But in use cases related to music production or video editing, if I want to stream or record, the sound card's main **output** is going to be the only useful audio to capture. None of the other sources will have all parts of the master mix. The DAW needs to use the resources the sound card provides directly instead of just passing audio data to it like most audio-light applications do, so the sound can't be grabbed using the 'desktop' generic source. In the specific application I'm writing I was disappointed to find that calling getUserMedia with an audiooutput device ID confusingly gave up and instead gave me stream containing audio from my laptop's built-in mic. -- GitHub Notification of comment by ivyfae Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/629#issuecomment-668432259 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 4 August 2020 07:32:08 UTC