Re: Barix Exstreamer native xAP implementation.

[Edward Pearson]

Stuart, replies to your quesitons in-line below
Edward

>From: Stuart Booth [mailto:<a
href="/group/xAP_developer/post?postID=JJZjN_MiNEVfDop8vqC7XLQj32a3hRP08bFfoD_seZUg34xwyBJSaEHY3h4NEGNNqNu_gW4Rv99QEowQC48f">lists@x...</a>]
>Sent: 22 December 2003 19:16
>To: <a
href="/group/xAP_developer/post?postID=iyHGIfRQyfxbbUFGp6Y1dhpYjMHthC24z3XxDUNQwjPr5RZkGUAW3-bW2u3hwHJPq4m_qXgM03rfjMsv51165p9s7j9x">xAP_developer@xxxxxxx</a>
>Subject: Re: [xAP_developer] Barix Exstreamer native xAP
implementation.

>Edward, this sounds really, really excellent!

>I've got an Exstreamer sitting on top of a shelf here gathering dust
>... I sadly and ashamedly confess I just haven't got to it yet. It's
>sitting beside some Rio's and some X10 gear that are in the same
>state.

>So I'm up for giving it a whirl sometime. Somethig else on the ToDo
>list will have to go!

>>On Mon, 22 Dec 2003 18:49:15 -0000, "Edward Pearson"
>><<a
href="/group/xAP_developer/post?postID=RzEjyAxZwyqEadxyx6JARw9XyffElJT9VF4AtwpcW3ucU7FeNqCdMZJ2LHrdJJBkDB1q3bNLZ1htqk71trrFKACBIPjQBssg9AJPSQ">edward.mailgroup@b...</a>>
wrote:

>> Basic transport
>>functionality includes play, stop, pause, next, previous. I have
>>followed the relevant bit of the Whole House Audio schema
>>(<a href="http://www.xapframework.net/modules.php?";>http://www.xapframework.net/modules.php?</a>
>>name=Sections&amp;op=viewarticle&amp;artid=1) as closely as
possible.

>Ooo, that's interesting. I always hoped that that version would flop
>onto other players quite neatly. However, as I've not yet used it
for
>anything else, you are making me wonder how you got on - what bits
>didn't work so well, what you'd change, what you thought was wrong.

Generally I just picked out the very minimum bits that made sense
for a first version.

Firstly it does basic command/status along the lines of
(my interpretation of) Kevin's proposal.
It responds to
xAPcmd.status with:
xap-header
{
v=12
hop=1
uid=FF456700
class=xAPstatus.info
source=Barix.Exstreamer.LivingRoom
}
output.state
{
00=OFF
}
OFF is stopped, ON is playing. Similarly xAPcmd.state will set it
playing "00=ON" or stop it "00=OFF". Play state changes
for this or
any other
reason will generate a xAPstatus.event message similar to the .info
one above.

For xAP-Audio it responds to:
Audio.Transport: play, pause (toggle), stop, prev, next.
Playlist.Track: append

Remember, it's modelled on a traditional 'jukebox' so its internal
playlist
is a queue that it plays from the head/front with new requests being
appended
to the tail/back. [list members please note the correct use of both
"it's" and "its" in the previous sentence :-) ]
It will move to the previous track as long as it's [correct] entry
has
not been garbage collected.
Queue entries are track URL's; neither the unit's h/w or s/w do any
kind of
tag interpretation so any interaction at the level of Title,
Artist, Genre etc is out of scope.
I leave this to the client application that the user selects music
with.

Every five seconds when playing it generates a Transport.Notification
message. Here I filled in some of the unspecified bits of the schema
with what seemed appropriate. For example:

xap-header
{
v=12
hop=1
uid=FF456700
class=xAP-Audio.Query
source=Barix.Exstreamer.LivingRoom
}
Transport.Notification
{
stream=MP3:256:44100
url=<a
href="file://192.168.8.11/music/Fools">file://192.168.8.11/music/Fools</a>
Gold '95/01 - Fools Gold.mp3
progress=1634304
total=8288008
message=
}

The stream parameter indicates the h/w decoder status.
url is the current file
progress is the number of bytes streamed so far and
total in the number of bytes in the file
message is used to report additional status or errors.

>>2) Everything the unit does has to be written in a single thread
of a
>>Basic program. For the jukebox this means the program has to deal
>>with moving blocks of data between the network interface and the
MP3
>>decoder at the same time as responding to xAP commands. When
playing
>>decent quality MP3's (>192kbps) the unit can only process xAP
>>commands infrequently. eg, I get to check the UDP port about once
>>every 80ms. Processing a complex command such as add a new URL to
the
>>queue can take upto 500ms with all the string processing required,
at
>>which point your media stream buffer is looking seriously
depleted.
>>This has to main consequences:
>>
>>a) a busy xAP network effectively constitutes a denial of service
for
>>the MP3 stream since all broadcast packets need to be inspected
even
>>if they are to be discarded. Hitting the box with a stream of xAP
>>packets could cause the sound to break up.

>Oh dear!

>Any ideas what sort of rate you tend to have at which point trouble
>sets in? My own network traffic is increasing, although it's not in
>the ballpark of others by a long way.

It's noticeable already. Even with just a few apps chattering away
with heartbeats and the like you sometimes miss a transport command.
I have to heavily throttle sending messages to the unit, for instance
what queuing an album (one append message for each track) I send
only one
per second to reduce the chance of them being ignored.

>>How do other embedded apps deal with these issues? The broadcast
>>nature of xAP at the packet level is troubling me since a xAP node
>>cannot control the volume of traffic arriving at it.

Still looking for opinions here...

>Is there any advantage to be had from having these sit on a
different
>subnet with a filtering gateway?

It would work but seems a bit of a heavy handed solution.
What does a PC (or other) do when a (relatively) large number of
broadcast
UDP packets arrive? Presumably there is some point at which
it starts dropping them.

>You mentioned earlier that:

>>Currently it is only available as alternative firmware (not
>>integrated) for the units so you give up all the production
firmware
>>features when you install Basic eg, the Exstreamer running basic
has
>>no webserver.

>Does this firmware make it xAP only? So you wouldn't lose other
>functionality by putting it onto a different network Seems a shame
to
>have to do so, but if there is too much traffic, what else can be
done
>with xAP?

As a general clarification, the Basic firmware turns the unit into
something that will just run Basic programs. The Basic program I have
written for that environment implements a xAP controlled jukebox.
So, yes, in its current form it is xAP only (but receives all UDP
broadcast packets).

>>would be less of an issue if I was developing for the unit in
>>embedded C or assembler rather than interpreted basic but
>>nevertheless there seems to be no way of ensuring that a node be
able
>>to guarantee dealing with everything it receives. Do anybody
else's
>>xAP implementations suffer from message overload?

>All my stuff is PC based so far, sorry. 15.65 xAP messages per
minute
>apparently.

Well the Extreamer should double that for you with its status
chattering!

>>Future
>>Next project is to xAP enable the Barionet. This will suffer fewer
>>challenges than the Exstreamer since it doesn't have to play
music!
>>Barix have kindly donated a pre-production unit for me to work
with.
>>For those of you who don't know what this is it's essentially a
DIN
>>mountable module with ethernet, web server, couple of serial
ports, a
>>bunch of digital and analog I/O's, two mains relays and a 1-Wire
>>interface (eg, for temperature sensors).
>>See
>><a href="http://www.barix.com/en/datasheets/Product%20Sheet%20Barionet%";>http://www.barix.com/en/datasheets/Product%20Sheet%20Barionet%</a>
>>20V16.pdf
>>Sounds like quite a powerful component for part of a xAP
household. I
>>think my central heating boiler maybe about to get a webserver!

>Excellent :)))) ! The idea of webservers on all manner of devices
>quite appeals to my "endless fun with h/w devices" side...

>I really like the sound of this Barionet. I see the docs mention
Barix
>extension modules too.

So far I've resisted starting this till I've packaged up the
Exstreamer
stuff. A few more comments hear and there... and a read me.