- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Tue, 18 Jun 2013 01:52:34 +1200
- To: Jukka Jylänki <jujjyl@gmail.com>
- Cc: "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAOp6jLYBreBFD8L57ttzP2E6GXHVucQ9oocx=LFShoRsJba4mA@mail.gmail.com>
On Tue, Jun 18, 2013 at 1:36 AM, Jukka Jylänki <jujjyl@gmail.com> wrote: > With the start()-scheduled approach, In Firefox nightly, the audio > stutters on all sampling rates. In Chrome, audio does not give glitches on > 48kHz or 96kHz. This sample > https://dl.dropboxusercontent.com/u/40949268/emcc/bugs/webaudio_only_sdl_beep.htmlruns through the various sampling rates to allow you to test as well. > OK. Thanks for the testcase. Obviously we (Firefox) have a general scheduling bug. The resampling issue is deeper, however. Perhaps it's not surprising that if we resample a fixed-duration tone and then repeat it using a series of separate AudioBufferSourceNodes, you don't get a continuous tone. Two approaches here might work: 1) specify a sample rate for ScriptProcessorNode and resample its inputs and outputs automatically 2) allow specifying a sample rate for an entire AudioContext at creation time and use either ScriptProcessorNode or AudioBufferSourceNode. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Received on Monday, 17 June 2013 13:53:10 UTC