Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[RE] Acknowledging contributions



I think an acknowledgement section that acknowledges that you have used input from the people and states clearly that doesn't necessarily mean they agree with the entire content and aren't responsible for the author's interpretation of their input is the usual way.

Regards,
Pat

-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG
[mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of David V James
Sent: Wednesday, 27 April, 2005 1:56 PM
To: STDS-802-3-RE@LISTSERV.IEEE.ORG
Subject: Re: [RE] Latencies through RE cables (better URL)


Kevin,

>> I find no fault with David's derivation of a 0.5ms network hop latency
                        ^^^^^^^
Actually, its Alexei that provided the slide (and
many of the clipart objects) from which DVJ created text.
Actually, in the fog of intense editing burnout, DVJ
messed up the first version before Alexei provided
the corrective proof-reading.

Unfortunately, its hard to give proper credit to each of
the contributors. It gets even harder on each revisions,
since the border line between the source and iterative
changes by reviewer groups becomes fuzzy over time...

Maybe I should include a list of contributors, with a
disclaimer that they assisted the document preparation,
although they may not agree with all of the cumulative
writing?

This might be a good topic for further discussion. How
can you give credit, without falsely or prematurely
implying concurrence on overall content? Any ideas?

Cheers,
DVJ
David V. James



>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of Gross, Kevin
>> Sent: Wednesday, April 27, 2005 11:32 AM
>> To: STDS-802-3-RE@LISTSERV.IEEE.ORG
>> Subject: Re: [RE] Latencies through RE cables (better URL)
>>
>>
>> I concur. I should have mentioned that I find no fault with David's
>> derivation of a 0.5ms network hop latency requirement from a 15ms overall
>> latency requirement.
>>
>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG] On
>> Behalf Of Alexei Beliaev
>> Sent: Wednesday, April 27, 2005 12:23 PM
>> To: STDS-802-3-RE@LISTSERV.IEEE.ORG
>> Subject: Re: [RE] Latencies through RE cables (better URL)
>>
>> I agree that 5 ms for processing delay in PC is a very
>> approximate number.
>> Nevertheless, people from both Cakewalk and Steinberg claimed in
>> personal
>> conversations on one of the latest AES shows that their software would
>> provide it.
>> As for the total delay budget, it looks to be well understood now that
>> shorter delays are better (especially if they come virtually for
>> free), and
>> RE SG states shorter delays in the list of objectives (250 usec
>> per hoc, 2
>> ms through the network). One of major points of my presentation
>> was that we
>> could not assume that the total delay budget would be spent on
>> the network
>> only.
>> Alexei Beliaev
>> Gibson Labs
>> 408-313-2665
>>
>> ----- Original Message -----
>> From: "Gross, Kevin" <kevin.gross@CIRRUS.COM>
>> To: <STDS-802-3-RE@LISTSERV.IEEE.ORG>
>> Sent: Wednesday, April 27, 2005 9:31 AM
>> Subject: Re: [RE] Latencies through RE cables (better URL)
>>
>>
>> > I've looked at the scenarios in the paper. I have a couple comments.
>> >
>> > 1/ No headphone scenarios are considered. A DJ or singer wearing
>> > headphones
>> > is the most critical case I'm aware of with respect to latency. Delays
>> > above
>> > 0.5ms are audible and, in many cases, objectionable in this
>> scenario. This
>> > sort of headphone monitoring is routinely used in home studio recording
>> > (section 1.3.2) and even by some geeky garage musicians
>> (section 1.3.3).
>> >
>> > 2/ I question whether a 5ms processing delay is achievable
>> through a PC as
>> > shown in figure 1.3. The PC architecture was not designed for real-time
>> > processing. Delay through a PC is certainly greater than 15ms and can
>> > reach
>> > 100ms and beyond. As such, some musicians find it unacceptable to run
>> > their
>> > monitors through the PC; they use external gear to bypass the PC during
>> > tracking. Others, baulk at the cost of the external gear, and learn to
>> > perform well despite the latency.
>> >
>> > -----Original Message-----
>> > From: owner-stds-802-3-re@IEEE.ORG
[mailto:owner-stds-802-3-re@IEEE.ORG]
> On
> Behalf Of David V James
> Sent: Tuesday, April 26, 2005 3:52 PM
> To: STDS-802-3-RE@LISTSERV.IEEE.ORG
> Subject: [RE] Latencies through RE cables (better URL)
>
> All,
>
> (The URL has been updated, after David Law
> provided a more universally accessible web page).
>
> Things seem to have been quiet for the last week.
> Perhaps I could stimulate some discussions on
> cable latencies?
>
> I believe Alexei's presentations have claimed that
> interactive latencies of 15ms are nearly audible.
>
> Since the link delays are only part of the delay
> equation, this has led some of us to believe that
> (worst case) per-hop latencies should not exceed
> 0.5ms. (This number is much more than the speed
> of light, since it includes buffer and conflict
> delays.)
>
> Is there any controversy with using this as a
> working per-hop maximum delay number?
>
> For background material on this topic, please
> reference pages 15-17 of the following
> working paper:
>
>  http://www.ieee802.org/3/re_study/material/index.html
>  (Thanks again to David Law for his quick posting!!)
>
> I have spent the last week accumulating content
> of various slide presentations into the above
> listed working paper. Hopefully this will be helpful
> when considering this and other issues.
>
> DVJ
> David V. James
>