Documentation query?

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

Documentation query?

Ed Wildgoose-2
Hi, according to:
    http://jackaudio.org/files/docs/html/statistics_8h.html

The function jack_get_xrun_delayed_usecs is defined in <jack/types.h>, but on my Jack1 0.118 system I find it in jack/statistics.h

Is this just a Jack1 vs Jack2 thing or a typo?

Thanks

Ed W

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Documentation query?

Paul Davis
On Mon, Apr 19, 2010 at 4:14 PM, Ed W <[hidden email]> wrote:
> Hi, according to:
>     http://jackaudio.org/files/docs/html/statistics_8h.html
>
> The function jack_get_xrun_delayed_usecs is defined in <jack/types.h>, but
> on my Jack1 0.118 system I find it in jack/statistics.h

the statistics API is basically dead, and should be removed from the
docs if not the source. it is not useful for anyone. there are MUCH
MUCH better ways of measuring the sorts of things that this was
intended to cover. they didn't exist 5-6 years ago when this stuff was
implemented.

> Is this just a Jack1 vs Jack2 thing or a typo?

both, sort of.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Documentation query?

Ed Wildgoose-2
On 20/04/2010 00:27, Paul Davis wrote:
On Mon, Apr 19, 2010 at 4:14 PM, Ed W [hidden email] wrote:
  
Hi, according to:
    http://jackaudio.org/files/docs/html/statistics_8h.html

The function jack_get_xrun_delayed_usecs is defined in <jack/types.h>, but
on my Jack1 0.118 system I find it in jack/statistics.h
    
the statistics API is basically dead, and should be removed from the
docs if not the source. it is not useful for anyone. there are MUCH
MUCH better ways of measuring the sorts of things that this was
intended to cover. they didn't exist 5-6 years ago when this stuff was
implemented.

  

Thanks - what I wanted to implement was that in the case that an xrun occured then I wanted to measure how many fragments were missed (hopefully only one!) and this info would then be used on the next callback to skip over some data so that the audio would continue playing at the same point as if the xrun never happened

So my assumption is:
- After an xrun occurs then the callback interval remains the same, ie if we have a 10ms callback period and suffer a 1ms xrun, then we missed one whole fragment and the next callback will be 9ms later?  Perhaps someone could confirm this is the case at least using Alsa? (ie the card is not reset after an xrun, but continues eating samples at the same periodicity?)

Therefore I setup my xrun callback and in that callback I call " jack_get_xrun_delayed_usecs" to get the delay.  I then calculate how many whole fragments have been missed (rounded up).  Does this sound correct?

Can anyone confirm this is the correct way to achieve the desired result?  In particular does the audio device get reset/restarted on an xrun (ie callback interval is altered)?  Is there another function I should be using if statistics.h is dead?  ie what are these "MUCH better" ways?

Basically I just want a dropout to be a dropout and for the audio when it comes back to be at roughly the same position it would have been had there been no dropout?

Thanks

Ed W

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Documentation query?

Paul Davis
On Tue, Apr 20, 2010 at 9:26 AM, Ed W <[hidden email]> wrote:
> Thanks - what I wanted to implement was that in the case that an xrun
> occured then I wanted to measure how many fragments were missed (hopefully
> only one!) and this info would then be used on the next callback to skip
> over some data so that the audio would continue playing at the same point as
> if the xrun never happened

JACK won't let you do this.

> Therefore I setup my xrun callback and in that callback I call "
> jack_get_xrun_delayed_usecs" to get the delay.  I then calculate how many
> whole fragments have been missed (rounded up).  Does this sound correct?

No. You can't do it. JACK's xrun handling doesn't remotely attempt to
be time bounded. There is no way for you to know with any accuracy how
much time has passed. And nor should you, really. If you want that
kind of behaviour, you probably don't want to be using JACK. Your
app's job as a JACK client is to do what what its asked to do (process
data, set transport state, provide time information, and so forth).
Reasoning about what is happening "under the hood" will only lead to
disappointment.

--p
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Documentation query?

Fons Adriaensen-2
On Tue, Apr 20, 2010 at 09:36:46AM -0400, Paul Davis wrote:

> On Tue, Apr 20, 2010 at 9:26 AM, Ed W <[hidden email]> wrote:
> > Thanks - what I wanted to implement was that in the case that an xrun
> > occured then I wanted to measure how many fragments were missed (hopefully
> > only one!) and this info would then be used on the next callback to skip
> > over some data so that the audio would continue playing at the same point as
> > if the xrun never happened
>
> JACK won't let you do this.

First I'd say this is a very legitimate question, and
Jack *will* let you find out, modulo one problem.
 
In each process callback, get the value

t = jack_last_frame_time()

and compare this to the previous one.

This is Jack's 'best estimate' of the time when
the current cycle started, expressed in frames,
and with an arbitrary initial value (so only
differences have any meaning).

If everything runs normally, this will increment
in steps of period_size. Small deviations from
this value are possible, as the time is measured
by Jack and not by the driver, and there will be
a small variation in scheduling latency. Jack has
code to filter this jitter, but small deviations
from the expected difference are still possible.

If the difference of t and it previous value is
significantly different from the period size this
indicates that some extra time has passed.

Since the time scale is frames, it's trivial to
find the number of samples to skip:

skip = t - previous_t - period_size

provided that value is not close to zero.

Regarding the 'modulo one problem': there must be
a bug somewhere in the code code dealing with this
as _sometimes_, in _some_ circumstances,
jack_last_frame_time() will return the *same* value
in two consecutive process callbacks, which clearly
must be wrong. I guess that if you just ignore this
(it would mean you have to 'rewind' one period rather
than skip some frames), things could work.

Ciao,


--
FA

O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Documentation query?

Ed Wildgoose-2
In reply to this post by Paul Davis
On 20/04/2010 14:36, Paul Davis wrote:

> On Tue, Apr 20, 2010 at 9:26 AM, Ed W<[hidden email]>  wrote:
>    
>> Thanks - what I wanted to implement was that in the case that an xrun
>> occured then I wanted to measure how many fragments were missed (hopefully
>> only one!) and this info would then be used on the next callback to skip
>> over some data so that the audio would continue playing at the same point as
>> if the xrun never happened
>>      
> JACK won't let you do this.
>    

I'm not quite sure what you mean?  It's not something that Jack has any
say in, nor can prevent me doing, so I probably mis-described the problem?

>> Therefore I setup my xrun callback and in that callback I call "
>> jack_get_xrun_delayed_usecs" to get the delay.  I then calculate how many
>> whole fragments have been missed (rounded up).  Does this sound correct?
>>      
> No. You can't do it. JACK's xrun handling doesn't remotely attempt to
> be time bounded. There is no way for you to know with any accuracy how
> much time has passed.

At risk of asking the obvious - what is the
"jack_get_xrun_delayed_usecs" call for and what about the statistics
that Jack outputs to the log files (along the lines of "xrun of at least
Xms")?

I could simply note the time the callback last fired and estimate it
from that I guess?

> And nor should you, really. If you want that
> kind of behaviour, you probably don't want to be using JACK. Your
> app's job as a JACK client is to do what what its asked to do (process
> data, set transport state, provide time information, and so forth).
> Reasoning about what is happening "under the hood" will only lead to
> disappointment.
>    

I don't want to bring up all that last debate again, I just happen to
like coding to cover all eventualities.  In the worst case event that
some overrun occurs I am coding up what should happen in that event...
It can happen, so I'm planning to deal with that eventuality...

Actually, on an related note I bought a couple of books on Haskell as
some "light reading" - not something I have looked at for many years
since I covered Miranda at uni.  However, it's really very interesting
picking it up now and I have to say you almost immediately start to
write your code with preconditions and postconditions in mind and almost
start coding for all the failure conditions before you code for the
success conditions...

Have a read here:
     http://learnyouahaskell.com
Hopefully I will then get fewer complaints about wanting to code for the
unexpected cases as well as the normal situation!

Cheers

Ed W
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Documentation query?

Paul Davis
On Tue, Apr 20, 2010 at 11:38 AM, Ed W <[hidden email]> wrote:
> I'm not quite sure what you mean?  It's not something that Jack has any say
> in, nor can prevent me doing, so I probably mis-described the problem?

there is no way for you to determine the number of samples that have
elapsed on the audio interface sample clock, especially since there is
every chance that it has been stopped and restarted.

> At risk of asking the obvious - what is the "jack_get_xrun_delayed_usecs"
> call for and what about the statistics that Jack outputs to the log files
> (along the lines of "xrun of at least Xms")?

this simply reflects the duration of the xrun as reported by the
backend/driver. it doesn't reflect the entire delay that will be
incurred.

> I could simply note the time the callback last fired and estimate it from
> that I guess?

that will only provide a duration based on the system clock. not to
mention that technically, querying the system time from the process
callback is illegal.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Documentation query?

Paul Davis
In reply to this post by Fons Adriaensen-2
On Tue, Apr 20, 2010 at 11:06 AM,  <[hidden email]> wrote:

> On Tue, Apr 20, 2010 at 09:36:46AM -0400, Paul Davis wrote:
>
>> On Tue, Apr 20, 2010 at 9:26 AM, Ed W <[hidden email]> wrote:
>> > Thanks - what I wanted to implement was that in the case that an xrun
>> > occured then I wanted to measure how many fragments were missed (hopefully
>> > only one!) and this info would then be used on the next callback to skip
>> > over some data so that the audio would continue playing at the same point as
>> > if the xrun never happened
>>
>> JACK won't let you do this.
>
> First I'd say this is a very legitimate question, and
> Jack *will* let you find out, modulo one problem.

fons - if there is a xrun, there is every chance that the backend
stopped and restarted the device. jack frame times are not valid for
comparisons across such events.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Documentation query?

Fons Adriaensen-2
On Tue, Apr 20, 2010 at 11:46:01AM -0400, Paul Davis wrote:

> fons - if there is a xrun, there is every chance that the backend
> stopped and restarted the device. jack frame times are not valid for
> comparisons across such events.

It works in case the delay is due to the engine skipping
some cycles. You are right saying it doesn't work in case
of an xrun in the backend.

But this case could be covered easily as all required
information is avaiable - it is just a matter of correct
initialisation, using the available wakeup times to
correct the frame_time. Since this is quite obvious I
just assumed it was being done. Looking at this init
code I suspect there are some problems there anyway,
which may also explain the repeated value seen sometimes.

Note that if a client implements its own DLL (as does
Supercollider to dispatch timed OSC commands), the
assumption is that frame_times are corrected after
an xrun. Not doing this would 'kick' a big error
into the client's DLL, and it would need considerable
time to recover (it will, but that could take several
seconds).

The alternative to correcting the frame time after an
xrun would be to make the cycle wakeup time (usecs)
available to clients.
 
Ciao,

--
FA

O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org