[whatwg] Audio Interface

On 4/21/06, Jeff Schiller <codedread at gmail.com> wrote:
> 2) Can you clarify the mechanism to determine if a user agent supports
> a particular content type?  Otherwise, as a developer do I just assume
> that every browser will support .wav or .mp3 or .ogg or .mid or .... ?
>  What about a static method on the Audio interface to query content
> types?

A static method would probably be best (or even a sting, with "wav mp3
ogg m4a" or something in it, or even the actual mime type for the
format).  WAV would probably be the baseline required format.

> 3) I think full URIs should be allowed in the Audio constructor.  Why
> must the URI be a relative one?  Is this some crude means of
> preventing leaching of bandwidth?  I feel this is artifically
> constraining what I should be allowed to do as a developer and as a
> service provider.  What if Google wants to start an audio ad program
> for websites?  What if I want to start a web service to let web
> developers use sounds on my server?

I don't see where the spec states that the URI must be relative -- it
merely states that the URI that is used for resolving relative URIs is
the window.location.href URI.

> 4) The term "repeat count" is misleading.The word "repeat" implies a
> re-occurence, so "to repeat once" means to play a total of two times.
> Just globally rename "repeat count" to "play count".  This is more
> accurate of what this number actually is (the number of times the
> sound will play).

I agree; play count would be more descriptive.  I'd also like to see a
pause() method, that pauses playback at whatever current frame is
playing, and then resumes playback there on play().

On the same subject, here's a copy of an email I sent a little while
ago, that I ended up mistakenly not Cc'ing the whatwg list on:

I've been recently thinking about audio as well.. however, I'm not
sure about them not having a DOM presence.  This may be totally off
the wall, but what about adding <audio src="foo.wav"> as an element
within <head>?  The default state of an <audio> element would be
"stopped", but we could do something like:

<audio id="background" src="background.wav" state="playing" repeat="true">
<audio id="fx1" src="fx1.wav">
<audio id="fx1" src="fx1.wav">

the state attribute would take a value of "stopped" (frame 0),
"playing", "paused" (paused/stopped with playback resuming at whatever
frame when it was paused).  These could be mapped to CSS -audio-state
and -audio-repeat or something.  Having these as elements would make
operations like "save as complete web page" be able to do something
useful with the audio elements (even though they could still be
created/loaded purely programmatically).  The default attributes might
be state="playing" with repeat="false"; a bgsound equivalent would be
obtained by state="playing" repeat="true".  The UA should provide a
way to disable audio elements; I'm not a huge fan of bgsound.

Something else that I think would be useful would be an onrepeat
handler; that is, whenever a looping audio stream repeats, it would
fire the handler.  This could be useful for audio synchronization,
e.g. you want to have something happen every time your alarm klaxon
audio repeats, and timers aren't quite precise enough.

   - Vlad

Received on Monday, 24 April 2006 15:39:09 UTC