- From: Chris Wilson <cwilso@google.com>
- Date: Thu, 10 Jan 2013 16:46:51 -0800
- To: He Shiming <heshiming@gmail.com>
- Cc: "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAJK2wqUibcHrRxR-PrLDN5kk9Tv+2-e4k5xyi6i9V3p-aKZrtw@mail.gmail.com>
It's not really that only the OfflineAudioContext does transcoding; the issue is that you want to control your output rate/format, which can only be done by using an OfflineAudioContext (or setting the hardware settings on your audio output device). If you could set your output format for audio output to 16kHz, you would see that all the audio output (from recorderJS, for example) would be in that format. -Chris On Thu, Jan 10, 2013 at 4:16 PM, He Shiming <heshiming@gmail.com> wrote: > I see. So OfflineAudioContext can do transcoding. Hope it will be exposed > soon. Thanks again Chris. > > > On Fri, Jan 11, 2013 at 2:39 AM, Chris Wilson <cwilso@google.com> wrote: > >> The more problematic portion of this, He, is that I suspect your input >> device is giving a higher bitrate than you want anyway, so there's no >> getting around that you'll need to transcode your input stream (unless your >> input hardware really is giving a 16kHz mono stream) - it's just whether >> there would be built-in ways to do that, and right now, there aren't. In >> our current design, the input is promoted to the output's hardware rate - >> it's not locked to 44kHz/stereo/16bit, that just happens to be what your >> output hardware is. >> >> Reducing from stereo to mono is easy, of course. As I mentioned before, >> dropping from 44kHz to 22kHz is also easy; but if you really need to encode >> at specifically 16kHz, and don't want to write the interpolation code, you >> can always record the buffer in your normal AudioContext, then create an >> OfflineAudioContext at 16kHz mono 16bit, call offlineContext.createBuffer( >> 1, length, sampleRate ); and copy the data from your recorded buffer, then >> play in the offline context and encode the resulting buffer you're handed >> in oncomplete. >> >> >> On Thu, Jan 10, 2013 at 6:44 AM, He Shiming <heshiming@gmail.com> wrote: >> >>> Thanks Rob. >>> >>> But the so called 'StreamRecorder' is a bit confusing. A google search >>> came up nothing related. Though the sample code here: >>> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/webrtc-integration.htmldid mention the '.record' method on LocalMediaStream interface, the actual >>> draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html mentioned >>> 'Apr 23 2012 - Remove MediaStreamRecorder' with no further explanation. >>> >>> >>> On Thu, Jan 10, 2013 at 6:47 PM, Robert O'Callahan <robert@ocallahan.org >>> > wrote: >>> >>>> The StreamRecorder API proposal in public-media-capture is a better fit >>>> for this use-case. It will let developers record directly to WAV with >>>> minimal JS code, at whatever the native sample rate of the stream is. >>>> >>>> Rob >>>> -- >>>> Jesus called them together and said, “You know that the rulers of the >>>> Gentiles lord it over them, and their high officials exercise authority >>>> over them. Not so with you. Instead, whoever wants to become great >>>> among you must be your servant, and whoever wants to be first must be >>>> your slave — just as the Son of Man did not come to be served, but to >>>> serve, and to give his life as a ransom for many.” [Matthew 20:25-28] >>>> >>> >>> >>> >>> -- >>> Best regards, >>> He Shiming >>> >> >> > > > -- > Best regards, > He Shiming >
Received on Friday, 11 January 2013 00:47:19 UTC