[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: Re: xAP-Audio schema questions....
- Subject: RE: Re: xAP-Audio schema questions....
- From: "Malcolm Green" <groups@xxxxxxxxxxxx>
- Date: Tue, 11 Jan 2005 22:14:29 -0000
------=_NextPart_000_002C_01C4F82A.EBB2B950
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
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
_____
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|