[pulseaudio-discuss] How does automatic output resampling in Pulseaudio work?

[Lennart Poettering]

On Mon, 18.02.08 11:56, Erich Boleyn (erich at uruk.org) wrote:

> 
> Greetings all,
> 
> I'm using higher-quality 24-bit/96-khz PCM to avoid resampling and
> dynamic range artifacts in my sound setup, even though most of my sources
> start out at 16-bit/44.1-khz.
> 
> In trying to keep the audio in the higher-quality format as long as
> possible, a question arises:
> 
> When Pulseaudio converts from one format to another at the sound output
> (say for an ostensibly 16-bit/48-khz DAC) *and* performs the automatic
> output resampling (due to the normal output hardware clock imperfection
> issues), which one more accurately represents the real chain of events:
> 
>   A)    24-bit/96-khz PCM  --(resampled)-->  16-bit/48-khz
>                            --(resampled)-->  16-bit/near-48-khz-real-freq
> 
>   B)    24-bit/96-khz PCM  --(resampled)-->  16-bit/near-48-khz-real-freq
> 
> I.e. is it resampled once to get to the "output format" and again at
> the final hardware matching stage, or is it resampled once directly to
> the hardware matching frequency?

If necessary, resampling happens at every sink. I.e. if you connect a
stream to a sink, and it doesn't match the sample rate of the sink,
then we will have to resample. 

If you run module-combine then this might have the effect things are
first resampled when handed over to the virtual combined sink and than
once again for each of the backend sinks.

Because PA is no system for building pipelines we do not optimize for
minimal resampling on the way through the pipeline.

PA has no right to assume [1] that the system clock is any more "correct"
than the sound card clock. Hence PA will never resample just because
of a deviation between system clock and sound card clock.

module-combine however resamples in all cases to cope for the
differing hardware clocks.

Lennart

Footnotes:

[1] Actually, system clocks tend to be much better than sound card
clocks, but that's just one observation. And all real world clocks
deviate from atomic time. That's a fact and not fixable.

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4