[LAD] Drift compensation document

[Benny Alexandar]

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

[Len Ovens]

Post by Benny Alexandar
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.

Post by Benny Alexandar
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

[benravin]

Post by Len Ovens
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

[Len Ovens]

Post by Len Ovens

Post by Len Ovens
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

[benravin]

Post by Len Ovens
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

[Fred Gleason]

Post by benravin
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 |
|----------------------------------------------------------------------|

[Fons Adriaensen]

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,

[benravin]

Post by Fons Adriaensen
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

[Paul Davis]

Post by benravin

Post by Fons Adriaensen
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.​

​

[benravin]

This post might be inappropriate. Click to display it.

[Paul Davis]

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

​>> 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
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[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

[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.

Post by 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
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[benravin]

any example application or document will be very helpful.



--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html

[benravin]

This post might be inappropriate. Click to display it.

[Harry van Haaren]

Post by benravin
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

[1] http://lalists.stanford.edu/lad/2011/11/0150.html

Post by benravin
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-
f58952.html
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[Cedric Roux]

Post by Len Ovens
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.