Barix Exstreamer native xAP implementation.

[Edward Pearson]

All,

I have spent the last few weeks working on a native implementation of
xAP for the Barix Exstreamer network MP3 player (www.exstreamer.com).
I say native because there in no PC application involved; the xAP
interface is implemented on the unit itself. I'm not sure if this is
the first time xAP has been added to a commercially available harware
device. All the other implementations seems to use either a dedicated
PC gateway application (eg, StuartB's Slim connector) or a modified
form of the device's server application (eg, recent SliMP3 xPL
announcement).

I have been working with a beta version (actually numerous beta
versions) of an alternative firmware for the Exstreamer being
developed at Barix. This firmware implements a version of Small Basic
with extensions to control the Exstreamer hardware. I have written a
sample xAP jukebox application in this Basic language as a
feasibility test on embedded xAP control and as a testbed for the
beta testing that I have been doing for Barix. The jukebox needs no
server software to run other than a collection of MP3 files available
on a windows (or other CIFS implementation file share). I have also
written a very simple user interface using xapframework to test out
the implementation. Functionality on the unit is modelled on a
traditional jukebox (no neon lights though): the user requests a song
to be played (by sending a URL) and it gets added to a play queue.
The player plays its way through the queue of songs. 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.

Challenges
It's been quite a challenging project mainly due to:
1) developing a program at the same time as the language
implementation is evolving and being debugged is always fun!
2) working in such a simple language as Small Basic is little more
powerful than assembler.
3) trying to work around the very tight memory and performance
constraints of the unit.

more on each of these below.

Barix have been hugely responsive over the last few weeks, I've
sometimes received multiple updates of the firmware in a single day
in response to both my finding bugs in their implementation and also
in response to me requesting new features to be added. Background is
that they are developing this Basic for integration with all their
products (Exstreamer and Barionet currently) at some point in the
future. 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.

Small basic is fun! It's hardly C# or Java. Switching between
developing for the unit in Basic and developing the user interface in
C# and xAPframework is like time-warping back and forwards across 25
years of computing (oops, showing my age). Small basic has: line
numbers (no renumbering), only global variables (max 5 chars in the
name), no code blocks just if then goto line number, gosub (no
parameters), integer arrays but no string arrays, max 64 named
variables etc etc. Parental advisory: don't show the code to anybody
under 18; it may affect them quite adversely! The more recent
versions are tokensied but still interpreted so performance is not
great.

The exstreamer is essentially a Lantronix DSTni-LX embedded processor
coupled to a Micronas 35x9F DSP for MP3 decoding. The challenges of
programming an embedded device are exacerbated considerably by using
a Basic implementation but it does mean that user applications can be
produced for the device without any development boards or special
compilers; a text editor is all you need (there's an add-on for
TextPad that does syntax colouring for Basic). Specific challenges
have been (or continue to be):

1) Memory constraints. Once you allocated 32k for the media buffer,
4k for the stream read buffer and 4k for URL storage there's not much
space left so global variables need to be reused judiciously.

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. I deal with this by
prioritising media stream playing over xAP command processing but
this means missing xAP packets - see next point.

b) While the program is processing a xAP command (even if it is to be
discarded) there's only an input buffer slot for UDP packets so it's
easy to loose targetted commands if they arrive close together or are
masked out by other xAP devices talking. (OK, Maybe I should try
queueing inbound xAP commands).

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. Obviously this
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?

Conclusions
Despite the challenges/shortcomings above this has been a very
interesting experiment in xAP enablement of a real time device. IMHO
it's not ready to leave the xAP Developer group at this time due to
the challenges described above. But it is good enough for me to
listen to music on and I much prefer the jukebox metaphor to the
standard Exstreamer playlist-based user interface. I've created a
listenable custom music playing device and a user interface that,
since it's xAP, is totally decentralised (multiple clients can add to
the common play queue - fun for all the family - well, all members
with a laptop on their knee). Anlybody that wants the code is very
welcome, just email me. Barix have just put that most recent Basic
firmware up on the exstreamer yahoo group.

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!

Edward Pearson
<a
href="/group/xAP_developer/post?postID=lDZjrG5Z2WnSAbKx5ExtSzBsUSzlVg5dzT-OVVFQysDXcMFSYnelTmvpbXdrd386YJHqKUdq9SIWEgCIfgopicOFa8aL3EBLtJs">edward.pearson@b...</a>