[whatwg] Audio Interface

Mon Apr 24 23:11:11 PDT 2006

On 4/24/06, Jeff Schiller <codedread at gmail.com> wrote:
> 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

Sure, the actual mime types would be fine.  One problem is that
application/ogg isn't specifically an audio format, since ogg is just
a container format... the same would apply to mpeg4, say.  Not sure
what to do about that, since the MIME types aren't descriptive enough
there.

> > <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

HTML isn't a XML language :)  But yes, in XHTML they would be <audio/>, sure.

    - Vlad

> 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
> >
>
>