Re: Audio Control schema changes

[Stuart Booth]

[ Oops, this got long! ]

In the current audio control schema as published, audio items such as
Volume, Balance etc are queried individually. So to get all the
information you have to send/receive several messages. The sample
applies for details on the current playlist track where even more
requests are required. A bit nasty really!

Edward suggested combining these into one query fetches all relevant
data message. For example:

Class=xAP-Audio.Query

Audio.Query
{
}

Audio.Info
{
Volume=
Balance=
Bass=
Treble=
}

This is a great plan in general I think. However, it does mean
Audio.Info is a 'kitchen sink' block where the possible set of values
could be quite wide ranging. For example, the Audio settings that can
be configured are:

Class=xAP-Audio.Audio[.Event]

Audio.Mute
{
Mute=[On  Off  Toggle]
}

Audio.Mixer
{
Volume=[0...100  +nn  -nn]
--- optional
Balance=[-100...0...+100  +nn  -nn]
--- optional
Bass=[0...100  +nn  -nn]
--- optional
Treble=[0...100  +nn  -nn]
--- optional
}

Audio.SourceSelect
{
Input=[name]
}

We could extend Audio.Info whenever the audio control schema is
changed and requires it, such as the example below:

Class=xAP-Audio.Query

Audio.Query
{
}

Audio.Info
{
Volume=
Balance=
Bass=
Treble=
Mute=
Input=
}

Using Audio.Info you can see that we need to pack everything into the
one block, and hence it doesn't implicitly support future enhancements
(such as the recently added Audio.SourceSelect) so well:
- there might be a field name clash in future.
- it might get rather large over time.
- the conditions where certain values are valid may get overcomplicated.

In some cases a compound block containing all information makes an
awful lot of sense, such as Track.Info describing the current playlist
song.

I was wondering though - since there is an event message sent out when
something changes, it seems we should reuse a similar
style/name/content for the response message to the query, and reuse
the periodic "xAP-Audio.[Category].Info" messages for the
response
information. This can reuse a lot of code on both sides and is
supported in some respects by the Exstreamer already.

.Info blocks are sent periodically with state UNchanged information.
.Event block on the other hand are sent only when a state changes.

This has the effect of removing the response block from the Query
class in some cases at least.

So how about:

Class=xAP-Audio.Query

Audio.Query
{
Query=[ Mute  Mixer  SourceSelect ]
}

[Other queryable items such as Playlist and Track omitted for brevity]

As an example, examine the following. I have annotated the request and
response messages as you can see.

[Request]
Class=xAP-Audio.Query
Audio.Query
{
Query=Mixer
}

[Response]
Class=xAP-Audio.Audio.Info
Audio.Mixer
{
Volume=
Balance=
Bass=
Treble=
}

and also...

[Request]
Class=xAP-Audio.Query
Audio.Query
{
Query=SourceSelect
}

[Response]
Class=xAP-Audio.Audio.Info
Audio.SourceSelect
{
Input=[name]
}

This does require processing of the Query line inside the initial
query block. But this is consistent with Playlist.Query. Some don't
even have any query block content:

[Request]
Class=xAP-Audio.Query
Transport.Query
{
}

[Response - a compound block in this case]
Class=xAP-Audio.Transport.Info
Transport.Info
{
Mode=[Play  Pause  Stop]
Sleep=[Yes  No]
Power=[On  Off]
Length="Length"
Position="Position"
Index="playlist index"
Decoder="encoding:bit-rate:sample-rate"
}

and

[Request]
Class=xAP-Audio.Query
Playlist.Query
{
Query=[Track  List]
Index="index in playlist"
}

[Response - where Query=Track]
Class=xAP-Audio.Playlist.Info
Track.Info
{
Title="title"
Artist="artist"
Album="album"
Path="path to current track"
Duration="title duration"
Index="playlist index"
Tracks="number of tracks in the current playlist"
Genre="genre"
}

or

[Response - where Query=List]

Class=xAP-Audio.Playlist.Info

Playlist.Info
{
Tracks="length of play list"
Index="index of current track"
Shuffle=[On  Off]
Repeat=[Stop  Track  Playlist]
}

It has the advantage of a query mechanism falling out of an existing
informational broadcast system and can be easily extended.

I did wonder about changing the query from:

Class=xAP-Audio.Query

Audio.Query
{
Query=[ Mute  Mixer  SourceSelect  ... ]
}

Where the Query values are fixed, making this free-text and specifying
the block name that we're interested in. Although this does mean the
blocks have to be kept unique unless the class name is specified too
e.g.:

Query
{
Query=xAP-Audio.Audio[.Info?]:Audio.Mixer
}

Hopefully all these changes will fix a few flaws in the schema which
has been fairly static for almost a year now.

S

PS - congrats for reading this far! ;-)
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=N1CuJT4bJWSGD9d9F00sKYxHZDr-OWEIJPCkNVhGn7sQZaAEbRbX7svB5D3knXKyzt5pKXzMfMTw4QmJgd4">stuart@x...</a>>
xAPFramework.net - a xAP software development framework for .net

<a href="http://www.xapautomation.org/";>http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>