On Thu, 04 Aug 2005 01:07:23 +0100, Pooh Bear wrote:

wrote:

wrote:
Pooh Bear wrote:
DaveC wrote:

Is there a wireless solution to distributing audio throughout a residence to
8 rooms? Digital?

Something similar to wireless computer networking...

Currently only at mp3 like quality. True16 bit linear pcm in
stereo @ 44kHz sampling requires something like about 6 Mbps
of bandwidth.

44,1000 ksamples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

Sorry, that's:

44,1000 samples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

or

44.1 ksamples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

In any case, it's 1.4 Mbits/sec, NOT 6 Mbits/sec.

That's the raw data rate only !

Now you have to add overhead for the frequency hopping stuff, handshaking, whatever
and redundancy for lost packets - and I've no idea how the data's encapsulated -
there'll doubtless be extra stuff there too. I'm not calculating this myself, I have
it on good authority from some guys who are developing the product. I was quite
surprised how much overhead is required myself actually.

You don't have to use TCP/IP, and you don't need, or even want, lost
packet redundancy, at least not for streaming audio. If you need a
protocol at all, use something like UUCP.

Cheers!
Rich

Pooh Bear wrote:
wrote:

wrote:
Pooh Bear wrote:
DaveC wrote:

Is there a wireless solution to distributing audio throughout a residence to
8 rooms? Digital?

Something similar to wireless computer networking...
Currently only at mp3 like quality. True16 bit linear pcm in
stereo @ 44kHz sampling requires something like about 6 Mbps
of bandwidth.
44,1000 ksamples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec
Sorry, that's:

44,1000 samples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

or

44.1 ksamples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

In any case, it's 1.4 Mbits/sec, NOT 6 Mbits/sec.

That's the raw data rate only !

Now you have to add overhead for the frequency hopping stuff, handshaking, whatever
and redundancy for lost packets - and I've no idea how the data's encapsulated -
there'll doubtless be extra stuff there too. I'm not calculating this myself, I have
it on good authority from some guys who are developing the product. I was quite
surprised how much overhead is required myself actually.

Graham


Even accepting your numbers, a 10 Mbps link is adequate. So it's not
necessary to resort to MP3.

--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form .

On 8/3/05 5:07 PM, in article , "Pooh Bear"
wrote:

wrote:

wrote:
Pooh Bear wrote:
DaveC wrote:

Is there a wireless solution to distributing audio throughout a residence
to
8 rooms? Digital?

Something similar to wireless computer networking...

Currently only at mp3 like quality. True16 bit linear pcm in
stereo @ 44kHz sampling requires something like about 6 Mbps
of bandwidth.

44,1000 ksamples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

Sorry, that's:

44,1000 samples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

or

44.1 ksamples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

In any case, it's 1.4 Mbits/sec, NOT 6 Mbits/sec.

That's the raw data rate only !

Now you have to add overhead for the frequency hopping stuff, handshaking,
whatever
and redundancy for lost packets - and I've no idea how the data's encapsulated
-
there'll doubtless be extra stuff there too. I'm not calculating this myself,
I have
it on good authority from some guys who are developing the product. I was
quite
surprised how much overhead is required myself actually.

You've provided other BS swearing about the correctness of it and have been
wrong. Your credibility slipped before this and stating 6 Mbit/s here
confirms you don't know Jack.

Rich Grise wrote:

On Thu, 04 Aug 2005 01:07:23 +0100, Pooh Bear wrote:

That's the raw data rate only !

Now you have to add overhead for the frequency hopping stuff, handshaking, whatever
and redundancy for lost packets - and I've no idea how the data's encapsulated -
there'll doubtless be extra stuff there too. I'm not calculating this myself, I have
it on good authority from some guys who are developing the product. I was quite
surprised how much overhead is required myself actually.

You don't have to use TCP/IP, and you don't need, or even want, lost
packet redundancy, at least not for streaming audio. If you need a
protocol at all, use something like UUCP.

If you don't account for lost packets what's going to happen to any lost audio data ? I'll
ask some more next time I talk to the guys about the protocol they're using.

Graham

CJT wrote:

Pooh Bear wrote:
wrote:

wrote:
Pooh Bear wrote:
DaveC wrote:

Is there a wireless solution to distributing audio throughout a residence to
8 rooms? Digital?

Something similar to wireless computer networking...
Currently only at mp3 like quality. True16 bit linear pcm in
stereo @ 44kHz sampling requires something like about 6 Mbps
of bandwidth.
44,1000 ksamples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec
Sorry, that's:

44,1000 samples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

or

44.1 ksamples/sec * 16 bits/sample * 2 channels = 1,411,200 bits/sec

In any case, it's 1.4 Mbits/sec, NOT 6 Mbits/sec.

That's the raw data rate only !

Now you have to add overhead for the frequency hopping stuff, handshaking, whatever
and redundancy for lost packets - and I've no idea how the data's encapsulated -
there'll doubtless be extra stuff there too. I'm not calculating this myself, I have
it on good authority from some guys who are developing the product. I was quite
surprised how much overhead is required myself actually.

Graham


Even accepting your numbers, a 10 Mbps link is adequate. So it's not
necessary to resort to MP3.

10Mbps would indeed be fine if the link could grab most of the relevant bandwidth.

Existing 2.4G audiolinks are mostly 'mp3' like. Look for the term 'sub band codec' in the
description - although many are simply sold using the confusing and meaningless term
'stereo quality' !

I note that Jim Thompson commented on a analogue FM based 2.4G audio link too.

Graham

"Pooh Bear" wrote in message
...

Rich Grise wrote:

On Thu, 04 Aug 2005 01:07:23 +0100, Pooh Bear wrote:

That's the raw data rate only !

Now you have to add overhead for the frequency hopping stuff,
handshaking, whatever
and redundancy for lost packets - and I've no idea how the data's
encapsulated -
there'll doubtless be extra stuff there too. I'm not calculating this
myself, I have
it on good authority from some guys who are developing the product. I
was quite
surprised how much overhead is required myself actually.

You don't have to use TCP/IP, and you don't need, or even want, lost
packet redundancy, at least not for streaming audio. If you need a
protocol at all, use something like UUCP.

If you don't account for lost packets what's going to happen to any lost
audio data ? I'll
ask some more next time I talk to the guys about the protocol they're
using.

Graham


You get a 'pfsst' noise (that may lose something in translation) until
everything sync's up again. Audio streaming isn't generally critical stuff
so why bother trying to make up the lost stuff.

Ken

Pooh Bear wrote:
Rich Grise wrote:

On Thu, 04 Aug 2005 01:07:23 +0100, Pooh Bear wrote:

That's the raw data rate only !

Now you have to add overhead for the frequency hopping stuff, handshaking, whatever
and redundancy for lost packets - and I've no idea how the data's encapsulated -
there'll doubtless be extra stuff there too. I'm not calculating this myself, I have
it on good authority from some guys who are developing the product. I was quite
surprised how much overhead is required myself actually.
You don't have to use TCP/IP, and you don't need, or even want, lost
packet redundancy, at least not for streaming audio. If you need a
protocol at all, use something like UUCP.

If you don't account for lost packets what's going to happen to any lost audio data ? I'll
ask some more next time I talk to the guys about the protocol they're using.

Graham

Once their time has passed, they're irrelevant.

--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form .

"Pooh Bear" wrote in message
...

Existing 2.4G audiolinks are mostly 'mp3' like. Look for the term 'sub
band codec' in the
description - although many are simply sold using the confusing and
meaningless term
'stereo quality' !

Well, I use a wireless link for my Netgear MP101, and it handles .wav files.

I see it says on the box that the MP101 uses 802.11g, which uses the 2.4GHz
technology, and speeds are "up to 54Mbps" (yea, right ...).

Tim

..

Ken Taylor wrote:

"Pooh Bear" wrote in message
...

If you don't account for lost packets what's going to happen to any lost
audio data ? I'll
ask some more next time I talk to the guys about the protocol they're
using.

Graham


You get a 'pfsst' noise (that may lose something in translation) until
everything sync's up again. Audio streaming isn't generally critical stuff
so why bother trying to make up the lost stuff.

That's what I thought.

That makes such a scheme unacceptable for serious hi-fi or professional audio
usage which will be the mainstay of the market for such a product.

Ergo... redundancy *is* required.

Graham

CJT wrote:

Pooh Bear wrote:
Rich Grise wrote:

On Thu, 04 Aug 2005 01:07:23 +0100, Pooh Bear wrote:

That's the raw data rate only !

Now you have to add overhead for the frequency hopping stuff, handshaking, whatever
and redundancy for lost packets - and I've no idea how the data's encapsulated -
there'll doubtless be extra stuff there too. I'm not calculating this myself, I have
it on good authority from some guys who are developing the product. I was quite
surprised how much overhead is required myself actually.
You don't have to use TCP/IP, and you don't need, or even want, lost
packet redundancy, at least not for streaming audio. If you need a
protocol at all, use something like UUCP.

If you don't account for lost packets what's going to happen to any lost audio data ? I'll
ask some more next time I talk to the guys about the protocol they're using.

Graham

Once their time has passed, they're irrelevant.


Which is why you have a receive buffer and there's latency between transmission and reception.

Graham