[whatwg] Audio Interface

Mon Apr 24 20:08:45 PDT 2006

Vlad,

Thanks for the reply.  I would prefer something with the actual MIME
types.  Here are some important ones (in my opinion):

audio/x-wav
audio/mpeg
application/ogg
audio/mid

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

I don't personally see a strong need at this point, but if you're
going to do this, at least make them valid XML elements :P

Regards,
Jeff

On 4/24/06, Vladimir Vukicevic <vladimirv at gmail.com> wrote:
> 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
>