[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ALSAPulseAudio procedure

From: Fons Adriaensen
Subject: Re: ALSAPulseAudio procedure
Date: Thu, 2 Jul 2020 16:01:40 +0200

On Thu, Jul 02, 2020 at 06:43:21AM -0500, Barry Duggan wrote:
> Probably I will create a new page for diagnosing audio problems. All
> suggestions are welcome :)

Depending on what exactly you are doing, there may be another problem.

If you take the signal from an RF source, process and decimate it
to e.g. 48 kHz, that frequency will never be *exactly* equal to the 
48 kHz that the audio hardware is using. The reason is simple: each
end uses its own clock. Your RF hardware may have 1 ppm accuracy,
but most internal PC audio cards have much wider tolerances.

No matter how small the difference, this will produce overruns or

The solution is to use adaptive resampling in the audio sink.
This is a problem I've solved a number of times - as a Linux
user you may know the zita-ajbridge and zita-njbridge packages.

I once modified the GR Jack sink to do this, and the same could
be done with the ALSA sink. It worked but required too much
latency to be useful, and the solution wasn't as clean as it
could be.

The reason for that is that the GR framework doesn't provide
(AFAIK) the required 'hooks' to do this.

Basically what is required for an audio sink is that the
sink module needs to know *when* the producer is writing 
to the queue that feeds the audio sink, and how much.
And for an audio source used with and RF sink (i.e. for a 
transmitter), the audio source module should know *when*
the consumer of the audio samples reads its input, and
how much it reads.

And this should work without the module that is connected
to the audio source or sink being aware of this and forced
to cooperate -- that would put a burden on each and every
module that would ever connect to audio.

Without this information, the only robust solution is to
have a large internal buffer in the audio source or sink.
Which in turn means high latency, apart from being not
really an efficient solution.

This was one of the reasons why I abandoned GR and wrote
my own SDR framework.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]