[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: Tue, 17 Feb 2004 08:49:00 +0000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<TITLE>Message</TITLE>
<DIV><SPAN class="799522908-17022004"><FONT
face="Arial" color="#0000ff"
size="2">Sounds like it would be better for mcsMusic to listen
out for the new transport.event blocks that are sent out when the transport
moves to a different track. The kind of need you describe is exactly the
kind of scenario they were intended to support. Sounds to me that at the
moment you have to rely on continually polling the unit using queries to
see where it's got to. Polling is always a wasteful activity. With the
.event messages indicating state changes and the regular .info reminders,
there should actually be little need for the query mechanism at
all.</FONT></SPAN></DIV>
<DIV><SPAN class="799522908-17022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="799522908-17022004"><FONT
face="Arial" color="#0000ff" size="2">You
also make an important point that all nodes on the xAP network receive all
messages, Indeed this is the spirit of xAP - the sender does not know what
devices and applications are going to make use of the information it sends
(even when it is a response to a query from a specific node) so it is best
for it to send complete descriptions rather than very specific responses
that will only be of interest to one specialised application. Receiving xAP
nodes should be able to know if a message is interesting to them by the
time they have inspected the source, class and target fields in the header;
un-interesting messages can be discarded without inspecting the body
blocks.</FONT></SPAN></DIV>
<DIV><SPAN class="799522908-17022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="799522908-17022004"><FONT
face="Arial" color="#0000ff" size="2">We
are both writing audio unit controller applications, which is great! I'm
not going to dig my heels in here and stop the fine-grained query mechanism
if you really need it and Stuart doesn't mind inplementing it. It's just
that I think there is much more elegant solution using
events.</FONT></SPAN></DIV>
<BLOCKQUOTE dir="ltr">
<DIV></DIV>
<DIV class="OutlookMessageHeader" lang="en-us"
dir="ltr" align="left"><FONT
face="Tahoma" size="2">-----Original
Message-----<B>From:</B> Michael McSharry [mailto:mcs101main@xxxxxxx]
<B>Sent:</B> 17 February 2004 01:26<B>To:</B>
xAP_developer@xxxxxxx<B>Subject:</B> Re: [xAP_developer] Audio
Control schema changes</FONT></DIV>
<DIV><FONT face="Arial" size="2">In the
mcsMusic application the Playlist query is used to retrieve the current
index into the playlist. When the playlist index approaches the
end of mcsMusic cache then another block from the server's playlist is
retrieved. Once a forward-looking playlist segment has been
retried then there is sufficient information for preview data
display. There is no longer any need to retrieve blocks of
playlist data since that block exists in the cache. All that is
needed is the index. It is not that big a deal to receive all the
playlist data and dump all but the index, but it seems like a
waste. Every byte that goes on the network needs to be received by
every xap application and cpu cycles burned by each doing the buffering and
decoding. WIth a small network and limited number of apps it will
not even be noticed, but I do not see how it hurts to provide a design in
the schema that all
ows the implementer the freedom of how to optimize use of the available
resources. The individual items can be optional and the makeup of
the Track and List can be optional as well.</FONT></DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV>----- Original Message ----- </DIV>
<BLOCKQUOTE>
<DIV><B>From:</B> <A
title="edward.mailgroup@xxxxxxx" href="mailto:edward.mailgroup@xxxxxxx";>Edward
Pearson</A> </DIV>
<DIV><B>To:</B> <A
title="xAP_developer@xxxxxxx" href="mailto:xAP_developer@xxxxxxx";>xAP_developer@xxxxxxx</A>
</DIV>
<DIV><B>Sent:</B> Monday, February 16, 2004 2:44
PM</DIV>
<DIV><B>Subject:</B> RE: [xAP_developer] Audio Control
schema changes</DIV>
<DIV></DIV>
<DIV><SPAN class="372062522-16022004"><FONT
face="Arial" color="#0000ff" size="2">I'm
dubious about the usefulness of such fine-grained queries. For example, I
can't imagine what kind of application would be in need of
information on the artist of a particular track in the playlist but is not
interested in the title of the track. Or just the Genre. Do you have a
real-world need for this granularity?</FONT></SPAN></DIV>
<DIV><SPAN class="372062522-16022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="372062522-16022004"><FONT
face="Arial" color="#0000ff" size="2">If
the main reason is bandwidth concerns then I'd counter that such a scheme
would increase the amount of packets being sent (and thus bandwidth used)
considerably. On an ethernet network, even with something very 'chatty'
such as xAP-News the bandwidth used is barely mesurable. For serial
networks I understand that the general thinking is now that the
ethernet-serial xAP bridge will have to have pretty tight filtering setup
to ensure the serial side only carries information relevant to the devices
on that segment. The difference in bandwidth between these two most common
transports is many orders of magnitude so they have to be treated quite
differently.</FONT></SPAN></DIV>
<DIV><SPAN class="372062522-16022004"><FONT
face="Arial" color="#0000ff"
size="2"></FONT></SPAN> </DIV>
<DIV><SPAN class="372062522-16022004"><FONT
face="Arial" color="#0000ff" size="2">I'm
wary (when defining any software interface not just xAP) of getting into
theoretical discussions that add unneccesary complexity without any
real-world need. The spirit of xAP is very much one of simplicity;
my suggested changes to the audio schema were aimed at triming down the
number of variations of messages and getting away from the earlier
fine-grained query scheme.</FONT></SPAN></DIV>
<BLOCKQUOTE dir="ltr">
<DIV></DIV>
<DIV class="OutlookMessageHeader" lang="en-us"
dir="ltr" align="left"><FONT
face="Tahoma" size="2">-----Original
Message-----<B>From:</B> Michael McSharry [mailto:mcs101main@xxxxxxx]
<B>Sent:</B> 14 February 2004 18:45<B>To:</B>
xAP_developer@xxxxxxx<B>Subject:</B> Re: [xAP_developer] Audio
Control schema changes</FONT></DIV>
<DIV><FONT face="Arial" size="2">I
generally agree with information returned in block format, but at the same
time consideration should be given to low bandwith interfaces as well as
the general proliferation where the "state" of all providers is
clogging up the network. When a query is made it should be
possible to query either a particular key or a group. This will
allow the optimum level of traffic as determined by the unit that is in
need of the information.</FONT></DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Arial" size="2">Using the
example</FONT></DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Courier
New">[Request]Class=xAP-Audio.QueryPlaylist.Query{
Query=[Track List Title Artist Album Path Duration Index Tracks
Genre] Index="index in
playlist"}[Response - where
Query=Track]Class=xAP-Audio.Playlist.InfoTrack.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"}</FONT></DIV>
<DIV><FONT face="Courier
New"></FONT> </DIV>
<DIV><FONT face="Courier New">[Response - where
Query=Artist]Class=xAP-Audio.Playlist.InfoArtist.Info{
Artist="artist"}</FONT></DIV>
<DIV></DIV>
<BLOCKQUOTE>
<DIV><SPAN class="372062522-16022004"><FONT
color="#0000ff"> [originals
truncated] </FONT></SPAN><!-- **end egp html
banner**
--></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|