11 Mar
2006
11 Mar
'06
2:06 p.m.
netjack-0.8 is released.
netjack links jackds together via a network.
build your linux-audio cluster. work on a remote ardour,
or even 2 ardours at once.
netjack is also great for jamming with a friend.
- one period roundtrip latency.
- transport sync supporting slow-sync clients.
see: http://netjack.sourceforge.net
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
12 Mar
12 Mar
9:11 a.m.
New subject: [linux-audio-dev] [ANN] netjack-0.9rc1
On Sat, Mar 11, 2006 at 07:01:43PM +0100, torbenh(a)gmx.de wrote:
netjack-0.9rc1 is here...
endianess issues fixed. tests are underway...
but if it works for 2 x86 (double swap) it should work for PPC <-> x86
netjack-0.8 is released.
netjack links jackds together via a network.
build your linux-audio cluster. work on a remote ardour,
or even 2 ardours at once.
netjack is also great for jamming with a friend.
- one period roundtrip latency.
- transport sync supporting slow-sync clients.
see: http://netjack.sourceforge.net
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
4:50 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Sun, 2006-03-12 at 14:06 +0100, torbenh(a)gmx.de wrote:
netjack-0.9rc1 is here...
endianess issues fixed. tests are underway...
but if it works for 2 x86 (double swap) it should work for PPC <->
x86
Why do you use big-endian on the wire, requiring a double swap for x86
<-> x86? Wouldn't LE make more sense, especially as PPC Macs become
unavailable?
Lee
13 Mar
13 Mar
5:26 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee Revell wrote:
On Sun, 2006-03-12 at 14:06 +0100, torbenh(a)gmx.de
wrote:
well i am not in a position to redefine ntohl and htonl.
sorry.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
netjack-0.9rc1 is here...
endianess issues fixed. tests are underway...
but if it works for 2 x86 (double swap) it should work for PPC <->
x86
Why do you use big-endian on the wire, requiring a double swap for x86
<-> x86? Wouldn't LE make more sense, especially as PPC Macs become
unavailable?
5:45 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Mon, 2006-03-13 at 22:21 +0100, torbenh(a)gmx.de wrote:
On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee Revell
wrote:
Sorry, my question was stupid - obviously I've been away from networking
for a while ;-)
On Sun, 2006-03-12 at 14:06 +0100, torbenh(a)gmx.de
wrote:
well i am not in a position to redefine ntohl and htonl.
sorry.
netjack-0.9rc1 is here...
endianess issues fixed. tests are underway...
but if it works for 2 x86 (double swap) it should work for PPC <->
x86
Why do you use big-endian on the wire, requiring a double swap for x86
<-> x86? Wouldn't LE make more sense, especially as PPC Macs become
unavailable? 
5:59 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Mon, 2006-03-13 at 16:45 -0500, Lee Revell wrote:
On Mon, 2006-03-13 at 22:21 +0100, torbenh(a)gmx.de
wrote:
its not a stupid question. and it really isn't hard to write functions
which could be called htobe and betoh, for example.
On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee
Revell wrote:
Sorry, my question was stupid - obviously I've been away from networking
for a while ;-) On Sun, 2006-03-12 at 14:06 +0100, torbenh(a)gmx.de
wrote:
well i am not in a position to redefine ntohl and htonl.
sorry.
netjack-0.9rc1 is here...
endianess issues fixed. tests are underway...
but if it works for 2 x86 (double swap) it should work for PPC <->
x86
Why do you use big-endian on the wire, requiring a double swap for x86
<-> x86? Wouldn't LE make more sense, especially as PPC Macs become
unavailable? 
6:03 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Mon, Mar 13, 2006 at 10:21:39PM +0100, torbenh(a)gmx.de wrote:
On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee Revell
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 ?
--
FA
Why do you use big-endian on the wire, requiring
a double swap for x86
<-> x86? Wouldn't LE make more sense, especially as PPC Macs become
unavailable?
well i am not in a position to redefine ntohl and htonl.
6:22 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Mon, 2006-03-13 at 23:10 +0100, fons adriaensen wrote:
On Mon, Mar 13, 2006 at 10:21:39PM +0100,
torbenh(a)gmx.de wrote:
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.
--p
On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee
Revell 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 ? Why do you use big-endian on the wire, requiring
a double swap for x86
<-> x86? Wouldn't LE make more sense, especially as PPC Macs become
unavailable?
well i am not in a position to redefine ntohl and htonl.
6:33 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
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:
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 ?
--
FA
Follie! Follie delirio vano e' questo!
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.
6:38 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
Can LAU be removed from further replies?
On Mon, 2006-03-13 at 23:40 +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:
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. 
6:58 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
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:
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.
<sk>
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.
7:14 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Mon, Mar 13, 2006 at 11:59:15PM +0100, stefan kersten 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.
OK, but for floats the situation could be more complex. On Intel,
the exponent/sign byte is the last one. Is it always the first
one on BE platforms ? If it isn't then using ntohl() or htonl()
wich are designed to work on 32-bit ints will not help.
For doubles, things are even more fuzzy. Can you just use ntohl()
and htonl() on both halves, or do these two have to be swapped as
well ? Will either rule produce consistent results on all
platforms ?
--
FA
Follie ! Follie delirio vano e' questo !
7:34 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Tue, 2006-03-14 at 00:21 +0100, fons adriaensen wrote:
On Mon, Mar 13, 2006 at 11:59:15PM +0100, stefan
kersten wrote:
i don't believe that "network order" is defined for floats, but one
could reasonably assume it was the same big-endian ordering. however,
since the IEEE spec crosses 8 bit boundaries (IIRC), simply using *to*
isn't going to work. i think this applies also to doubles.
ntohf and htonf would be required, i think.
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.
OK, but for floats the situation could be more complex. On Intel,
the exponent/sign byte is the last one. Is it always the first
one on BE platforms ? If it isn't then using ntohl() or htonl()
wich are designed to work on 32-bit ints will not help.
For doubles, things are even more fuzzy. Can you just use ntohl()
and htonl() on both halves, or do these two have to be swapped as
well ? Will either rule produce consistent results on all
platforms ?
8:14 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Tue, Mar 14, 2006 at 12:21:40AM +0100, fons adriaensen wrote:
OK, but for floats the situation could be more
complex. On
Intel, the exponent/sign byte is the last one. Is it
always the first one on BE platforms ? If it isn't then
using ntohl() or htonl() wich are designed to work on
32-bit ints will not help.
IEEE 754 defines the layout of a single float:
1 | 8 | 23 |
s | e | f |
|msbit lsbit|msbit lsbit|
from which i'd say the byte order can be derived. the
sign/exponent is in the msb, so it's stored first on BE and
last on LE machines.
For doubles, things are even more fuzzy. Can you just
use
ntohl() and htonl() on both halves, or do these two have
to be swapped as well ? Will either rule produce
consistent results on all platforms ?
doubles are defined similarly; to convert between LE and BE
you have to reverse the bytes or equivalently swap the
reversed 32-bit words.
<sk>
14 Mar
14 Mar
3 a.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
fons adriaensen wrote:
OK, but for floats the situation could be more
complex.
In libsndfile I use a 32 bit end swapper on floats and a
64 bit endswapper on doubles.
Will either rule produce consistent results on all
platforms ?
The above does produce consistent results across platforms
(tested on x86, ia64, ppc and mips).
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Oh my god! They killed init! You bastards!
2:44 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Tue, Mar 14, 2006 at 12:21:40AM +0100, fons adriaensen wrote:
On Mon, Mar 13, 2006 at 11:59:15PM +0100, stefan
kersten wrote:
the current netjack code for converting the floats is tested.
it works. at least for PPC <-> intel
i only added the packet header after that test, and robert did not yet
test it again.
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.
OK, but for floats the situation could be more complex. On Intel,
the exponent/sign byte is the last one. Is it always the first
one on BE platforms ? If it isn't then using ntohl() or htonl()
wich are designed to work on 32-bit ints will not help.
For doubles, things are even more fuzzy. Can you just use ntohl()
and htonl() on both halves, or do these two have to be swapped as
well ? Will either rule produce consistent results on all
platforms ?
i am happy, that i dont need to transfer doubles :)
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
3:01 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
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.
3:14 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Tue, 2006-03-14 at 19:56 +0100, torbenh(a)gmx.de 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.
These were just suggestions... of course the performance impact is
small. But when a code path will be called on every sample then even a
0.01% speedup is worthwhile.
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 :/
Well, you did post your announcement to a development list - if you only
wanted testers you should have only sent to LAU ;-)
Lee
3:30 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Tue, Mar 14, 2006 at 02:13:59PM -0500, Lee Revell wrote:
:) that explains it....
On Tue, 2006-03-14 at 19:56 +0100, torbenh(a)gmx.de
wrote:
well i dont think, that doing something simple with the data being
copied does cost anything. you can prove me wrong though...
the memory is the bottleneck. or is this pathetic because of 98% cache
hits ?
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.
These were just suggestions... of course the performance impact is
small. But when a code path will be called on every sample then even a
0.01% speedup is worthwhile. 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 :/
Well, you did post your announcement to a development list - if you only
wanted testers you should have only sent to LAU ;-)
Lee
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
3:37 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
On Tue, Mar 14, 2006 at 07:56:47PM +0100, torbenh(a)gmx.de wrote:
no, it was a joke.
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.
i doubt that too.
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 don't think that's measurable either because the byte swap
is probably not the main source of overhead. besides, i'm on
ppc, so plz plz don't change it :)
thanks for netjack!
<sk>
7171
days inactive
7174
days old
linux-audio-dev@lists.linuxaudio.org
19 comments
6 participants
participants (6)
-
Erik de Castro Lopo -
fons adriaensen -
Lee Revell -
Paul Davis -
stefan kersten -
torbenh＠gmx.de