14 Mar
2006
14 Mar
'06
3:01 p.m.
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:
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
On Mon, Mar 13, 2006 at 05:25:04PM -0500, Paul
Davis wrote:
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. On Mon, 2006-03-13 at 23:10 +0100, fons
adriaensen wrote:
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 ? 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.