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
