Drift compensation document

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

Drift compensation document

benravin

Hi All,


This is my first post to Linux Audio. I had a look at alsa_in/out programs, and

the man page says it performs drift compensation for drift between the two clocks.


I would like to know more about the implementation details such as the drift

compensation using PI controller. Any paper/presentation documents available

other than the C code. Please share me the details.


-ben


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

Len Ovens
On Tue, 29 Aug 2017, Benny Alexandar wrote:

> This is my first post to Linux Audio. I had a look at alsa_in/out programs, and
> the man page says it performs drift compensation for drift between the two
> clocks.

drift compensation equals resample or Sample Rate Conversion (SRC)

A resample step is used in many places and used to be quite bad (AC97
relies on this to derive all required Sample rates from 48k... in some
cards even 48k goes through SRC) so in a longer recording the left track
and the right may be two different lengths. However, things have gotten a
lot better. BTW, the zita-ajbridge gives better quality and uses less CPU
than alsa_in/out. I believe the Zita SRC libs are available as a separate
package as well.

A lot of broadcast oriented Audio cards offer SRC on each digital (aes3)
input so that the output is sample aligned.

> I would like to know more about the implementation details such as the drift
> compensation using PI controller. Any paper/presentation documents available
> other than the C code. Please share me the details.

If you have ieee access: (I don't so I don't know how good this is)
http://ieeexplore.ieee.org/document/920529/

http://www.analog.com/media/en/technical-documentation/technical-articles/5148255032673409856AES2005_ASRC.pdf
http://homepage.usask.ca/~hhn404/Journals/REV-Jul-Sep2011-Quang.pdf
and more. Google "Asynchronous Sample Rate Converter paper" for more.

--
Len Ovens
www.ovenwerks.net

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

benravin
>> so in a longer recording the left track
and the right may be two different lengths

If the sound card is clocked from a  single crystal, both the channels will
drift by the same amount right ? How each channel will drift apart ? Could
you please elaborate it.

-ben



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

SxDx
In reply to this post by Len Ovens
On 08/29/2017 11:37 PM, Len Ovens wrote:
> If you have ieee access: (I don't so I don't know how good this is)
> http://ieeexplore.ieee.org/document/920529/

Anyone needing access to documents stored on this IEEE thing
can ask me.

Offlist.

Obviously.
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

Len Ovens
In reply to this post by benravin
On Thu, 31 Aug 2017, benravin wrote:

>>> so in a longer recording the left track
> and the right may be two different lengths
>
> If the sound card is clocked from a  single crystal, both the channels will
> drift by the same amount right ? How each channel will drift apart ? Could
> you please elaborate it.

When using SRC to match sample rate on a stereo unit, the two channels
need to be processed together. Some of the ac97 audio cards just plugged
two SRC units inline with the digital audio. The card's crystal would have
given two channels of 48k audio in sync, but after the SRC units that sync
would be lost. I also have some not so nice things to say about the HD
audio that replaced AC97, but sync is not one of them.

People seem to forget that no matter what most MP3s use as a sample rate,
in the minds of the Intel and Microsoft engineers, 48k is (was) the
standard. So all those MP3s on a windows system would have gone through a
sample rate change from 44k1 to 48k on their way to the audio card.

Internal Audio inputs are designed for using things like skype, where
quality doesn't matter. The bit depth may be 16 or more bits, but the
audio circuitry in front of that is closer to the cassette tape than any
mic preamp used in a studio (even a bedroom studio for playing around in).

--
Len Ovens
www.ovenwerks.net

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

benravin
>> A lot of broadcast oriented Audio cards offer SRC on each digital (aes3)
input so that the output is sample aligned

If audio sample rate of a radio receiver has to be matched with respect to
transmitter  radio station audio sample rate, then some timing information
has to be derived.  But, in case of broadcast digital radio receivers, there
is no information about the time stamps in the received data as metadata
information. How to timestamp and do the drift compensation in this
scenario?



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

Fred Gleason-2
On Sep 2, 2017, at 06:26, benravin <[hidden email]> wrote:

If audio sample rate of a radio receiver has to be matched with respect to
transmitter  radio station audio sample rate, then some timing information
has to be derived.  But, in case of broadcast digital radio receivers, there
is no information about the time stamps in the received data as metadata
information. How to timestamp and do the drift compensation in this
scenario? 

One approach that I’ve used with good success here is to run the decoded PCM through a FIFO buffer between the SRC and the play-out stages and then use the size of that FIFO (which will change dynamically in response to things like network congestion) to feed a PLL that drives the converter ratio for the SRC stage.  The trade-off for this approach of course is increased latency.  If true low-latency operation is required, then some sort of clocking (ala AES67) will be required.

Cheers!


|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |              Chief Developer             |
|                           |              Paravel Systems             |
|----------------------------------------------------------------------|
|          A room without books is like a body without a soul.         |
|                                         -- Cicero                    |
|----------------------------------------------------------------------|


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

Fons Adriaensen-3
On Sat, Sep 02, 2017 at 11:54:15AM -0400, Fred Gleason wrote:
 
> One approach that I’ve used with good success here is to run
> the decoded PCM through a FIFO buffer between the SRC and the
> play-out stages and then use the size of that FIFO (which will
> change dynamically in response to things like network congestion)
> to feed a PLL that drives the converter ratio for the SRC stage.

Which is what zita-ajbridge and njbridge do in software.
The difference is that since data enters and leaves the
fifo in blocks of samples and not as a constant rate stream
it's a bit more involved to obtain the (average) FIFO size.

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)

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

benravin
>> The difference is that since data enters and leaves the
>> fifo in blocks of samples and not as a constant rate stream.

But the timestamping on block of data writes can introduce more timing
errors even with a DLL. For example if the audio is compressed the decoding
time can vary based on the content and is proportional to write timestamps
( encoding of silence followed by high content).  How to compensate these
jitters  ?  

-ben



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

Paul Davis


On Mon, Sep 4, 2017 at 3:00 AM, benravin <[hidden email]> wrote:
>> The difference is that since data enters and leaves the
>> fifo in blocks of samples and not as a constant rate stream.

But the timestamping on block of data writes can introduce more timing
errors even with a DLL. For example if the audio is compressed the decoding
time can vary based on the content and is proportional to write timestamps
( encoding of silence followed by high content).  How to compensate these
jitters  ?

​just another reason to avoid working with such formats. decompress it first to PCM. done.​



_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

benravin

​>> just another reason to avoid working with such formats. decompress it
first to PCM. done.​


Thanks Paul! I was time stamping the output of audio codec  decoded PCM
samples which was introducing lot of jitter. Now I'm reusing what Fons had
implemented on zita-j2a using a *local* fifo and not the buffers which used
to connect the graph. I need to test the control loop for my audio app.

btw,  is it possible to send some asynchronous control signals in jackd ?

-ben



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

Paul Davis
jackd is a 100% synchronous design,  entirely by intent.

On Wed, Sep 6, 2017 at 12:38 PM, benravin <[hidden email]> wrote:

​>> just another reason to avoid working with such formats. decompress it
first to PCM. done.​


Thanks Paul! I was time stamping the output of audio codec  decoded PCM
samples which was introducing lot of jitter. Now I'm reusing what Fons had
implemented on zita-j2a using a *local* fifo and not the buffers which used
to connect the graph. I need to test the control loop for my audio app.

btw,  is it possible to send some asynchronous control signals in jackd ?

-ben



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

benravin
Ok, my requirement is to apply fade-in on first audio period when audio
starts, and do fade-out on last audio period when stopped to avoid any audio
glitches. These start and stop is based on user selection and De-selection
of audio.  How is  it possible with Jack ?



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

Paul Davis
it has nothing to do with JACK.

you need to pump events/notifications/requests into the process thread/callback via your own mechanism (lock-free FIFOs are common) and act on them from there.

On Wed, Sep 6, 2017 at 1:16 PM, benravin <[hidden email]> wrote:
Ok, my requirement is to apply fade-in on first audio period when audio
starts, and do fade-out on last audio period when stopped to avoid any audio
glitches. These start and stop is based on user selection and De-selection
of audio.  How is  it possible with Jack ?



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

benravin
any example application or document will be very helpful.



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

benravin
In reply to this post by Paul Davis
Hi Paul,

I feel its better to add these support as well in JACK framework, like
sending control signals, notifications etc, rather than user has to
implement these.

-ben



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Drift compensation document

Harry van Haaren
On Fri, Sep 8, 2017 at 6:28 PM, benravin <[hidden email]> wrote:
Hi Paul,

I feel its better to add these support as well in JACK framework, like
sending control signals, notifications etc, rather than user has to
implement these.

Hi Ben,

Please be aware of "top posting" - it is good manners to reply under a message, so the context of the reply is maintained.

In response to your comments above, I will politely disagree. While a library or framework to do async messaging etc might be useful to some JACK users, it will certainly not benefit everybody. As such, it should be a separate project, and not demand that existing JACK users also have to deal with this extra complexity/functionality.

Some googling will likely lead you to multiple frameworks or libraries that provide lock-free programming constructs like queues, FIFOs, locks etc. There's even a few old threads on this mailing-list[1] about it :)

Regards, -Harry
 
 
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev



--

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev