Re: Pertaining to testing the audio demo posted earlier

Hi Grant,

I love your Wave_Player work, this is absolutely awesome!!

It would be nice to turn this project into a tool we can use for
testing. It would be useful to add the following features:

1) Drag from Desktop to window, instead of clicking "Load File"
2) Looping of loaded samples
3) Debug info that we can use to test speed on different machines

IMPORTANT NOTE:
Grant, I seem to remember this is the second or third time that you have
brought this issue up and I am glad you are still pushing on it. I think
everyone will agree that getting the JavaScript Processing Node fast is an
extremely important part of the Audio API implementation.

I think tests are needed here.

On a side note Grant, have you compared the difference in speed a for-loop
accessing a Float32Array (without any audio code whatsoever), between
Chrome / Firefox / Safari? You would need to subtract this result from any
Audio tests to get a more accurate idea of how much of the time is actually
being spent in the AudioNode / AudioData architecture.

Alistair


On Mon, Nov 14, 2011 at 3:01 AM, Grant Galitz <grantgalitz@gmail.com> wrote:

> bug: http://code.google.com/p/chromium/issues/detail?id=103812
>
>
> On Mon, Nov 14, 2011 at 3:00 AM, Grant Galitz <grantgalitz@gmail.com>wrote:
>
>> I had to open an issue in the Google Chrome tracker separately for this
>> page, as Chrome can run it slower than Firefox 3.0 (Yes 3.0, and 3.6 too)
>> in some cases. Google Chrome's scaling of <canvas> internally when CSS
>> fixed positioning is encountered is unbelievably slow and is much slower
>> than in most other browsers. The poor buffering from web audio for handling
>> javascript audio nodes also compounded the issue, causing major gaps in
>> audio when google chrome is resized to only a few hundred pixels in each
>> dimension.
>>
>> To test your own wav files I've also set up
>> http://www.grantgalitz.org/wav_player/
>>
>
>