Subject: [AVTCORE] timing requirements for IDMS

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Nov 2011 13:48:00 +0800

The list seems very inconclusive about what our requirements are for timing for a audio beam steering solution. At one level I am getting the answer of a single sample. I am also seeing 1 micro second. I tried to look at the list traffic and saw one link that did not work. Can someone give me the fundamentals of what we are trying to do. How accurate a beam do we want, what frequencies and sort of phase array. From this seems like one can derive the required accuracy. 

The one link I found on list (http://www.cs.ucc.ie/~ianp/CS2511/HAP.html) does not seem to work. 

(BTW … glad to see the work on this. For my applications probably synchronization of 10 ms would be fine but I'm not trying to do beam steering).

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 14 Nov 2011 09:10:49 +0000

Hi Cullen,

Thanks for your mail and your interest in this topic. 

For an in-depth answer, I'm afraid I will have to depend on Kevin or Aidan (CC).

For a more practical answer: I think the main issue here is whether we need to be more accurate than 16 microseconds (as provided by a 32bit NTP-format timestamp) or not (in which case we would need to go for the 64bit timestamp). From what I understand from Kevin and Aidan, the level or accuracy you would need to have in these advanced use cases is right around the level of 1-8 microseconds. 

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: maandag 14 november 2011 6:48
To: IETF AVT WG
Subject: [AVTCORE] timing requirements for IDMS

(BTW ... glad to see the work on this. For my applications probably synchronization of 10 ms would be fine but I'm not trying to do beam steering).  

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: Kevin Gross <[email-masked]>
Date: Mon, 14 Nov 2011 03:08:05 -0700

Here's a fix for the broken link -
http://web.archive.org/web/20100410235208/http://www.cs.ucc.ie/~ianp/CS2511/HAP.html.
Look at the Localisation section.

knowing geometry of speaker and listener placement, the accuracy
requirements in terms of time can be readily derived from
requirements/capabilities in terms of angles.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Mon, Nov 14, 2011 at 2:10 AM, Brandenburg, R. (Ray) van <
[email-masked]> wrote:

> For a more practical answer: I think the main issue here is whether we
> need to be more accurate than 16 microseconds (as provided by a 32bit
> NTP-format timestamp) or not (in which case we would need to go for the
> 64bit timestamp). From what I understand from Kevin and Aidan, the level or
> accuracy you would need to have in these advanced use cases is right around
> the level of 1-8 microseconds.
>
> Ray
>
> The list seems very inconclusive about what our requirements are for
> timing for a audio beam steering solution. At one level I am getting the
> answer of a single sample. I am also seeing 1 micro second. I tried to look
> at the list traffic and saw one link that did not work. Can someone give me
> the fundamentals of what we are trying to do. How accurate a beam do we
> want, what frequencies and sort of phase array. From this seems like one
> can derive the required accuracy.
>
> (BTW ... glad to see the work on this. For my applications probably
> synchronization of 10 ms would be fine but I'm not trying to do beam
> steering).
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Nov 2011 18:36:55 +0800

> For an in-depth answer, I'm afraid I will have to depend on Kevin or Aidan (CC).

Thank you guys - look forward to learning more. 

> 
> For a more practical answer: I think the main issue here is whether we need to be more accurate than 16 microseconds (as provided by a 32bit NTP-format timestamp) or not (in which case we would need to go for the 64bit timestamp).

Fair enough. When I went to the mic today I was thinking about the use cases for synchronized playback which would not need resolution like this. Once people mentioned beam forming, I realized I had been thinking about the wrong level. That said, I think it would be good to provide a few sentences of text in the draft and explained what level was needed, and why. 

> From what I understand from Kevin and Aidan, the level or accuracy you would need to have in these advanced use cases is right around the level of 1-8 microseconds.
> 
> Ray
>

---

From: Kevin Gross <[email-masked]>
Date: Mon, 14 Nov 2011 20:27:35 -0700

I published detailed use
cases<https://docs.google.com/document/d/1ANYd-MkQUtJi5_B8uwOwfazB0p1Qmr6X6r85dsmUTgo/edit>to
the reflector a couple months ago. We did not include this material in
the draft. It sounds like it would be be helpful if we included some of it.

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Mon, Nov 14, 2011 at 3:36 AM, Cullen Jennings <[email-masked]> wrote:

> 64bit timestamp).
> Fair enough. When I went to the mic today I was thinking about the use
> cases for synchronized playback which would not need resolution like this.
> Once people mentioned beam forming, I realized I had been thinking about
> the wrong level. That said, I think it would be good to provide a few
> sentences of text in the draft and explained what level was needed, and why.
>
> > From what I understand from Kevin and Aidan, the level or accuracy you
> would need to have in these advanced use cases is right around the level of
> 1-8 microseconds.
> >
> > Ray
> >

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 18 Nov 2011 21:35:48 -0500

>> For a more practical answer: I think the main issue here is whether we need to be more accurate than 16 microseconds (as provided by a 32bit NTP-format timestamp) or not (in which case we would ne…

Here is a physicist's answer. The human auditory system is good to
about 0.1 radians, maybe 0.02 radians for sounds from straight ahead.
At 1 KHz, this is based on phase. At much higher frequencies, this is
based on intensity. Intensity interferometers don't depend  on phase,
so they don't really depend much on timing. This requirements will
thus be dominated by the demands at 1 KHz, where our auditory system
forms a phase interferometer. (This upper frequency phase limit is set
by the speed of sound and the distance between our ears, i.e., the
size of our heads.)

1 KHz is ~ 6000 radians of phase per second, so 0.1 radian is 1/60,000
of a second, or ~ 17 microseconds, and 0.02 radians is ~ 3
microseconds. So, I would recommend you support 64bit timestamps.

Regards
Marshall

---

From: Stephen Botzko <[email-masked]>
Date: Sat, 19 Nov 2011 12:58:03 +0800

Not sure if this is physics or neurophysiology.

In any event, using a "just noticeable difference" test, humans can hear
interaural time differences (ITD) in the 10-20 microsecond range.  There
are several studies on the subject, some are referenced here:
http://www.jneurosci.org/content/23/2/716.full.pdf

17 microsecond granularity is of course near the upper end of this range.
So a 64 bit timestamp seems appropriate, in order to ensure that the
synchronization error between the channels is below the limits of human
perception.

Stephen Botzko

On Sat, Nov 19, 2011 at 10:35 AM, Marshall Eubanks <
[email-masked]> wrote:

> >> The one link I found on list (
> http://www.cs.ucc.ie/~ianp/CS2511/HAP.html) does not seem to work.
> >>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 28 Nov 2011 13:44:44 -0700

Thanks Stephen, Marshall, and Kevin. Theses were the sort of answers I was looking for - I think it might be worth at least a sentence or two in the draft explaining beam forming with phrase arrayed speakers required accuracies approaching the low number of micro seconds.