On Thu, Jan 9, 2014 at 6:47 AM, Jukka Jylänki <jujjyl@gmail.com> wrote: > Yes, that would definitely help with the int->float->int problem for > mobile, and allow lifting JS code from having to implement signal format > conversion. However it will not directly help with memory issues. If the > browser stores the data internally as float, it will still require twice > the memory. If that improvement would let browser store the audio data as > 16-bit int as well, then I think it would be helpful. > Yes, we could store the AudioBuffer contents as 16-bit samples and convert to float on the fly, so I think it would solve the memory usage issues. Furthermore, if you avoid mixing and processing --- so at any given time there's only one active AudioBufferSourceNode feeding into an AudioDestinationNode --- we could skip the float conversion entirely. But that's a bit tricky and unclear if it's really worth doing. 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 Thursday, 9 January 2014 03:32:57 UTC