[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: Audio Control schema changes
- Subject: RE: Audio Control schema changes
- From: Edward Pearson
- Date: Mon, 16 Feb 2004 23:07:00 +0000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<TITLE>Message</TITLE>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff" size="2">I
like splitting the response blocks up into functional components. But I
find your suggested naming a bit odd. Following your functional divisions
I'd suggest:</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2">Mixer.Info</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2">Source.Info</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2">Mute.Info</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2">(with corresponding .Event variations when something
has changed)</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff" size="2">To
me (having been an audio engineer in a former life) the following
functional divisions seem more
logical:</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff" size="2">Gain
- anything to do with the amplitude of the signal, includes: volume,
balance and mute</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff" size="2">EQ -
anything to do with filtering the signal, including bass, treble,
loudness</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2">Routing - would be where Mark's 'source' would
fit.</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff" size="2">For
even a basic routing schema, we should probably include the ability to
monitor at least one tape-loop ( TapeMon1=[on off]
).</FONT></SPAN></DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="426424622-16022004"><FONT
face="Arial" color="#0000ff" size="2">FYI
These are terms coming out of my early thinking towards the next major
evolution of this schema which I am aiming to have cover all manner of
domestic audio-visual equipment including multi-channel (home-cinema) and
multi-room setups. But more on that when my thinking has reached
critical-mass.</FONT></SPAN></DIV>
<BLOCKQUOTE>
<DIV></DIV>
<DIV class="OutlookMessageHeader" lang="en-us"
dir="ltr" align="left"><FONT
face="Tahoma" size="2">-----Original
Message-----<B>From:</B> Stuart Booth [mailto:lists@xxxxxxx]
<B>Sent:</B> 14 February 2004 18:09<B>To:</B>
xAP_developer@xxxxxxx<B>Subject:</B> Re: [xAP_developer] Audio
Control schema changes</FONT></DIV><TT>[ Oops, this got
long! ]In the current audio control schema as published, audio items such
asVolume, Balance etc are queried individually. So to get all
theinformation you have to send/receive several messages. The sampleapplies
for details on the current playlist track where even morerequests are
required. A bit nasty really!Edward suggested combining these into one
query fetches all relevantdata message. For
example:Class=xAP-Audio.QueryAudio.Query{}Audio.Info{
Volume= &a
mp;nbsp; Balance=
Bass= Treble=}This is a great plan in general
I think. However, it does meanAudio.Info is a 'kitchen sink' block where
the possible set of valuescould be quite wide ranging. For example, the
Audio settings that canbe configured
are:Class=xAP-Audio.Audio[.Event]Audio.Mute{Mute=[On Off
Toggle]}Audio.Mixer{Volume=[0...100 +nn
-nn] ---
optionalBalance=[-100...0...+100 +nn
-nn] ---
optionalBass=[0...100 +nn
-nn] ---
optionalTreble=[0...100 +nn
-nn] ---
optional}Audio.SourceSelect{ Input=[name]}We
could extend Audio.Info whenever the audio control schema ischanged and
requires it, such as the example
below:Class=xAP-Audio.QueryAudio.Query{}Audio.Info{
Volume= &
;nbsp; Balance=
Bass= Treble=
Mute= Input=}Using Audio.Info you can see
that we need to pack everything into theone 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 anawful lot of sense, such as Track.Info describing
the current playlistsong.I was wondering though - since there is an event
message sent out whensomething changes, it seems we should reuse a
similarstyle/name/content for the response message to the query, and
reusethe periodic "xAP-Audio.[Category].Info" messages for the
responseinformation. This can reuse a lot of code on both sides and
issupported 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
Queryclass in some cases at least.So how
about:Class=xAP-Audio.QueryAudio.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 andresponse messages as you can
see.[Request]Class=xAP-Audio.QueryAudio.Query{
Query=Mixer}[Response]Class=xAP-Audio.Audio.InfoAudio.Mixer{Volume=Balance=Bass=Treble=}and
also...[Request]Class=xAP-Audio.QueryAudio.Query{
Query=SourceSelect}[Response]Class=xAP-Audio.Audio.InfoAudio.SourceSelect{
Input=[name]}This does require processing of the Query line inside the
initialquery block. But this is consistent with Playlist.Query. S
ome don'teven have any query block
content:[Request]Class=xAP-Audio.QueryTransport.Query{}[Response - a
compound block in this
case]Class=xAP-Audio.Transport.InfoTransport.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.QueryPlaylist.Query{
Query=[Track List] Index="index in
playlist"}[Response - where
Query=Track]Class=xAP-Audio.Playlist.InfoTrack.Info{
Title="title"
Artist="artist"
Album="album" Path=&quo
t;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.InfoPlaylist.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
existinginformational broadcast system and can be easily extended.I did
wonder about changing the query
from:Class=xAP-Audio.QueryAudio.Query{
Query=[ Mute Mixer SourceSelect ... ]}Where the Query values are fixed,
making this free-text and specifyingthe block name that we're interested
in. Although th
is does mean theblocks have to be kept unique unless the class name is
specified tooe.g.:Query{
Query=xAP-Audio.Audio[.Info?]:Audio.Mixer}Hopefully all these changes will
fix a few flaws in the schema whichhas been fairly static for almost a year
now.SPS - congrats for reading this far! ;-)-- Stuart Booth
<stuart@xxxxxxx>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></TT>
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|