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

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

------=_NextPart_000_0027_01C4FD9E.607B9B30
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

The approach I've taken to modelling for xAP schemas is straight from
traditional object modelling analysis. When I saw the early versions of the
audio schema I was concerned that the model had not broken the physical
devices down into their logical component (object) parts. That schema
followed some pretty specific aspects of the harware that was being
controlled (ie the SliMP3). The Exstreamer (and it particular my
experimental, proprietary firmware for it) presents quite a different
system
that broke that model. Therefore I proposed a set of clarifications to the
first version schema based on this experience. Given limited time and
resources the schema currently published and implemented by the Slim
Connector and others was a compromise.

The model I was using (that is not too far from the uPnP model - something
that I did look at briefly during design, but seem to remember thinking it
wasn't quite right - not been back and checked it though) has the following
primary objects in it:

Transport - the thing that plays a piece of music (normally a single audio
file, call it song for short). It is responsible for outputting the
file/stream into the outside world (eg, to an amplifier). It only knows
about the current song. It can play it, pause it, and stop it. Optionally,
it can seek backwards and forwards along the time dimension of the song. It
can find out meta data about the song from tags in the file, but the
problem
with this is that not all files/streams have that information so I
preferred
to keep the typical metadata set (song name, artist, track no etc)
explicitly in the schema. The transport is associated with a particular
playlist object from which it can request the next song to play on
completion of the current song.

Audio - responsible for controlling of the audiable aspects of the sound
eg,
volume/muting, eq, balance.

Display - self explanatory, the Slim has one, the Extreamer doesn't.

Playlist - a logical object responsible for managing a set of songs. A
controller/user adds songs to the playlist that they want to listen to.
They
can also remove songs, reorder them, set repeats and shuffles. Primary use
is to manage the set of songs that will be listened to in the near future.
But they could also be persisted so they can be performed again at a later
time.

Router - a service that manages the association between playlists and
transports. The current schema reduces this to a one to one association
between a playlist and a transport unfortunately. For a multi-room setup
this service would manage the matrix mapping multiple play lists and
multiple transports eg you could have playlist A playing on transports 1,2
&
3 while a second playlist B was playing on transports 4 & 5.

Library - a service that manages a collection of songs. Not currently part
of the xAP schema. Resposible for managing the physical, persisten storage
of a (possibly large) collection of songs and their associated metadata.
Has
interfaces that let a user/controller browse/search the collection and
choose songs for adding to a playlist.

Controller - and end user application with modules that interface to
transports, playlists,  routers and libraries.

So that's the model. The current schema supports transports, playlists (a
bit of Audio) but not the other objects. Early versions of the schema
didn't
have the split of responsibility between transport and playlist well
defined. Any lack of clarity between these items either in the current spec
or in current implementations is due to that legacy. Some of the proposals
that have been posted here recently don't follow this model. Hopefully this
explanation of the thinking behind the current schema will assist the
discussion of possible extensions. Apologies for taking too long to reply
in
detail.

On a related topic - query requesting vs status broadcast - the schema
supports both, but the frequent broadcasting of status is closer to the
core
xAP philosophy (different from uPnP). It has several advantages; one of the
key ones being better scalability over a query/polling approach. At the
network level xAP is a broadcast protocol (UDP on ethernet) so it's
counter-logical to implement RPC-like query/response constructs on top of
this. A consequence of this is that transport should include now.playing
blocks in most messages they transmit on the reasoning that some other
device on the network may find the information useful.


_____

From: Malcolm Green [mailto:groups@xxxxxxx]
Sent: 11 January 2005 22:14
To: xAP_developer@xxxxxxx
Subject: RE: [xAP_developer] Re: xAP-Audio schema questions....



Hi Kevin,


_____

From: Kevin Hawkins [mailto:lists@xxxxxxx]
Sent: 11 January 2005 17:43
To: xAP_developer@xxxxxxx
Subject: Re: [xAP_developer] Re: xAP-Audio schema questions....


Just as an aside one of the objectives of the xap-audio schema must
be that within an application , in this example TelCanto, you should be
able to just define a player type as xAP and it all just works as for
any other directly supported player.   It must be fully controllable and
provide realtime events back to TelCanto in such a way that it can be
precisely managed within TelCanto. Local actions on a xAP player eg
pressing skip or selecting a new track to play from an IR remote or
controlling it from another application eg the SliMP3 player vai the web
interface  must provide sufficient realtime feedback for the application
to stay in synch and in control.
Currently TelCanto is I believe architected as a 'push' type player,
based on it being the only controller, I dont think it handles local
changes on the player itself , indeed it doesnt need to.


Not strictly true.  TelCanto continually "polls" the player to
check its
status, so it will detect if, for example, it has been paused or stopped
via
a remote control or web interface.  It will be slightly easier and more
efficient if there is an event mechanism.

Later though,
with multiple players and ever more complex architectures  this might be
a needed architecture. What for example should happen when a Slim player
being controlled via TelCanto has playlist changes made via the
SlimServer web interface....?  That's one for the particular application
to choose to support in whatever way they choose (or ignore)  - all that
matters is that that a xAP player provides rich enough info to leave
this choice to the developer.

So Malcolm - if there's things you would need in this scenario - then
tell us and we'll get them included.

Kevin

PS This borders on difficult areas like should a xAP player support
playlist management - handling this as a software queue for a player
that doesnt natively offer this capability ????   My experience is that
most applications that would be using a xAP player in this way probably
drive it directly saying 'play this <UNC pathname> now'  and then
issue
this again for the next track at exactly the right time , possibly they
queue one track as a play next if the player supports it eg with
something like WinAMP - I know XLobby does this to allow the player to
naturally play continually without split second commands being needed.
Thinking about this there could be a separate xAP playlist (helper)
manager application just driving a raw player if a fancier player was
needed...


I think the helper approach is probably the best solution - keep the player
itself as simple as possible.

Regards,
Malcolm



_____