The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Barix Exstreamer native xAP implementation.


  • Subject: Re: Barix Exstreamer native xAP implementation.
  • From: Stuart Booth
  • Date: Mon, 22 Dec 2003 19:15:00 +0000

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=Zug2E9df3f_tdLESy7kycfGug95lvGDmDOd1dP35tv-5iG-PaK8xWz_psdl2QuBBQUi5s9uyG0Jeu5HLouboMCnoxUMWyNk">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.

>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.

>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.

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

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?

>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.

>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.

S
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=r_byKi4jVkNCM1pDFI2qQhSWZl2Y_UVAccMBLVAUgWUZy0HRAnVik9EnyKiLUExeTXrD0ksTUPAF5QGO05c">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>





xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.