Latency of SSR BRS renderer

2 views
Skip to first unread message

Hagen Wierstorf

unread,
Nov 9, 2016, 7:10:39 AM11/9/16
to SSR Mailingliste, Vera Erbes
Hi all.

A reviewer stated the following question regarding my usage of the BRS renderer
of the SSR for dynamic binaural synthesis:

"Were the HRTFs updated on every reading from the Fastrak (120 Hz)?
What is the overall head-to-HRTF latency? i.e. How long does it take for a head
motion to be reflected in updated HRTFs and audio?"

In my case I didn't connected the Fastrak directly to the SSR, but first to
Puredata, were its data stream is split into two and one of them is transferred to
the SSR, so I guess the actual Fastrak rate is then 60 Hz. So my first question
is:
1.) Does the SSR react to all of the head tracker input data and the actual used
update rate of the listener orientation was also 60 Hz inside the SSR?

My second question is regarding the overall latency:
2.) Is the overall latency then more or less determined by the audio block length of
Jack? If so, is it corresponding to a full block length, or half of it?

Thanks for your hints
/Hagen

Jens Ahrens

unread,
Nov 9, 2016, 7:59:48 AM11/9/16
to Hagen Wierstorf, SSR Mailingliste, Vera Erbes
Hi Hagen,

2016-11-09 13:10 GMT+01:00 Hagen Wierstorf <hagen.w...@posteo.de>:
Hi all.

A reviewer stated the following question regarding my usage of the BRS renderer
of the SSR for dynamic binaural synthesis:

"Were the HRTFs updated on every reading from the Fastrak (120 Hz)?
What is the overall head-to-HRTF latency? i.e. How long does it take for a head
motion to be reflected in updated HRTFs and audio?"

In my case I didn't connected the Fastrak directly to the SSR, but first to
Puredata, were its data stream is split into two and one of them is transferred to
the SSR, so I guess the actual Fastrak rate is then 60 Hz. So my first question
is:
1.) Does the SSR react to all of the head tracker input data and the actual used
update rate of the listener orientation was also 60 Hz inside the SSR?

It is such that the tracker keeps on sending position and orientation data that is written into the scene data class inside SSR. Whenever a new audio frame is to be processed, the renderer reads the current listener position and orientation data from the scene class and processes the entire audio frame with that In other words, the tracking data that was last to arrive prior to the beginning of the audio frame is the one that is being used.


My second question is regarding the overall latency:
2.) Is the overall latency then more or less determined by the audio block length of
Jack? If so, is it corresponding to a full block length, or half of it?

Yes, kind of. The frame length is a limiting factor. The audio processing part updates the listener position and orientation only once for every frame. Additional to that, JACK buffers the signal to avoid dropouts. That would typically be 2 or 3 frames more. Then, the sound card will do buffering, too. And so forth. The bottom line is that it's difficult to reliably anticipate the latency of a system.

Alexander Lindau did a study on the perception of latency in head-tracking: https://www2.ak.tu-berlin.de/~akgroup/ak_pub/2009/Lindau_2009_The_Perception_of_System_Latency_in_Dynamic_Binaural_Synthesis.pdf He ended up with measuring latency by hand. That is, he had a lever that measured when a movement was instigated. The latency was then measured as the time that evolves until the audio output changed. Obviously, there is a significant jitter on the latency depending on at what time relative to the beginning of a frame you pull the lever.

Greets,
Jens


--
You received this message because you are subscribed to the Google Groups "SoundScape Renderer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to SoundScapeRenderer+unsub...@googlegroups.com.
To post to this group, send email to SoundScapeRenderer@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/SoundScapeRenderer/20161109121037.rwtf6bysogjgxp5u%40audio.
For more options, visit https://groups.google.com/d/optout.

Hagen Wierstorf

unread,
Nov 9, 2016, 10:01:46 AM11/9/16
to SoundScape Renderer, hagen.w...@posteo.de, vera....@uni-rostock.de
Hi Jens

 

My second question is regarding the overall latency:
2.) Is the overall latency then more or less determined by the audio block length of
Jack? If so, is it corresponding to a full block length, or half of it?

Yes, kind of. The frame length is a limiting factor. The audio processing part updates the listener position and orientation only once for every frame. Additional to that, JACK buffers the signal to avoid dropouts. That would typically be 2 or 3 frames more. Then, the sound card will do buffering, too. And so forth. The bottom line is that it's difficult to reliably anticipate the latency of a system.

Alexander Lindau did a study on the perception of latency in head-tracking: https://www2.ak.tu-berlin.de/~akgroup/ak_pub/2009/Lindau_2009_The_Perception_of_System_Latency_in_Dynamic_Binaural_Synthesis.pdf He ended up with measuring latency by hand. That is, he had a lever that measured when a movement was instigated. The latency was then measured as the time that evolves until the audio output changed. Obviously, there is a significant jitter on the latency depending on at what time relative to the beginning of a frame you pull the lever.

OK, that seems to be fine. I used a block length of 1024 samples in Jack, corresponding to 23 ms. Others (http://www.aes.org/e-lib/browse.cfm?elib=8050) have found that for correct localization of virtual sources even a latency of 500 ms seems to be sufficient, so I guess I should be on the save side.

@Vera: if I remember correctly you have also tried to estimate the latency of a similar setup, did you perform some measurements?

/Hagen 

Jens Ahrens

unread,
Nov 9, 2016, 10:04:22 AM11/9/16
to Hagen Wierstorf, SoundScape Renderer, Hagen Wierstorf, Vera Erbes
Hi Hagen,

I just learned that the current multi-threaded incarnation of SSR is doing things slightly differently than back in the day. But the effect on the latency is just the same.

Greets,
Jens


--
You received this message because you are subscribed to the Google Groups "SoundScape Renderer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to SoundScapeRenderer+unsub...@googlegroups.com.
To post to this group, send email to SoundScapeRenderer@googlegroups.com.

vera.erbes

unread,
Nov 9, 2016, 10:11:57 AM11/9/16
to SoundScape Renderer, hagen.w...@posteo.de, vera....@uni-rostock.de


Am Mittwoch, 9. November 2016 16:01:46 UTC+1 schrieb Hagen Wierstorf:

@Vera: if I remember correctly you have also tried to estimate the latency of a similar setup, did you perform some measurements?


 
 No, I did not perform measurements. But I'm still interested in repeating an experiment for the SSR like Alex Lindau did in the paper Jens mentioned. Maybe if I find the time someday, or someone else does... ?

Kind regards,
Vera
Reply all
Reply to author
Forward
0 new messages