22 Dec
2009
22 Dec
'09
5:05 p.m.
Hi,
I had a thought that maybe the network sound card should not be using
ethernet but instead wireless 802.11n.
The ralink rt2870 chipset is well supported at full 300Mb/s on Linux and
has open source drivers.
I think this would open up a lot of opportunities with a wireless sound
card.
I'm not sure how many are on the market right now but I haven't heard of
any yet so there is a big opportunity there to fill a gap.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
22 Dec
22 Dec
6:40 p.m.
Patrick Shirkey wrote:
Hi,
I had a thought that maybe the network sound card should not be using
ethernet but instead wireless 802.11n.
The ralink rt2870 chipset is well supported at full 300Mb/s on Linux and
has open source drivers.
I think this would open up a lot of opportunities with a wireless sound
card.
I'm not sure how many are on the market right now but I haven't heard of
any yet so there is a big opportunity there to fill a gap.
low latency audio over wireless is fundamentally impossible.
it's a shared medium, pretty much like thicknet or any other hub or bus
network. if two endpoints ever send at the same time (and they will),
the packets will clash and trigger resends after a non-deterministic
delay (so as to avoid endless re-clashing if two endpoints happen to be
"in sync").
the only thing that would work over wireless is heavily-buffered media
center stuff for consumers, because nobody cares if there's half a
second delay between your pressing play and the start of the movie.
the only way to make low latency streaming work is to use the link
uni-directionally (i.e. there's only ever one sender per allocated
channel) and to shoot everybody on sight who looks like they might have
any other wireless devices on them. especially the latter might prove
difficult, since it's a non-technical problem with social and legal
implications.
6:43 p.m.
2009/12/22 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
the only way to make low latency streaming work is to
use the link
uni-directionally (i.e. there's only ever one sender per allocated
channel) and to shoot everybody on sight who looks like they might have
any other wireless devices on them. especially the latter might prove
difficult, since it's a non-technical problem with social and legal
implications.
open-source software is a harsh mistress.
--
Josh Lawrence
http://www.hardbop200.com
23 Dec
23 Dec
4:14 a.m.
On 12/23/2009 09:40 AM, Jörn Nettingsmeier wrote:
Patrick Shirkey wrote:
So there's absolutely no way that a keyboard, pc, mixer, speaker set
transferring data over 802.11n could be made to work?
For example in a home studio setting...
Patrick Shirkey
Boost Hardware Ltd
Hi,
I had a thought that maybe the network sound card should not be using
ethernet but instead wireless 802.11n.
The ralink rt2870 chipset is well supported at full 300Mb/s on Linux and
has open source drivers.
I think this would open up a lot of opportunities with a wireless sound
card.
I'm not sure how many are on the market right now but I haven't heard of
any yet so there is a big opportunity there to fill a gap.
low latency audio over wireless is fundamentally impossible.
it's a shared medium, pretty much like thicknet or any other hub or bus
network. if two endpoints ever send at the same time (and they will),
the packets will clash and trigger resends after a non-deterministic
delay (so as to avoid endless re-clashing if two endpoints happen to be
"in sync").
the only thing that would work over wireless is heavily-buffered media
center stuff for consumers, because nobody cares if there's half a
second delay between your pressing play and the start of the movie.
5:10 a.m.
On Wednesday 23 December 2009 09:12:24 Patrick Shirkey wrote:
On 12/23/2009 09:40 AM, Jörn Nettingsmeier wrote:
There is no way to make it work with guaranteed low latency. You need somewhat
low latencies to play the keyboard to other music. And you need it guaranteed
unless you always record xruns and gaps as part of your musical experience...
And even then its wireless and using a frequency-range used by almost all
other people around you. Just count the wireless networks in your flat provided
you live in a flat with other people living upstairs/downstairs/next to you.
And then try to get a fast, non-interrupted stream (latency about 20ms or
shorter for real playing). And then remember Jörn in that it might be illegal
to shoot your neighbours...
Have fun,
Arnold
Patrick Shirkey wrote:
So there's absolutely no way that a keyboard, pc, mixer, speaker set
transferring data over 802.11n could be made to work?
For example in a home studio setting... I had a thought that maybe the network sound card
should not be using
ethernet but instead wireless 802.11n.
The ralink rt2870 chipset is well supported at full 300Mb/s on Linux and
has open source drivers.
I think this would open up a lot of opportunities with a wireless sound
card.
I'm not sure how many are on the market right now but I haven't heard of
any yet so there is a big opportunity there to fill a gap.
low latency audio over wireless is fundamentally impossible.
it's a shared medium, pretty much like thicknet or any other hub or bus
network. if two endpoints ever send at the same time (and they will),
the packets will clash and trigger resends after a non-deterministic
delay (so as to avoid endless re-clashing if two endpoints happen to be
"in sync").
the only thing that would work over wireless is heavily-buffered media
center stuff for consumers, because nobody cares if there's half a
second delay between your pressing play and the start of the movie. 
6:54 p.m.
On 12/23/2009 08:08 PM, Arnold Krille wrote:
On Wednesday 23 December 2009 09:12:24 Patrick Shirkey
wrote:
So the issue is with other streams being picked up by the receiver which
affects latency by increasing collisions?
Would this still be a problem on a secured connection? Surely the
receiver would ignore all data that is not being transmitted over the
secured access point?
Does anyone have an idea of how to work out the actual latency for a
wifi packet at 300Mb/s?
If we are talking about a studio setup with devices no further than 2
meters distance from each other that should aloow sub 20ms send/receive.
The bottle neck appears to be the chip and the code that manages the
transmit/receive process.
Patrick Shirkey
Boost Hardware Ltd
On 12/23/2009 09:40 AM, Jörn Nettingsmeier
wrote:
There is no way to make it work with guaranteed low latency. You need
somewhat
low latencies to play the keyboard to other music. And you need it guaranteed
unless you always record xruns and gaps as part of your musical experience...
And even then its wireless and using a frequency-range used by almost all
other people around you. Just count the wireless networks in your flat provided
you live in a flat with other people living upstairs/downstairs/next to you.
And then try to get a fast, non-interrupted stream (latency about 20ms or
shorter for real playing).
Patrick Shirkey wrote:
So there's absolutely no way that a keyboard, pc, mixer, speaker set
transferring data over 802.11n could be made to work?
For example in a home studio setting...
I had a thought that maybe the network sound card
should not be using
ethernet but instead wireless 802.11n.
The ralink rt2870 chipset is well supported at full 300Mb/s on Linux and
has open source drivers.
I think this would open up a lot of opportunities with a wireless sound
card.
I'm not sure how many are on the market right now but I haven't heard of
any yet so there is a big opportunity there to fill a gap.
low latency audio over wireless is fundamentally impossible.
it's a shared medium, pretty much like thicknet or any other hub or bus
network. if two endpoints ever send at the same time (and they will),
the packets will clash and trigger resends after a non-deterministic
delay (so as to avoid endless re-clashing if two endpoints happen to be
"in sync").
the only thing that would work over wireless is heavily-buffered media
center stuff for consumers, because nobody cares if there's half a
second delay between your pressing play and the start of the movie.
8:33 p.m.
Hi,
On Wednesday 23 December 2009 23:52:46 Patrick Shirkey wrote:
On 12/23/2009 08:08 PM, Arnold Krille wrote:
No, the problem is one or two layers deeper in the stack. We are talking wifi
here. No matter if there is only two devices on that network or a secure
connection, its still wireless transmission over radio frequencies in the 2GHz
range. Which is per se much more affected by any disturbance then a dedicated
cable is. Every mobile phone, every blue-tooth device, every neighbours
network, every iron in your ceiling will influence this. And not only with a
constant background-noise in your frequency range, but also with momentary
scrambling and such stuff. So in the layers you can not (easily) control by
software there is already lots of resending and rescheduling of packets. And
all these introduce uncertainties and latencies you don't want in your audio
transmission. Unless you can do with 100ms latency and more...
There is no way to make it work with guaranteed
low latency. You need
somewhat low latencies to play the keyboard to other music. And you need
it guaranteed unless you always record xruns and gaps as part of your
musical experience...
And even then its wireless and using a frequency-range used by almost all
other people around you. Just count the wireless networks in your flat
provided you live in a flat with other people living
upstairs/downstairs/next to you. And then try to get a fast,
non-interrupted stream (latency about 20ms or shorter for real playing).
So the
issue is with other streams being picked up by the receiver which
affects latency by increasing collisions?
Would this still be a problem on a secured connection? Surely the
receiver would ignore all data that is not being transmitted over the
secured access point? Does anyone have an idea of how to work out the actual
latency for a
wifi packet at 300Mb/s?
The data-rate is not important. What is important is the struggle you do to
get a payload packet out and the reception acknowledged. Wifi is very versatile
and allows usage (almost) everywhere. But you pay a high price in
predictability and latency.
Heck, even the wireless microphones struggle with problems and these "just"
send some analogue data. While digital is simpler in that its only zero or
one, its actually lots more complex on getting data out reliably.
If we are talking about a studio setup with devices no
further than 2
meters distance from each other that should aloow sub 20ms send/receive.
The bottle neck appears to be the chip and the code that manages the
transmit/receive process.
No, the bottle-neck is your neighbours accessing google and facebook via wifi
disturbing your signal momentarily producing gaps and xruns. And the only way
around it is using an area where there are no neighbours.
Once the stream is stable and reliable, it will easily go below 20ms latency.
But getting the stream to be reliable is already complicated with things like
firewire (which has isochronous channels for exactly this purpose) and its more
complicated with usb (which has a master telling the clients when to send
bigger payloads to not disturb the other bus-members). Ask the jack-over-udp
guys how difficult it is to create such stream reliably over tcp-ip network. And
they take lost packets into account (which means an xrun) and advise you to
use it on dedicated networks if you want more the the immediate experience...
If jacknet over wifi fills your needs, use it. But if it doesn't don't blame it
on its developers, blame it on the underlying network (-technology) used.
Have fun,
Arnold
8:49 p.m.
On 12/24/2009 11:31 AM, Arnold Krille wrote:
While in Korea I was on a cdma network and the voice quality and signal
quality/coverage was a factor of 10 times better than my experience with
gsm networks in other countries.
This part is what I was expecting.
Hi,
On Wednesday 23 December 2009 23:52:46 Patrick Shirkey wrote:
This is good analysis. Thanks for taking the time.
Is that number 100ms a real number or just an estimate?
Also in terms of audio quality it sounds like an issue similar to the
difference between vinyl and mp3 yet we all know which format is winning
the sales battle.
On 12/23/2009 08:08 PM, Arnold Krille wrote:
No, the problem is one or two layers deeper in the stack. We are talking
wifi
here. No matter if there is only two devices on that network or a secure
connection, its still wireless transmission over radio frequencies in the 2GHz
range. Which is per se much more affected by any disturbance then a dedicated
cable is. Every mobile phone, every blue-tooth device, every neighbours
network, every iron in your ceiling will influence this. And not only with a
constant background-noise in your frequency range, but also with momentary
scrambling and such stuff. So in the layers you can not (easily) control by
software there is already lots of resending and rescheduling of packets. And
all these introduce uncertainties and latencies you don't want in your audio
transmission. Unless you can do with 100ms latency and more...
There is no way to make it work with guaranteed
low latency. You need
somewhat low latencies to play the keyboard to other music. And you need
it guaranteed unless you always record xruns and gaps as part of your
musical experience...
And even then its wireless and using a frequency-range used by almost all
other people around you. Just count the wireless networks in your flat
provided you live in a flat with other people living
upstairs/downstairs/next to you. And then try to get a fast,
non-interrupted stream (latency about 20ms or shorter for real playing).
So the issue is with other streams being picked up by the receiver which
affects latency by increasing collisions?
Would this still be a problem on a secured connection? Surely the
receiver would ignore all data that is not being transmitted over the
secured access point?
Does anyone
have an idea of how to work out the actual latency for a
wifi packet at 300Mb/s?
The data-rate is not important. What is important is the struggle you do to
get a payload packet out and the reception acknowledged. Wifi is very versatile
and allows usage (almost) everywhere. But you pay a high price in
predictability and latency.
Heck, even the wireless microphones struggle with problems and these "just"
send some analogue data. While digital is simpler in that its only zero or
one, its actually lots more complex on getting data out reliably.
If we are
talking about a studio setup with devices no further than 2
meters distance from each other that should aloow sub 20ms send/receive.
The bottle neck appears to be the chip and the code that manages the
transmit/receive process.
No, the bottle-neck is your neighbours accessing google and facebook via
wifi
disturbing your signal momentarily producing gaps and xruns. And the only way
around it is using an area where there are no neighbours.
Once the stream is stable and reliable, it will easily go below 20ms latency.
But getting the stream to be reliable is already
complicated with things like
firewire (which has isochronous channels for exactly this purpose) and its more
complicated with usb (which has a master telling the clients when to send
bigger payloads to not disturb the other bus-members). Ask the jack-over-udp
guys how difficult it is to create such stream reliably over tcp-ip network. And
they take lost packets into account (which means an xrun) and advise you to
use it on dedicated networks if you want more the the immediate experience...
In this case are we comparing a network located over large distances
with internet nodes in between or a couple of computers sitting within a
couple of meters of each other?
If jacknet over wifi fills your needs, use it. But if
it doesn't don't blame it
on its developers, blame it on the underlying network (-technology) used.
Absolutely.
Patrick Shirkey
Boost Hardware Ltd
24 Dec
24 Dec
6:02 a.m.
Hi,
On Thursday 24 December 2009 01:48:14 Patrick Shirkey wrote:
Comparing local wired network and local wifi...
Have fun,
Arnold
On 12/24/2009 11:31 AM, Arnold Krille wrote:
I was once taught that a good estimate for an error is better then a bad
calculation. This number is a guess from my understanding and experience of
networks and the osi layers...
On Wednesday 23 December 2009 23:52:46 Patrick
Shirkey wrote:
This is good analysis. Thanks for taking the time.
Is that number 100ms a real number or just an estimate? So the issue is with other streams being picked
up by the receiver which
affects latency by increasing collisions?
Would this still be a problem on a secured connection? Surely the
receiver would ignore all data that is not being transmitted over the
secured access point?
No, the problem is one or two layers deeper in the stack. We
are talking
wifi here. No matter if there is only two devices on that network or a
secure connection, its still wireless transmission over radio frequencies
in the 2GHz range. Which is per se much more affected by any disturbance
then a dedicated cable is. Every mobile phone, every blue-tooth device,
every neighbours network, every iron in your ceiling will influence this.
And not only with a constant background-noise in your frequency range,
but also with momentary scrambling and such stuff. So in the layers you
can not (easily) control by software there is already lots of resending
and rescheduling of packets. And all these introduce uncertainties and
latencies you don't want in your audio transmission. Unless you can do
with 100ms latency and more... But getting
the stream to be reliable is already complicated with things
like firewire (which has isochronous channels for exactly this purpose)
and its more complicated with usb (which has a master telling the clients
when to send bigger payloads to not disturb the other bus-members). Ask
the jack-over-udp guys how difficult it is to create such stream reliably
over tcp-ip network. And they take lost packets into account (which means
an xrun) and advise you to use it on dedicated networks if you want more
the the immediate experience...
In this case are we comparing a network located
over large distances
with internet nodes in between or a couple of computers sitting within a
couple of meters of each other?
5443
days inactive
5445
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
5 participants
participants (5)
-
Arnold Krille -
Josh Lawrence -
Jörn Nettingsmeier -
Patrick Shirkey -
Paul Davis