Re: Re: xAP-Audio schema questions....

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Thnaks for feedback P...

patrick@xxxxxxx 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