I disagree, adding a low $ multi port Ethernet to one PC has got to be
cheaper than having multiple PC all with the music SW, disk space, and
CPU speed to accomplish the task. Using cheap available low $ Ethernet
available today will alway be cheaper than the latest and greatest just
developed standard. I could put 4 port Ethernet cards in every PC for
very few $ nowadays.
Regards Denis
Alexei Beliaev wrote:
It is good! We agree that accurate
time reference is required in the house infrastructure!
Now let's be careful about what we
assume when we speak about live performances. As for me, it is
not about studio installations or anything very much
professional. Professionals usually can afford expensive solutions, and
they certainly can use multiple network cards in dedicated computers on
isolated networks which are managed using special software. My case of live performance is about our kids
playing music together at home, and I believe that many people would
find this impractical to set up a special room for such activities
in their houses (at least if they had a choice). I also know that there
is a very large number of people who play music at home just for
pleasure so it would be too much if we say that each of them requires a
studio. Having a dedicated computer
with dedicated interface for musical applications is inconvenient but
unavoidable in today home music recording/playing. It is simple, but it can not be cheap, because
it is very specific and constraining.
Regards,
Alexei Beliaev
Gibson Labs
408-313-2665
-----
Original Message -----
Sent:
Tuesday, April 12, 2005 12:51 PM
Subject:
Re: [RE] Compatibility with 802 and why the study group is not yet a
task force
I don't necessarily agree, a live performance would not be part of the
house infrastructure, but in a studio or reserved room where traffic
from other sources would not be seen and/or be an issue. I know today
when I do live recordings I'm not backing up the PC or watching a video
from the PC at the same time or surfing the internet. If a simple
solution could answer all, then great! But if not, the home studio
market still pays more anyway, put 4 Ethernet ports in the PC one for
the instruments switch, one for the home network and one for each
Speaker. I thinks its still cheaper than the 20 plus 1/4 inch patch
cords I use today!
PS: It solves the delay and QOS issues as well.
I do agree that both the home infrastructure and the live performance
do require an accurate time reference. But now the problem is
different, so the solution can be much cheaper.
Regards Denis
Alexei Beliaev wrote:
Actually, it looks like the
message contains a bit of illustration to existing problems:
- The network delay is never 6%
(or any other certain/fixed/bounded value)
- When it comes to a solution
then it would be more convenient to have one that works for all of
mentioned applications (audio listening, live performances, gaming,
video watching, etc.). The are not so fundamentally different.
Regards,
Alexei Beliaev
Gibson Labs
408-313-2665
-----
Original Message -----
Sent:
Tuesday, April 12, 2005 7:25 AM
Subject:
Re: [RE] Compatibility with 802 and why the study group is not yet a
task force
I fully agree. We seem to be
focused on the solution before defining the problem. I would like for
us to work on a problem definition in Austin.
Regards,
Yoram.
Two last elements to add to the list that may help RE move forward.
1) Define the problem! All I hear is how the solution will fix it, but
when I see the latency diagram, the network only consists of less than
6% of the total delay. Why are we not focusing on the other 94% of the
path delay?
2) Once the problem is defined, break the problem into appropriate
classes like Audio Listening, Video Watching, Live Performances,
Gaming, etc. It may be that the solution for most of the classes is
already here, and the solution for a couple of the classes may need
features to be added in 802.3.
I also agree with Arthur, the RE study group should use the IEEE RE
reflector.
Regards Denis
Arthur Marris wrote:
Second attempt to get this
sent to the email list
Folks,
On reviewing the Yahoo mailing list
archive I saw an email asking why the compatibility with 802 criterion
failed to get the necessary 75% approval in the 802.3 closing plenary
session. In my view there are two reasons for this:
1) It was stated during the debate in the
closing plenary by a study group member that no changes to the MAC or
PHY may be necessary. If that is the case then what is the point of
doing an 802.3 project? You need to give the 802.3 working group some
idea of what it is that you want to do.
2) You failed to convince 802.1 that what
you are proposing is compatible with their switching specs. The
tutorial gave the impression that the purpose of the task force would
be to standardize a mooted Firewire switch architecture in 802.1. This
switch architecture requires a separate queue for RE traffic and is
required to deliver frames at precise time intervals. Predictably this
did not go down well in 802.1 and the 802.3 working group took notice
of this.
I also have the following observations to
make
i) To see RE through as an 802.3 project
you need to engage with the wider 802.3 working group. Using a Yahoo
mailing list rather than this one does not help. If you want to know
why people voted against the compatibility criterion ask on this
mailing list. The vote to set up the study group was 41 to 7 so there
is support for a task force and making changes to the 802.3 spec for
RE. Don't squander this good will.
ii) You need a chair who is experienced in
802.3 policy and procedures.
iii) You need to come up with a
quantitative requirement for jitter and relative latency and justify
it. I saw the figure of 10us mentioned on the Yahoo mailing list. This
is ridiculously tight. An 802.3 voter who is experienced in VOIP
pointed out to me that even 1ms is too tight when you consider that
sound only travels one foot in a millisecond. Once you have
this requirement nailed a lot else will fall into place.
iv) The sort of thing that would make sense
for a task force would be to develop a mechanism for measuring link
delay using MAC control frames so that time stamp information could be
accurately interpreted. This is within the scope of 802.3 and clearly
relevant to what you are trying to achieve with residential Ethernet.
Arthur.
--
Denis Beaudoin DMTS Texas Instruments dbeaudoin@ti.com 972-480-3277
--
Denis Beaudoin DMTS Texas Instruments dbeaudoin@ti.com 972-480-3277
--
Denis Beaudoin DMTS Texas Instruments dbeaudoin@ti.com 972-480-3277
|