Re: xAP-Audio schema questions....

["Edward Pearson" <edward.mailgroup@xxxxxxxxxxxxxxxx>]

The Exstreamer embedded solution sends out regular now.playing
messages and in that it includes an (off-spec) progress parameter
which is something like
position=<bytes so far>/<total bytes>

(I say "something like" as I'm on a business trip at the moment
and
can't check the code)

The reason for using the bytes was because that is all that is
available on the Exstreamer client API. The Exstreamer does all its
MP3 decoding in hardware on the client so there's no access to the
frame structure of the stream or the metadata within in it, just the
byte stream.

The now.playing message block gets included in all .event messages
as well as being sent at regular intervals when there's a stream
active. I like the idea of varying the frequency on context;
particularly useful for ff/rew situations.

I just reviewed the text of the spec and it's not clear on when and
where .events can happen. The intention was that any command
received can generate a .event/.info message in just the same way as
BSC defines it. So, any activity, triggered either by local control
or a xAP command or some other control channel should generate
a .event message if it caused a change (eg, transport went from play
to pause) and a .info message if the state remained unchanged. The
Exstreamer implementation includes a copy of the xAP command block
that caused the action (assuming it was xAP that caused it) in the
response (event/info) message so you can see both what happened and
why. If that's as clear as mud then I can post some examples when I
get back to the UK over the weekend.

I'd be happy to agree that the current schema needs work to bring it
up to the standard of the ones that have been written more recently.
Yay, we're getting better at this stuff! It leaves too much loosely
defined; the demarcation between the transport, playlist and control
elements is not good enough and it maps too closely to the specifics
of the devices that that it's been implemented on to date.



--- In xAP_developer@xxxxxxx, Kevin Hawkins <lists@u...>
wrote:
> Thnaks for feedback P...
>
> patrick@l... wrote:
>
> >
> >
> >>>It strikes me we could do with defining some additional
time
related
> >>>parameters for inclusion in the event reporting timeline
including
> >>>
> >>>Duration  <mandatory>
> >>>StartTime <mandatory>
> >>>EndTime <mandatory>
> >>>CurrentTime  <mandatory>
> >>>ElapsedTime   <optional ?>
> >>>RemainingTime  <optional ?>
> >>>
> >>>
> >
> >I didn't write the original schema, but I raised similar queries
when
> >I was doing the xAP Rio stuff and I think these are already
covered.
> >Notification events can be sent asynchronously, they don't have
to be
> >sent in response to an explicit query.
> >
> Yes,  - I think that's OK and we should ask that they be sent with
some
> reasonable periodic frequency. I haven't seen anything about
including
> the other time parameter keys though - specifically
the 'CurrentTime' or
> position being reported which is the key one showing progress
through a
> track. The others just provide completeness for a full reporting
of
> position. The remaining time is very useful when you are 'push'
driving
> a player with tracks on the fly rather than appending to a
playlist.
>
> I am still a little unclear in which .event schema local transport
> change messages are sent (eg FF or Pause is pressed on the player)
and
> what the defined parameter values are for these actions  FF REW
Pause
> STOP REC MUTE etc
>
>
> >Perhaps Stuart et al can
> >comment? I also think there may be some undocumented extensions
to the
> >published schema - is what is on xapautomation.org the latest and
> >greatest?
> >
> >
> I am using the schema from the Wiki - if there is a newer version
around
> or any extensions  can someone point me to them ??
>
> >
> >
> >
> >>>.. and that these should be sent periodically at a
frequency
that is
> >>>configurable as different users might want tighter
feedback. 10
secs
> >>>sounds a useful time for most implementations. Towards the
end
of the
> >>>current track it may be desireable to increase the
frequency of
events
> >>>
> >>>
> >
> >I like the idea of a varying update frequency, sounds sensible to
me.
> >If you wanted to get really sexy you could bump up the frequency
> >whenever a user initiated event occurred (a button was pressed
etc),
> >for a few seconds...
> >
> >
> Yes I guess feedback is most vital whenever and event has happened
or is
> imminent (eg track change/end) this leads to a much nicer realtime
user
> experience. Easy to play with this concept later once we have the
time
> events being reported.  If no-one comes back with comments I'm
going to
> propose that the additions above be made.
>
> Comments from me on above schema additions...
>
>  Remaining time I listed as <optional> but is highly recommended
> (useful) , I would sort of like to make it mandatory even - ..
>
> Where end times are unknown eg a streaming source we need to know
what
> values to put in there - maybe a blank value will suffice, or ? or
unknown.
>
> CurrentTime could be 'Position' I guess.
>
> K