[Jack-Devel] fractional frame rates for alsa_in and alsa_out

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

[Jack-Devel] fractional frame rates for alsa_in and alsa_out

Markus Grabner
        Hi!

A while ago I initiated work on a Linux driver for Line6 devices (now under sound/usb/line6 in the Linux kernel tree). Some of these devices have weird sample rates (39062.5Hz, derived from the 10MHz USB clock divided by 256). The alsa_in and alsa_out jack clients are convenient tools to use such Line6 devices together with more standardized hardware operating at, e.g., 48kHz. However, alsa_in only supports integer sample rates, and even after a couple of minutes, alsa_in doesn't detect the correct resampling factor 1.2288 (48000/39062.5), but still reports the initial approximated value 1.228816 (48000/39062). Admittedly, the error isn't too big, but is larger than the error of high-quality crystal oscillators. And, after all, why use an approximation if we know better?

I modified alsa_in and alsa_out such that they accept a sample rate in floating point format (command line option "-r") and query the fractional sample rate from the ALSA driver to compute the initial estimation of the resampling factor (see attached patch).

What do you think about this patch?

        Kind regards,
                Markus

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

0001-using-fractional-sample-rate.patch (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fractional frame rates for alsa_in and alsa_out

Fons Adriaensen-3
On Mon, Jun 13, 2016 at 12:04:30AM +0200, Markus Grabner wrote:

> A while ago I initiated work on a Linux driver for Line6 devices
> (now under sound/usb/line6 in the Linux kernel tree). Some of these
> devices have weird sample rates (39062.5Hz, derived from the 10MHz
> USB clock divided by 256). The alsa_in and alsa_out jack clients
> are convenient tools to use such Line6 devices together with more
> standardized hardware operating at, e.g., 48kHz. However, alsa_in
> only supports integer sample rates, and even after a couple of minutes,
> alsa_in doesn't detect the correct resampling factor 1.2288 (48000/39062.5),
> but still reports the initial approximated value 1.228816 (48000/39062).
> Admittedly, the error isn't too big, but is larger than the error of
> high-quality crystal oscillators. And, after all, why use an approximation
> if we know better?

You could try zita-a2j and j2a (which are also provided by Jack1 as
internal clients) - they should have no problem syncing.

Anyway, the small initial error doesn't matter at all since these
programs will sync to the *actual* sample rate. The nominal value
is just a starting point, and the rounding error (approx 0.0013%
for your example) is much smaller than the random error that can
be expected between any two devices.

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

_______________________________________________
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: fractional frame rates for alsa_in and alsa_out

Markus Grabner
On Monday 13 June 2016 19:34:07 Fons Adriaensen wrote:

> On Mon, Jun 13, 2016 at 12:04:30AM +0200, Markus Grabner wrote:
>
> > A while ago I initiated work on a Linux driver for Line6 devices
> > (now under sound/usb/line6 in the Linux kernel tree). Some of these
> > devices have weird sample rates (39062.5Hz, derived from the 10MHz
> > USB clock divided by 256). The alsa_in and alsa_out jack clients
> > are convenient tools to use such Line6 devices together with more
> > standardized hardware operating at, e.g., 48kHz. However, alsa_in
> > only supports integer sample rates, and even after a couple of minutes,
> > alsa_in doesn't detect the correct resampling factor 1.2288 (48000/39062.5),
> > but still reports the initial approximated value 1.228816 (48000/39062).
> > Admittedly, the error isn't too big, but is larger than the error of
> > high-quality crystal oscillators. And, after all, why use an approximation
> > if we know better?
>
> You could try zita-a2j and j2a (which are also provided by Jack1 as
> internal clients) - they should have no problem syncing.
>
> Anyway, the small initial error doesn't matter at all since these
> programs will sync to the *actual* sample rate. The nominal value
> is just a starting point, and the rounding error (approx 0.0013%
> for your example) is much smaller than the random error that can
> be expected between any two devices.
Thanks for the hint! It took me quite a while, though, to get these programs to work properly, for two reasons:

1.) Out of the box, zita-a2j/j2a wouldn't start at all with my device since no exact (integer) frame rate could be set. I therefore did the same exercise as with alsa_in/out to support fractional frame rates (see attached file "zita-exact-rate.patch"). I hoped it would also converge faster to the correct frame rate if a correct initial value was given, which I could indeed observe occasionally, but on average there was no difference in convergence time. At least the error displayed in verbose mode now exactly represents the relative error between the internal clock sources of both devices :-), which is reasonably small.

2.) After having fixed the initialization issue, I noticed that after a couple of minutes zita_a2j/j2a stop working with the message "Detected excessive timing errors, waiting 10 seconds." and would not recover from this. I added some additional debugging output and tracked this issue down to the point that the problem occurs immediately after the internal timer (lower 28 bits of the jack timestamp) overflows. Therefore I modified the code such that the full 64 bit jack timestamp is used wherever possible (see attached file "zita-jacktime.patch") to get rid of overflow issues (well, almost, the jack timer overflows after more than half a million years :-).

Could you please review the patches and let me know what you think about these?

        Thanks & kind regards,
                Markus

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

zita-exact-rate.patch (6K) Download Attachment
zita-jacktime.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fractional frame rates for alsa_in and alsa_out

David Nielson-2
On 08/18/2016 03:46 PM, Markus Grabner wrote:
>
> Could you please review the patches and let me know what you think about these?
>

(Naive, non-Jack dev responding)

The code around your patch uses 4 spaces for indentation; your new lines
use tabs, so it renders strangely on my system. (I make my tab stops a
strange width specifically to catch this.)

Could the move to a fractional sample rate affect devices with integer
sample rates? IE, does the integer 48000 == 48000 in IEEE 754 floating
point, and if not, what effect will it have?

David Nielson
_______________________________________________
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: fractional frame rates for alsa_in and alsa_out

Paul Davis
Any integer value below 2^24 - 1 has perfect representation in all IEEE floating point formats.

On Fri, Aug 19, 2016 at 10:16 AM, David Nielson <[hidden email]> wrote:
On 08/18/2016 03:46 PM, Markus Grabner wrote:
>
> Could you please review the patches and let me know what you think about these?
>

(Naive, non-Jack dev responding)

The code around your patch uses 4 spaces for indentation; your new lines
use tabs, so it renders strangely on my system. (I make my tab stops a
strange width specifically to catch this.)

Could the move to a fractional sample rate affect devices with integer
sample rates? IE, does the integer 48000 == 48000 in IEEE 754 floating
point, and if not, what effect will it have?

David Nielson
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
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: fractional frame rates for alsa_in and alsa_out

Tim-2
On Friday, August 19, 2016 10:26:08 AM EDT Paul Davis wrote:
> Any integer value below 2^24 - 1 has perfect representation in all IEEE
> floating point formats.

Intersting, I've been seriously contemplating changing MusE's
 internal frame type from integer to double or long double,
 becuase I've been finding some non-trivial timing errors
 that can't be ignored now, requiring fractional frame values.

I never had a super in-depth look at floating point so I researched
 and concluded the same thing, that a double or long double should
 be able to represent the whole integer range that we've been using,
 without error. This would allow us fractional values.

Cheers.
Tim.

>
> On Fri, Aug 19, 2016 at 10:16 AM, David Nielson <[hidden email]> wrote:
> > On 08/18/2016 03:46 PM, Markus Grabner wrote:
> > > Could you please review the patches and let me know what you think about
> >
> > these?
> >
> >
> > (Naive, non-Jack dev responding)
> >
> > The code around your patch uses 4 spaces for indentation; your new lines
> > use tabs, so it renders strangely on my system. (I make my tab stops a
> > strange width specifically to catch this.)
> >
> > Could the move to a fractional sample rate affect devices with integer
> > sample rates? IE, does the integer 48000 == 48000 in IEEE 754 floating
> > point, and if not, what effect will it have?
> >
> > David Nielson

_______________________________________________
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: fractional frame rates for alsa_in and alsa_out

David Nielson-2
In reply to this post by Paul Davis
<troll>
What about when I make good on the threat of creating a sound card with
1-bit samples at 25 MHz?
</troll>

:P

David

On 08/19/2016 09:26 AM, Paul Davis wrote:
> Any integer value below 2^24 - 1 has perfect representation in all IEEE
> floating point formats.
>
_______________________________________________
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: fractional frame rates for alsa_in and alsa_out

Markus Grabner
On Friday 19 August 2016 09:50:28 David Nielson wrote:
> <troll>
> What about when I make good on the threat of creating a sound card with
> 1-bit samples at 25 MHz?
> </troll>
Then you have delta-sigma modulation, and your card will probably output 16- or 24-bit samples at a reasonable rate :-) Aside from that, the rate could certainly be represented by a double precision value, which can accurately represent any 32-bit integer.

        Kind regards,
                Markus

_______________________________________________
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: fractional frame rates for alsa_in and alsa_out

Markus Grabner
In reply to this post by David Nielson-2
On Friday 19 August 2016 09:16:44 David Nielson wrote:

> On 08/18/2016 03:46 PM, Markus Grabner wrote:
> >
> > Could you please review the patches and let me know what you think about these?
> >
>
> (Naive, non-Jack dev responding)
>
> The code around your patch uses 4 spaces for indentation; your new lines
> use tabs, so it renders strangely on my system. (I make my tab stops a
> strange width specifically to catch this.)
I tried hard to keep the original formatting, but seem to have failed at some points since the editor I used (Qt Creator) changes tabs and spaces without notice.

        Kind regards,
                Markus

_______________________________________________
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: fractional frame rates for alsa_in and alsa_out

John Rigg-16
In reply to this post by David Nielson-2
On Fri, Aug 19, 2016 at 09:50:28AM -0500, David Nielson wrote:
> <troll>
> What about when I make good on the threat of creating a sound card with
> 1-bit samples at 25 MHz?
> </troll>

Audio interfaces using 1-bit samples at 24.576 MHz (a variant of octuple
rate DSD) already exist.

John
_______________________________________________
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: fractional frame rates for alsa_in and alsa_out

Fons Adriaensen-3
In reply to this post by Markus Grabner
On Thu, Aug 18, 2016 at 10:46:27PM +0200, Markus Grabner wrote:

> 1.) Out of the box, zita-a2j/j2a wouldn't start at all with my device
> since no exact (integer) frame rate could be set. I therefore did the
> same exercise as with alsa_in/out to support fractional frame rates
> (see attached file "zita-exact-rate.patch"). I hoped it would also
> converge faster to the correct frame rate if a correct initial value
> was given, which I could indeed observe occasionally, but on average
> there was no difference in convergence time.

There shouldn't be. The settling time is determined by the loop
bandwidth.

Which distro are you using ? Zita-alsa-pcmi is *not* part of
zita-ajbridge, it's a separate library, used by a number of other
apps.

Anyway, your patch would mean an incompatible change to the API,
and that's not going to happen. I'll see if and how I can support
fractional sample rates in another way.

Anyway, even set_rate_near() takes an int as parameter, so there
is no point in using a float, except for the test

  rate_num != _fsamp * rate_den

but this will fail anyway unless you are lucky and _fsamp is
an _exact_ floating point representation of num / den.

So the solution could be to use set_rate_near() and replace
the test with something more robust.


> 2.) After having fixed the initialization issue, I noticed that
> after a couple of minutes zita_a2j/j2a stop working with the message
> "Detected excessive timing errors, waiting 10 seconds." and would
> not recover from this. I added some additional debugging output
> and tracked this issue down to the point that the problem occurs
> immediately after the internal timer (lower 28 bits of the jack
> timestamp) overflows.

That's very likely just a coincidence. I'm pretty sure the code
handles the mod 2^28 format correctly, but I'll verify this again.

> Therefore I modified the code such that the full 64 bit jack
> timestamp is used wherever possible (see attached file
> "zita-jacktime.patch") to get rid of overflow issues (well,
> almost, the jack timer overflows after more than half a million
> years :-).

Assuming it starts at zero.

The reduction to 28 bits requires extra code, which means it was
not done without reason. One reason is that I want the loop
calculations to be independent of details such as the format of
the timers used, and use consistent units (seconds).


Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org