29 Aug
2017
29 Aug
'17
8:01 p.m.
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
29 Aug
29 Aug
11:37 p.m.
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/5…
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
31 Aug
31 Aug
8:01 p.m.
> 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
1 Sep
1 Sep
8:25 p.m.
On Thu, 31 Aug 2017, benravin wrote:
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
> 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.
2 Sep
2 Sep
12:26 p.m.
> 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
5:54 p.m.
On Sep 2, 2017, at 06:26, benravin <ben.alex(a)outlook.com> 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 |
|----------------------------------------------------------------------|
3 Sep
3 Sep
3:34 p.m.
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)
4 Sep
4 Sep
9 a.m.
> 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
2:55 p.m.
On Mon, Sep 4, 2017 at 3:00 AM, benravin <ben.alex(a)outlook.com> wrote:
just another reason to avoid working with such formats. decompress it
first to PCM. done.
> 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 ?
6 Sep
6 Sep
6:38 p.m.
>> 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
6:40 p.m.
jackd is a 100% synchronous design, entirely by intent.
On Wed, Sep 6, 2017 at 12:38 PM, benravin <ben.alex(a)outlook.com> 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
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
7:16 p.m.
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
7:20 p.m.
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 <ben.alex(a)outlook.com> 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
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
7:26 p.m.
any example application or document will be very helpful.
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
8 Sep
8 Sep
7:28 p.m.
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
8:51 p.m.
On Fri, Sep 8, 2017 at 6:28 PM, benravin <ben.alex(a)outlook.com> 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
[1] http://lalists.stanford.edu/lad/2011/11/0150.html
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-
f58952.html
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
--
http://www.openavproductions.com
31 Aug
31 Aug
10:52 p.m.
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.
2422
days inactive
2432
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
8 participants
participants (8)
-
Benny Alexandar -
benravin
-
Cedric Roux -
Fons Adriaensen -
Fred Gleason -
Harry van Haaren -
Len Ovens -
Paul Davis