Re: Extending MediaRecorder to record from Web Audio node faster than real time?

I suspected that Recorder would be interesting bit.  :)

ROC, the challenge I have here is it's quite easy to prevent
MediaStreamAudioDestinationNode from being created in an offline context -
we simply remove the constructor from OfflineAudioContext.  There's an open
issue on this (https://github.com/WebAudio/web-audio-api/issues/308), I
just haven't gotten to it yet.  But once you can construct a recorder and
hand it an arbitrary node, we'll have to deal with the interaction between
OfflineAudioContext and MediaStreamRecorder in some way.  This seems like
mostly convenience over the current way.  Am I missing something?


On Wed, Aug 27, 2014 at 9:05 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>  On 08/27/2014 05:57 PM, Chris Wilson wrote:
>
> Is a MediaStream (and Recorder) going to be happy about having its number
> of channels changed in mid-stream?
>
>
> MediaStreams can have tracks added and removed at any time; they're rather
> flexible.
>
> Recorder has certain issues with that, since some of the formats we want
> to record to don't do things like multiple video tracks where some of them
> start midstream.
>
> The recorder spec will have to say what it does when such things happen
> (either error out or continue recording only on the tracks present at
> initialization).
>
>
>
>
> On Wed, Aug 27, 2014 at 8:26 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>> On 08/27/2014 03:35 AM, Robert O'Callahan wrote:
>>
>>> BTW as far as "details to be worked out", I don't think there's anything
>>> new here to figure out (although there is a bit more text to write). "new
>>> MediaRecorder(audioNode)" should behave almost exactly like "var dest =
>>> audioNode.context.createMediaStreamDestination(); audioNode.connect(dest);
>>> new MediaRecorder(dest.stream);". The only edge case I can think of is
>>> handling ChannelSplitterNode.
>>>
>>
>>  If it should behave "almost exactly like", can we define it to behave
>> "exactly like"?
>>
>> Including a possible error exception when encountering
>> ChannelSplitterNode?
>>
>> If there are two ways of doing the same thing, I'd like to have
>> completely consistent behaviour rather than "almost consistent behaviour".
>>
>>
>>
>>> Rob
>>> --
>>> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
>>> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
>>> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
>>> owohooo
>>> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o
>>> o‘oRoaocoao,o’o oioso
>>> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
>>> owohooo
>>> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
>>> ooofo
>>> otohoeo ofoioroeo ooofo ohoeololo.
>>>
>>
>>
>>
>
>