[linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1

[torbenh at gmx.de]

On Mon, Mar 13, 2006 at 11:59:15PM +0100, stefan kersten wrote:
> On Mon, Mar 13, 2006 at 11:40:04PM +0100, fons adriaensen wrote:
> > On Mon, Mar 13, 2006 at 05:25:04PM -0500, Paul Davis wrote:
> > > On Mon, 2006-03-13 at 23:10 +0100, fons adriaensen wrote:
> > > > Is it true on the common platforms that using ntohl and htonl on
> > > > floats will always result in compatible data on the wire or in a
> > > > file ? In other words, are floats byte-swapped consistently w.r.t.
> > > > the Intel format on all big-endian systems ?
> > > 
> > > network byte order was defined to be big-endian in the early 1980s.
> > > those two functions create big-endian 32 bit representations regardless
> > > of the host platform.
> > 
> > That much I know, so let me rephrase the question: is network byte order
> > also defined for single precision IEEE floats ? If not, is there a de
> > facto standard ?
> 
> as paul stated, network byte order is defined to be
> big-endian, so yes, you have to convert 32 bit floats (and
> doubles, for that matter) on intel, because they are stored
> lsb first. of course it would be perfectly valid for netjack
> to use little endian `on the wire'; but this would be like
> putting my powerbook in little endian mode when playing a
> wav file. sort of.

so you say that i should not htonl the floats i copy from my net buffer
to the jack-port ?
i doubt, this is a great performance impact.

when i change the packet format next time, i could change that to byte
swap on a PPC. but considering that PPCs are generally slower than x86
nowadays, this would create more cpu load on a jack-network.

i am puzzled. did anybody actually test it ?
well at least there is some netjack thread now :/


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language