Re: Integer PCM sample formats to Web Audio API?

Hi again,

I'm definitely not saying "WONTFIX". Just to be clear, I fully support 
the idea of adding support for creating AudioBuffers from integer sample 
formats.

I might have misunderstood your message. When reading about "triple-A 
games" and "games engine middleware" I started thinking about 
contemporary products, and figured that the best solution would be to 
use a proper Web Audio API back end for such situations, rather than an 
OpenAL/SDL_audio/whatever-on-top-of-WebAudio wrapper.

On the subject of saving memory (and possibly improving the performance 
on some architectures), I have already suggested that we should consider 
some mechanism for allowing the audio engine to store AudioBuffers 
internally in formats other than Float32 (e.g. compressed or 16-bit 
integer - see [1] & [2] for instance). However, I still feel that it's a 
good idea to separate source data formats and internal formats, 
otherwise we risk adding a lot of more complexity to the API and its 
implementations.

/Marcus

[1] http://lists.w3.org/Archives/Public/public-audio/2013OctDec/0295.html
[2] http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0230.html




2014-01-08 16:21, Jukka Jylänki skrev:
> Direct3D vs OpenGL is not the correct analogy here. If Web Audio spec 
> resolved the need for integer sample formats as WONTFIX, it would be 
> the equivalent of WebGL having said "For simplicity, we'll only do 
> 4xFloat32 RGBA textures as the only texture format type and don't 
> support any other integer formats or compressed texture formats. That 
> shall be the WebGL way.", which would have been completely horrible.
>
> Instead, OpenGL vs Direct3D is a very good example to the contrary, 
> they are exactly in the feature parity competition business. Direct3D 
> 11.2 just recently introduced support for "Tiled resources" ( 
> http://msdn.microsoft.com/en-us/library/windows/desktop/dn312084(v=vs.85).aspx 
> <http://msdn.microsoft.com/en-us/library/windows/desktop/dn312084%28v=vs.85%29.aspx> 
> ), a way to do virtualized textures or "megatexturing". OpenGL done 
> the same in OpenGL 4.4 with GL_ARB_sparse_texture ( 
> http://www.techpowerup.com/187584/khronos-releases-opengl-4-4-specification.html 
> ). Why? Since they understand that in order to stay viable as a 
> seriously investable spec, they must compete in features. The way you 
> program against the two APIs is immaterial in comparison, but that 
> they both support the same _use cases_ and _features_ is extremely 
> important. One should not confuse an API, i.e. the way you program 
> against the features, and the features themself that the API offers.
>
> 2014/1/8 Marcus Geelnard <mage@opera.com <mailto:mage@opera.com>>
>
>     What I mean is that you should keep the Web platform in mind when
>     designing your game engine ...
>
>
> My previous post tried to illustrate why this is a not a valid 
> counterargument to make. For projects like HTML5 port of ScummVM: 
> http://clb.demon.fi/html5scummvm/ or the Javascript MESS emulator: 
> http://jsmess.textfiles.com there is no "designing your game engine" step.
>
> 2014/1/8 Marcus Geelnard <mage@opera.com <mailto:mage@opera.com>>
>
>     otherwise you'll just be doing a port...
>
>
> Yes! We are doing a port!
> 2014/1/8 Marcus Geelnard <mage@opera.com <mailto:mage@opera.com>>
>
>     ... and it is quite likely that the port will perform noticeably
>     worse on the Web compared to the originally intended platform(s).
>
> And this will happen exactly if the Web platform is rigid and was not 
> designed to support the same features that the projects that are to be 
> ported needed. But since we are in the roles that can have a say over 
> what features Web Audio supports, it does not have to be that way.
>
>    Jukka


-- 
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software