W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: UC 7 - Audio / Music Visualization

From: Steve Sims <fontfx7@gmail.com>
Date: Wed, 18 Jan 2012 10:40:23 +0000
Cc: Joseph Berkovitz <joe@noteflight.com>, Olivier Thereaux <olivier.thereaux@bbc.co.uk>, public-audio@w3.org
Message-Id: <17D7C538-932D-4945-8405-E991FC255ABD@gmail.com>
To: Alistair MacDonald <al@signedon.com>
On 17 Jan 2012, at 20:32, Alistair MacDonald wrote:

> Steve,
> 
> That's great feedback, thanks!
> 
> Great to hear that iTunes is using a web-view to deliver some audio features already. I did update my iTunes, Safari and download Deadmau5's 4x4=12 LP to check out the web view. Unfortunately all I see is a black screen :(

Hopefully I've managed to address this issue with Alastair off-list...  the LP does work, really, honist guv!  :-)  I think this may have been an issue for only the US version of the LP.

>>  Firstly I wouldn't expect a webpage to provide a user with the ability to control buffer size since that would make for a rather poor user experience.  If the buffer size needs adjusting to cope for slower machines then ideally IMHO the underlying Audio API should be doing that completely transparently.  Failing that, there should be mechanisms in the Audio API to allow for the developer to adjust the buffer size in response to potential playback problems.
>> 
> Yes you are probably right about that, especially in your particular use-case. However, the ability to have some control over buffer 
> sizes is beneficial for the user in some cases such as music production/software music synthesis.

I'm still inclined to think that even in production/synthesis software it's best to hide this kind of thing away from the user and leave it to the underlying API and/or developer to manage.  Something like firing an event to indicate when buffers are running low, or that an under-run has occurred, thus allowing the developer to adjust buffers accordingly in response.  (Please forgive me if this kind of functionality is already in the spec - it's been a while since I've read it through and unfortunately right now don't have time to re-read.)

Of course, the temptation for the developer will be to *not* listen for low-buffer feedback notifications and to just set large buffers.  That's probably best addressed with some 'best practice' documentation in the specification.

Steve
Received on Wednesday, 18 January 2012 15:49:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 January 2012 15:49:52 GMT