Re: Input buffer's time coordinate

Hi Raymond,

Am sorry my question sounds only about app implementation. I also just
wondering that AudioProcessing ( and current draft for audioWorker's
AudioProcess ) Event should have some information about original playback
time. `e.originalPlaybackTime` is a missing feature for me, I don't know
enough use cases are in the world, though.


And, the reason why I don't use offlineAudioContext is very clear. Chrome
has a bug around thread pool and crashes when many (around 1024 or 2048?)
offlineAudioContext has created.
https://code.google.com/p/chromium/issues/detail?id=433479#c3


Sébastien,

JFYI, I implemented the timecode channel as you suggested, and it works
very well, on both chrome and firefox. thanks Again!


Akira

2015-11-02 13:06 GMT+09:00 Raymond Toy <rtoy@google.com>:

> This has kind of drifted off-topic for the public-audio list, which is
> about the spec itself.  You should try public-audio-dev list instead.
>
> But for your particular case, why not use an offline audiocontext with an
> AudioBufferSource node with a constant signal followed by a gain node?
> This is how the automation diagram in the spec
> <http://webaudio.github.io/web-audio-api/#example1-AudioParam> was
> produced.  The source for the diagram is
> https://googlechrome.github.io/web-audio-samples/samples/audio/timeline.html
> .
>
> On Mon, Nov 2, 2015 at 12:13 AM, Akira Sawada <aklaswad@gmail.com> wrote:
>
>> Hi Sébastien,
>>
>> Thanks for the advice!
>> ChannelMerger was completely out of my sight! Yes, your code looks that I
>> want.
>> Will try this idea, and also tackle more simple way (e.g. use
>> param.linearRampToValueAtTime(LENGTH_OF_A_DAY, LENGTH_OF_A_DAY) to generate
>> timestamp instead ).
>>
>> P.S.
>> I'm also feeling sad to know there's no way to do this in non hacky way ;)
>>
>> thanks so much!
>>
>> Akira
>>
>>
>> 2015-11-02 0:10 GMT+09:00 s p <sebpiq@gmail.com>:
>>
>>> Hi Akira,
>>>
>>> I had the same problem a while ago. For this I find a hack, which works
>>> well in Chrome but not in Firefox (at the time there was a bug I think with
>>> ChannelMergerNode which was causing a problem there, but now maybe it is
>>> fixed?). You can find the code there :
>>> https://github.com/WhojamLab/WAARecorderNode/blob/master/lib/TimeTaggedScriptProcessorNode.js
>>>
>>> The basic idea is to use a BufferSourceNode playing a ramp - which is
>>> basically your timeline - and merge that audio signal with the signal you
>>> want to send to your ScriptProcessorNode. That way you both the signal you
>>> are interested in AND the timeline which gives you a precise time tag for
>>> each sample of your signal.
>>>
>>> I could also package this as a separate library, but considering that
>>> things are going to change soon enough, and ScriptProcessorNode will
>>> disappear, and these problems of unpredictable latency should disappear
>>> with it (will they?)
>>>  ... it is probably not worth ...
>>>
>>> Cheers
>>>
>>> On Sun, Nov 1, 2015 at 7:26 AM, Akira Sawada <aklaswad@gmail.com> wrote:
>>>
>>>> Hi group,
>>>>
>>>> I'm writing an audioParam automation editor (
>>>> http://aklaswad.github.io/alligata/envelope/ ) and using
>>>> scriptProcessor as simple peek meter in it.
>>>>
>>>> So, I want to know the exact time the samples in inputBuffer was
>>>> processed for.
>>>> Those input samples could have an information about context based time
>>>> coordinate because they're also processed on top of the time coordinate.
>>>>
>>>> Is there a way to know that?
>>>>
>>>> thanks.
>>>>
>>>> --
>>>> 澤田 哲 / Akira Sawada / aklaswad
>>>>
>>>> email me: aklaswad@gmail.com
>>>> visit me: http://blog.aklaswad.com/
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Sébastien Piquemal*
>>>
>>>  -----* @sebpiq*
>>>  ----- http://github.com/sebpiq
>>>  ----- http://funktion.fm
>>>
>>
>>
>>
>> --
>> 澤田 哲 / Akira Sawada / aklaswad
>>
>> email me: aklaswad@gmail.com
>> visit me: http://blog.aklaswad.com/
>>
>
>


-- 
澤田 哲 / Akira Sawada / aklaswad

email me: aklaswad@gmail.com
visit me: http://blog.aklaswad.com/

Received on Monday, 2 November 2015 08:31:19 UTC