- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Mon, 21 Jun 2010 11:00:31 +0200
- To: Chris Marrin <cmarrin@apple.com>, Jim Garrison <jim@garrison.cc>, "public-xg-audio@w3.org" <public-xg-audio@w3.org>
Hi all, I never received the mail from Jim, but I support his view. I don't think this group would have to address the access to the mic - this is already being discussed in the DAP WG. But allowing the mic(s) as a source opens up for more audio related use cases. For example to enhance the mic signal by removing noise from the signal. Or, in the case of several mics, to estimate the direction to the source (relative to the device). The full-duplex case add more interesting(?) topics, such as echo handling and 3D playout. --Stefan -----Original Message----- From: public-xg-audio-request@w3.org [mailto:public-xg-audio-request@w3.org] On Behalf Of Chris Marrin Sent: den 20 juni 2010 18:44 To: Jim Garrison Cc: public-xg-audio@w3.org Subject: Re: Common goals and framework On Jun 18, 2010, at 9:01 PM, Jim Garrison wrote: > On 06/17/2010 09:47 AM, Chris Marrin wrote: >> Additionally, we described 3 sources of audio: >> >> 1) Streaming audio (from <audio> and <video> nodes) >> >> 2) Buffered audio. This is file-based audio, but which is buffered in memory so it can be efficiently played and reused. >> >> 3) Generative audio. This could come from nodes with built-in >> oscillators and synthesizers, or generated from JavaScript > > Why not also allow audio from a device input, such as the user's > microphone? Sure, full-duplex raises additional issues, but we are > leaving out several important use cases for audio if we don't consider > real, live audio as a possible source. That adds the issue of device access, similar to live video recording. That's a good task for someone to access. But I believe it's out of scope for this particular spec, which focuses on audio processing of existing sources. ----- ~Chris cmarrin@apple.com
Received on Monday, 21 June 2010 09:02:37 UTC