surprising latency

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

surprising latency

Nicolau Werneck
Greetings... This is my first post to this list.  I started using jack for some
weeks now, but only now I really started to get my hands dirty.

Right now  I'm making a program  to measure transfer  functions... I'm starting
measuring the loop between the line-out  and the line-in (with couple or jack -
RCA cables, plus a RCA-RCA gizmo)

I don't care much about the latency. 2bufs *1024 / 48ksps ~ 42.6ms is just fine
for me. But I want a stable Latency!!!... I don't want it to change!...

For example, with my PCI ound card,  I tried my program out (it used the Wiener
algorithm to find a FIR filter), and the result is this:

n   h[n]   x[n]   y[n]
-10 +0.004 -1.000 -1.000
 -9 +0.012 -1.000 -1.000
 -8 -0.036  1.000 -1.000
 -7 +0.002 -1.000 -1.000
 -6 -0.009 -1.000 -1.000
 -5 +0.033 -1.000 +1.000
 -4 +0.020 -1.000 +1.000
 -3 -0.006 -1.000 +1.000
 -2 -0.008 -1.000 +1.000
 -1 -0.021  1.000 +1.000
  0 -0.021  1.000 -0.950
  1 -0.037  1.000 +0.950
  2 +0.018  1.000 +0.950
  3 +0.591  0.863 -0.950
  4 +0.346 -0.707 -0.950
  5 +0.004  1.000 +0.950
  6 +0.005 -0.612 -0.950
  7 +0.000 -1.000 -0.950
  8 -0.004  1.000 -0.950
  9 -0.022 -1.000 +0.950

Notice down here. at position n=3, we  have a peak of h[n], which is the impule
response...

So, this  board is OK. removing  the 2048 latency  from the buffers, we  have a
latency of 3 sample,s that I believe mut com from the D/A and A/D chips...

But then I tried out an external Creative USB Sound Blast Audigy NX 2. I wanted
to ue it because  I'm going to record some stuff, and  this other internal card
of mine has  a terrible digital noise around 2kHz, and  I imagined the external
might have less noise. Plus it is an expansive device, gotta be better! :P

But then  I tried my program  out, only to find  that it seems  that the device
imposes a  much larger latency... And  rose, the number is  NOT STABLE!!! Every
time I  run the  program again, I  might get  a different latency,  which often
remains  the  same  until  I  stop  the program.   That's  the  reason  of  the
subject... Every  run of the  proram the system  surprises me with  a different
latency then I expected! :(

Has anybody ever seen anything like this???

Numbers span from about  150 to 250 samples...  First I imagined  it could be a
fixed 256 samples, a cute number,  but it's not...  Very frequently it's around
240, some times less, some times more.

I need a fixed latency!!!... It could be 797 samples, even 48000 samples!!... I
just need  it to  keep the same  (or at least  in a  small range). If  it keeps
changing, I won't know where to look at to do my calculations! :(

So, what I need  to know is: is it normal? Is it  something that happend in the
external  device, or  is  it fault  of  my computer,  or my  USB  bus? Would  a
different, newer  and more expansive  USB port make  a difference?... Can  I do
anything about it?... :/

Just when I  tough I was going to switch to  this newer, futuristic-looking USB
device, I get a  problem that was even worse then the  noise I had before! :(((
(plus, of course, the problem that I  needed to stop listening ot music all the
time)



I would be deeply thankful to any help... Good advices are worthy a candy! :)

thanks, cya...







--
Nicolau Werneck <[hidden email]>         9F99 25AB E47E 8724 2F71
http://cefala.org/~nwerneck                   EA40 DC23 42CE 6B76 B07F
"You shall know the truth, and the truth shall make you mad."
-- Aldous Huxley


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Jesse Chappell
On 6/8/07, Nicolau Leal Werneck <[hidden email]> wrote:

> I need a fixed latency!!!... It could be 797 samples, even 48000 samples!!... I
> just need  it to  keep the same  (or at least  in a  small range). If  it keeps
> changing, I won't know where to look at to do my calculations! :(
>
> So, what I need  to know is: is it normal? Is it  something that happend in the
> external  device, or  is  it fault  of  my computer,  or my  USB  bus? Would  a
> different, newer  and more expansive  USB port make  a difference?... Can  I do
> anything about it?... :/

This is normal for USB devices if you don't use carefully chosen
samplerates, buffersizes and buffer counts.   The USB bus runs on
timing based on millisec boundaries, thus you should try to specify
the parameters to give nice even millisec values.  The magic lies in
choosing 48000 sample rate, and *3* periods of power-of-2 buffers.
  eg:  256 * 3 / 48000.0 =  16 ms

Give that a try.

jlc

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Fons Adriaensen-2
In reply to this post by Nicolau Werneck
On Fri, Jun 08, 2007 at 10:02:54AM -0300, Nicolau Leal Werneck wrote:

> But then  I tried my program  out, only to find  that it seems  that the device
> imposes a  much larger latency... And  rose, the number is  NOT STABLE!!! Every
> time I  run the  program again, I  might get  a different latency,  which often
> remains  the  same  until  I  stop  the program.   That's  the  reason  of  the
> subject... Every  run of the  proram the system  surprises me with  a different
> latency then I expected! :(

That probably means there is something not fully OK with your program.

Try jdelay, it will show you the exact latency with sub-sample precision.

   <www.kokkinizita.net/linuxaudio/downloads>

--
FA

Follie! Follie! Delirio vano è questo !



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Fons Adriaensen-2
In reply to this post by Jesse Chappell
On Fri, Jun 08, 2007 at 09:14:12AM -0400, Jesse Chappell wrote:

> This is normal for USB devices if you don't use carefully chosen
> samplerates, buffersizes and buffer counts.   The USB bus runs on
> timing based on millisec boundaries, thus you should try to specify
> the parameters to give nice even millisec values.  The magic lies in
> choosing 48000 sample rate, and *3* periods of power-of-2 buffers.
>   eg:  256 * 3 / 48000.0 =  16 ms

Yes, using -n 3 will help with USB and allow smaller buffer sizes that
would bot work with -n 2. But assuming the card and driver are operating
normally, latency should be at least be constant until JACK is restarted.
Stopping and starting the app that measures it should not have any
effect as everything keeps running even without that app.

--
FA

Follie! Follie! Delirio vano è questo !



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Nicolau Werneck
In reply to this post by Fons Adriaensen-2

It worked!!... Thanks guys.

I  had tried  the  -n 3  before,  I found  by  Google, but  it  didn't work  at
first... Now I tried out  again more carefully, with multiple combinations, and
it worked for -n  3 -p 1024!...  Smaller buffer brings the  problem back, but I
believe it's linked to xruns happening.

But you said it  should be consistent through each run of  jackd... This mean I
should  always  measure  the  delay  in  my  programs  before  doing  my  other
measurements?

...And my program was ugly, I confess, but it wasn't completely wrong!!! ;) But
you can bet I'll savage jdelay to my project!! =)

thanks again, bye!


On 080607, 15:28, Fons Adriaensen wrote:

> On Fri, Jun 08, 2007 at 10:02:54AM -0300, Nicolau Leal Werneck wrote:
>
> > But then  I tried my program  out, only to find  that it seems  that the device
> > imposes a  much larger latency... And  rose, the number is  NOT STABLE!!! Every
> > time I  run the  program again, I  might get  a different latency,  which often
> > remains  the  same  until  I  stop  the program.   That's  the  reason  of  the
> > subject... Every  run of the  proram the system  surprises me with  a different
> > latency then I expected! :(
>
> That probably means there is something not fully OK with your program.
>
> Try jdelay, it will show you the exact latency with sub-sample precision.
>
>    <www.kokkinizita.net/linuxaudio/downloads>
>
> --
> FA
>
> Follie! Follie! Delirio vano è questo !
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel
--
Nicolau Werneck <[hidden email]>         9F99 25AB E47E 8724 2F71
http://cefala.org/~nwerneck                   EA40 DC23 42CE 6B76 B07F
"The great tragedy of science -- the slaying of a beautiful hypothesis by an ugly fact. "
-- Thomas Huxley


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Fons Adriaensen-2
On Fri, Jun 08, 2007 at 11:59:26AM -0300, Nicolau Leal Werneck wrote:

> But you said it  should be consistent through each run of  jackd... This mean I
> should  always  measure  the  delay  in  my  programs  before  doing  my  other
> measurements?

Latency must be stable as long as you don't restart the driver, and if it isn't,
as happened to you, that indicates there is a serious problem.

But this doesn't imply it should change each time you restart. If it does
that indicates a very crappy hardware or driver. I just checked 10 times
with my Edirol USB device, and the round-trip delay is as stable as it can
be, 1700.900 frames for -p 512 -n 3.

--
FA

Follie! Follie! Delirio vano è questo !



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Pieter Palmers
Fons Adriaensen wrote:

>On Fri, Jun 08, 2007 at 11:59:26AM -0300, Nicolau Leal Werneck wrote:
>
>  
>
>>But you said it  should be consistent through each run of  jackd... This mean I
>>should  always  measure  the  delay  in  my  programs  before  doing  my  other
>>measurements?
>>    
>>
>
>Latency must be stable as long as you don't restart the driver, and if it isn't,
>as happened to you, that indicates there is a serious problem.
>
>But this doesn't imply it should change each time you restart. If it does
>that indicates a very crappy hardware or driver. I just checked 10 times
>with my Edirol USB device, and the round-trip delay is as stable as it can
>be, 1700.900 frames for -p 512 -n 3.
>  
>
Note that freebob suffers from the latency-changes-when-restarted
phenomenon, so I guess it's a very crappy driver :).
It will be solved in FFADO.

Pieter

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Fons Adriaensen-2
On Sat, Jun 09, 2007 at 11:21:49AM +0200, Pieter Palmers wrote:

> >But this doesn't imply it should change each time you restart. If it does
> >that indicates a very crappy hardware or driver. I just checked 10 times
> >with my Edirol USB device, and the round-trip delay is as stable as it can
> >be, 1700.900 frames for -p 512 -n 3.
> >  
> >
> Note that freebob suffers from the latency-changes-when-restarted
> phenomenon, so I guess it's a very crappy driver :).

Or hardware, or both :-)

I hope you will agree that this shouldn't happen. If the hardware
and the driver start from a well-known state which I assume is always
the same (POR or soft reset), the timing relationships between all
streams should be well-defined.

Some applications (all the stuff I'll be working on in the foreseeable
future - WFS and HOA) depend on exactly defined relative delays between
all channels.

> It will be solved in FFADO.

How is this solved if devices are chained ? Sharing a word clock
is not enough - all devices have to start at the same time, or
at least with fixed relative delays.


--
FA

Follie! Follie! Delirio vano è questo !



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Pieter Palmers
Fons Adriaensen wrote:

>On Sat, Jun 09, 2007 at 11:21:49AM +0200, Pieter Palmers wrote:
>
>  
>
>>>But this doesn't imply it should change each time you restart. If it does
>>>that indicates a very crappy hardware or driver. I just checked 10 times
>>>with my Edirol USB device, and the round-trip delay is as stable as it can
>>>be, 1700.900 frames for -p 512 -n 3.
>>>
>>>
>>>      
>>>
>>Note that freebob suffers from the latency-changes-when-restarted
>>phenomenon, so I guess it's a very crappy driver :).
>>    
>>
>
>Or hardware, or both :-)
>
>I hope you will agree that this shouldn't happen. If the hardware
>and the driver start from a well-known state which I assume is always
>the same (POR or soft reset), the timing relationships between all
>streams should be well-defined.
>  
>
>Some applications (all the stuff I'll be working on in the foreseeable
>future - WFS and HOA) depend on exactly defined relative delays between
>all channels.
>  
>
Of course I do :). Not having phase alignment is a nightmare, even for
normal situations. Once you start recording what you play-back (i.e.
overdub) it is essential to have phase sync.

>>It will be solved in FFADO.
>>    
>>
>
>How is this solved if devices are chained ? Sharing a word clock
>is not enough - all devices have to start at the same time, or
>at least with fixed relative delays.
>  
>
For firewire devices it is a serious problem, notwithstanding the fact that the stream transport standard defines how this should be achieved. The reality however is that different vendors made a different interpretation of the standard...

The basic idea is the following:
1) Firewire has a clock that is globally available to all devices. One device generates it, all other devices slave to it. It runs at approx 24MHz and has a 128sec wraparound. In practice this should suffice as 'global time' since wraparounds are easy to detect and to compensate for. This clock is called the 'cycle timer' (CTR).

2) Every block of samples (4-32 samples/block) contains a timestamp that is equal to the value of the CTR at the moment a certain sample within the block should be played out. There are rules to determine which exact sample the timestamp refers to, but in practice it comes down to the first sample in the block. This fixes both absolute time and phase of the samples.

So what is the problem you might ask...

The spec is unclear about the exact meaning of the play-out time. The bottom line of this unclarity being the question whether you are allowed to add a certain amount of constant delay to this play-out time.
i.e.: is the moment you playout = TIMESTAMP or TIMESTAMP+FIXED_DELAY.

The problem becomes apparent if you s/FIXED_DELAY/VENDOR_CHOSEN_DELAY/:
playout = TIMESTAMP + VENDOR_CHOSEN_DELAY

or in the multiple device case:
playout1 = TIMESTAMP + VENDOR1_CHOSEN_DELAY
playout2 = TIMESTAMP + VENDOR2_CHOSEN_DELAY

The standard does not provide a means to retrieve VENDOR_CHOSEN_DELAY, so basically you define samples to be played out at the same time, but in reality they are not (if VENDOR1_CHOSEN_DELAY != VENDOR1_CHOSEN_DELAY).

There is a lot of discussion regarding the correct interpretation, with Yamaha (mLAN) and TCAT (DICE) saying "adding a FIXED_DELAY is NOT allowed", while BridgeCo (BeBoB) says it is allowed. I personally can read the standard both ways.

The reality is:
* Yamaha and TCAT have full-hardware implementations that have limited buffering capabilities. The 'full-hardware' makes that they are able to meet the strict timing needed for a 'no delay allowed' interpretation. The 'limited buffering' makes that they simply can't do the 'delay allowed' interpretation.
* BridgeCo uses a embedded software based approach with high buffering capabilities. They can't meet the no-extra-delay deadlines due to the software approach, but they can cope with larger delay variations.

This causes a fundamental incompatibility since Yamaha/TCAT devices won't ever be able to conform to the the BridgeCo interpretation of the standard, while BridgeCo can't conform to the Yamaha/TCAT interpretation.

How are we going to solve it?
The only solution is to compensate for the VENDOR_CHOSEN_DELAY in our handling/generation of timestamps. This means that we will have to find a way to measure this delay for all attached devices, and then account for it. The side effect of this will be that the slowest device will dominate the others.

Measuring the delay will require some user input, but only has to be done once for each setup. I was thinking of a procedure where the user would be asked to make connections between the inputs and outputs of the devices (including cross-device connections) and then adjust the delay until everything is in-phase.

The current FFADO implementation is able to ensure fixed delays between the different devices and restarts (or at least it should). It uses the timestamps for sync, leaving only the VENDOR_CHOSEN_DELAY as a fixed residue. It doesn't do the compensation yet, with the measurement being the major issue. This means that if you use identical devices with identical firmware versions FFADO will provide phase accuracy.

But this is still far off. First let's get the single-device scenario up and running.

Pieter

PS: note that this is an issue waiting to be discovered with the OSX driver too (at least I think so). It will combine "standard-compliant" devices (BeBoB, DICE with AV/C firmware, ECHO, ...) into one device, but there is no way it can cope with the delays without user interaction. Or they have extended the standards in such a way that they can figure out the vendor specific delay.

PPS: There seems to be another issue with phase accuracy on firewire devices and that seems to be that there is an uncertainty of 1 block (4-32 samples, depending on the samplerate) in the phase sync. It is reported for the OSX driver and I also had vendor confirmation on this. I haven't looked into it yet though.




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Fons Adriaensen-2
On Sat, Jun 09, 2007 at 01:05:53PM +0200, Pieter Palmers wrote:

> Fons Adriaensen wrote:
> >How is this solved if devices are chained ? Sharing a word clock
> >is not enough - all devices have to start at the same time, or
> >at least with fixed relative delays.
> >
> >
> For firewire devices it is a serious problem, notwithstanding the fact that
> the stream transport standard defines how this should be achieved. The
> reality however is that different vendors made a different interpretation
> of the standard...
>
> The basic idea is the following:
> ...

Thanks for a very clear intro to Firewire sample timing !

> This causes a fundamental incompatibility since Yamaha/TCAT devices won't
> ever be able to conform to the the BridgeCo interpretation of the standard,
> while BridgeCo can't conform to the Yamaha/TCAT interpretation

sospiri...
 
> How are we going to solve it?
> The only solution is to compensate for the VENDOR_CHOSEN_DELAY in our
> handling/generation of timestamps. This means that we will have to find a
> way to measure this delay for all attached devices, and then account for
> it. The side effect of this will be that the slowest device will dominate
> the others.

Looks like a good solution if you want exactly equal timing. But for many
applications it's still acceptable to have channels with different delays.
They will be measured and compensated for during installation (*) so as
long as they are fixed and you don't have to repeat the measurements each
time it's OK. It would be 'crappy' if you get random delays...

Are the timestamps supposed to include any delay in the ADC and analog
circuits, i.e. do they refer to the exact timing of the analog signals ?

(*) For WFS and similar you usually have a convolution on each output
channel, derived from a measured IR, to equalise the speaker and to
compensate for physical distance etc. This will absorb any timing deltas
iff they remain within limits.

--
FA

Follie! Follie! Delirio vano è questo !



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Pieter Palmers
Fons Adriaensen wrote:

> On Sat, Jun 09, 2007 at 01:05:53PM +0200, Pieter Palmers wrote:
>
>> Fons Adriaensen wrote:
>>> How is this solved if devices are chained ? Sharing a word clock
>>> is not enough - all devices have to start at the same time, or
>>> at least with fixed relative delays.
>>>
>>>
>> For firewire devices it is a serious problem, notwithstanding the fact that
>> the stream transport standard defines how this should be achieved. The
>> reality however is that different vendors made a different interpretation
>> of the standard...
>>
>> The basic idea is the following:
>> ...
>
> Thanks for a very clear intro to Firewire sample timing !
you're welcome :)
It took me 2 years to realize that the concept is actually rather
simple. Implementing this isn't that simple though.

>
>> This causes a fundamental incompatibility since Yamaha/TCAT devices won't
>> ever be able to conform to the the BridgeCo interpretation of the standard,
>> while BridgeCo can't conform to the Yamaha/TCAT interpretation
>
> sospiri...
that I had to babelfish, but indeed... another standard fails.

>> How are we going to solve it?
>> The only solution is to compensate for the VENDOR_CHOSEN_DELAY in our
>> handling/generation of timestamps. This means that we will have to find a
>> way to measure this delay for all attached devices, and then account for
>> it. The side effect of this will be that the slowest device will dominate
>> the others.
>
> Looks like a good solution if you want exactly equal timing. But for many
> applications it's still acceptable to have channels with different delays.
> They will be measured and compensated for during installation (*) so as
> long as they are fixed and you don't have to repeat the measurements each
> time it's OK. It would be 'crappy' if you get random delays...
>
> Are the timestamps supposed to include any delay in the ADC and analog
> circuits, i.e. do they refer to the exact timing of the analog signals ?

At risk of prosecution:
"... A receiver for professional use must have the capability of
presenting events at the time specified by the transmitter. ..."

I would understand it as including the ADC delays, but again it can be a
point of discussion. I would define the timestamp as the moment at which
the sample exits the environment controlled by the device manufacturer.
In other words it should include the interface delays.

While I'm at it anyway:
"... The transmitter shall add TRANSFER_DELAY to the quantized timing of
an event to construct the SYT. The TRANSER_DELAY value is initialized
with the DEFAULT_TRANSFER_DELAY value. For professional use,
TRANSFER_DELAY may be changed to achieve a shorter TRANSFER_DELAY value,
according to the Bus configuration. ..."

This is the section that causes the confusion: you should add a certain
delay (of which the default value is defined in the standard), but you
are allowed to change it in order to optimize the delay.

When rereading this section, I do have to say that the Yamaha/TCAT
interpretation makes more sense. The spec doesn't say that the RECEIVER
is allowed to add a delay to the presentation timestamp of a block it
receives.

The fact that the TRANSFER_DELAY may be changed does introduce a problem
anyway since it makes the round-trip latency device dependent. We don't
know how a device 'optimizes' the TRANSFER_DELAY part of the timestamps
it sends, so unless every device uses the same 'optimized' value this
introduces problems.

>
> (*) For WFS and similar you usually have a convolution on each output
> channel, derived from a measured IR, to equalise the speaker and to
> compensate for physical distance etc. This will absorb any timing deltas
> iff they remain within limits.
Usually the difference is rather small, sub-millisecond.

Pieter


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: surprising latency

Clemens Ladisch-2
In reply to this post by Nicolau Werneck
Nicolau Leal Werneck wrote:
> Right now  I'm making a program  to measure transfer  functions... I'm starting
> measuring the loop between the line-out  and the line-in (with couple or jack -
> RCA cables, plus a RCA-RCA gizmo)
> [...]
> But then I tried out an external Creative USB Sound Blast Audigy NX 2.
>
> But then  I tried my program  out, only to find  that it seems  that the device
> imposes a  much larger latency...

USB involves quite a lot of buffering because audio data is transferred
in one packet per frame (1 frame = 1 ms), where the time position of the
packet inside the frame can vary.  The driver has to buffer the data for
the next frame, the transmission takes one frame, and the device has to
buffer enough data to compensate for the up-to-1-ms jitter in the
incoming data packets.

> And  rose, the number is  NOT STABLE!!! Every
> time I  run the  program again, I  might get  a different latency,  which often
> remains  the  same  until  I  stop  the program.   That's  the  reason  of  the
> subject... Every  run of the  proram the system  surprises me with  a different
> latency then I expected! :(
>
> So, what I need  to know is: is it normal?

For the Audigy 2 NX, yes.

> Is it something that happend in the external device, or is it fault of
> my computer, or my USB bus?

All of them. :-)

Unlike most other USB audio devices, the Audigy 2 NX runs in
asynchronous mode, i.e., the device does not use the USB clock but has
its own sample clock, measures the difference between its own clock and
the USB clock, and then tells the computer how much data it wants to
receive in each frame.

This means that things like "-n 3" have no effect because the actual
sample rate, relative to the USB clock, will be somewhat different from
the desired sample rate.  (Look into /proc/asound/card*/stream0.)

The latency depends on how much the device wants its buffer to be
filled, and this probably depends on the phase difference between the
device's clock and the USB clock when the stream is started, i.e., it's
somewhat random.

> Would a different, newer and more expansive USB port make a difference?

No.  You could try any other USB audio device.


HTH
Clemens

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel