Bug 75954 - FIX_RATE and AUTO_TIMING_UPDATE don't work properly together
Summary: FIX_RATE and AUTO_TIMING_UPDATE don't work properly together
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: daemon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-09 17:19 UTC by Remi Denis-Courmont
Modified: 2018-07-30 10:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Test program (7.19 KB, text/plain)
2014-03-11 14:17 UTC, Tanu Kaskinen
Details

Description Remi Denis-Courmont 2014-03-09 17:19:34 UTC
SYSTEM:

HDA Intel / Realtek ALC887 card (stereo)
Linux kernel 3.13.6
Debian (Sid) on x86-64
PulseAudio 4.0 with default settings


STEPS TO REPRODUCE:

1) (re)start the PulseAudio daemon (pulseaudio -k)
-> the HDA sink input is initialized as: s16ke 2ch 44100Hz

2) play a stream at 48000kHz
-> the HDA sink input rate is changed to 48000Hz

3) stop the stream

4) play a stream at 22050Hz with PA_STREAM_FIX_RATE flag
-> the HDA sink input rate stays at 48000Hz (wrong) and the timing is totally off, as if the card was 44100Hz. With VLC this causes continuous pitch shifts.

Note: If PA_STREAM_FIX_RATE is not used, then PulseAudio correctly reverts to 44100Hz output.
Comment 1 Raymond 2014-03-11 09:01:09 UTC
but you alc887 does not support 22050

http://freedesktop.org/software/pulseaudio/doxygen/def_8h.html#a6966d809483170bc6d2e6c16188850fcab81c3687c121ad24c8c6673eca01c4d3

PA_STREAM_FIX_RATE

Use the sample rate of the sink, and possibly ignore the rate the sample spec contains.

Usage similar to PA_STREAM_FIX_FORMAT. Only supported when the server is at least PA 0.9.8. It is ignored on older servers.
Comment 2 Tanu Kaskinen 2014-03-11 14:17:57 UTC
Created attachment 95605 [details]
Test program

What does "pactl list sinks short" and "pactl list sink-inputs short" show when VLC is experiencing this problem?

I couldn't reproduce this with the attached test program. The test program does this in its write callback:

        now = pa_timeval_load(pa_gettimeofday(&timeval));
        seconds_passed = (now - started_at) / PA_USEC_PER_SEC;
        printf("seconds_passed = %u\n", seconds_passed);

        if (pa_stream_get_time(p, &stream_usec) >= 0) {
                stream_time = stream_usec / PA_USEC_PER_SEC;
                printf("stream_time = %u\n", stream_time);
        } else
                printf("pa_stream_get_time() failed.\n");

So it spams the terminal with this kind of output:

stream_write_cb()
seconds_passed = 260
stream_time = 260
stream_write_cb()
seconds_passed = 260
stream_time = 260
stream_write_cb()
seconds_passed = 261
stream_time = 260
stream_write_cb()
seconds_passed = 261
stream_time = 260

seconds_passed is the wall clock time since starting the stream, and stream_time is the stream time as returned by pa_stream_get_time(). If the stream was in reality playing at 44100 Hz while the reported sample spec was 48000 Hz, I'd expect seconds_passed and stream_time to diverge over time.
Comment 3 Remi Denis-Courmont 2014-03-11 18:57:43 UTC
Correction: The long term average playback rate appears to be 48kHz as reported by PulseAudio. However the short term timing values returned by pa_stream_get_latency() seem to be way off. More precisely the combination of PA_STREAM_FIX_RATE and PA_STREAM_AUTO_TIMING_UPDATE does not work properly; if I remove either or both flags, everything is fine.

(FWIW, VLC uses PA_STREAM_START_CORKED | PA_STREAM_INTERPOLATE_TIMING | PA_STREAM_NOT_MONOTONIC | PA_STREAM_AUTO_TIMING_UPDATE | PA_STREAM_FIX_RATE bu dyfault)

Tanu, here is what the requested command give me:

% pactl list sinks short
0       alsa_output.pci-0000_01_00.1.hdmi-stereo        module-alsa-card.c     s16le 2ch 44100Hz        SUSPENDED
1       alsa_output.pci-0000_00_1b.0.analog-stereo      module-alsa-card.c     s16le 2ch 48000Hz        RUNNING

% pactl list sink-inputs short
8       1       16      protocol-native.c       s16le 2ch 48000Hz

Raymond, I am aware of the fact that my soundcard does not support 22050Hz natively. However, I would have expected PulseAudio to select 44100Hz rather than 48000Hz in this case, since resampling to a straight multiple is a lot easier and better.
Comment 4 Tanu Kaskinen 2014-03-12 08:06:01 UTC
(In reply to comment #3)
> Raymond, I am aware of the fact that my soundcard does not support 22050Hz
> natively. However, I would have expected PulseAudio to select 44100Hz rather
> than 48000Hz in this case, since resampling to a straight multiple is a lot
> easier and better.

If you set the FIX_RATE flag, pulseaudio will ignore the rate in the sample spec, so your expectation of switching to 44100 Hz will not be met, unless someone implements a feature that allows applications to say "yes, I did set FIX_RATE, but if it's possible to adjust the device rate, I'd prefer 22050 Hz or something that is easy to resample to from 22050 Hz".
Comment 5 Raymond 2014-03-13 02:11:48 UTC
pulseaudio client cannot specify the sink to use specific  sample rate except passthrough mode which the client exclusively use the sink

the  fix-rate option of pacat seem support pitching if the rate of sample is different from the sink
Comment 6 Remi Denis-Courmont 2014-07-21 19:41:23 UTC
(In reply to comment #4)
> If you set the FIX_RATE flag, pulseaudio will ignore the rate in the sample
> spec, so your expectation of switching to 44100 Hz will not be met, unless
> someone implements a feature that allows applications to say "yes, I did set
> FIX_RATE, but if it's possible to adjust the device rate, I'd prefer 22050
> Hz or something that is easy to resample to from 22050 Hz".

Well I don't really care about which rate is used down the line. I think 44100 Hz would make more sense, but I could live with 48000 Hz too.

The problem remains that PA_STREAM_FIX_RATE and PA_STREAM_AUTO_TIMING_UPDATE are incompatible and yet 1) this is not documented 2) this does not even return an error.
Comment 7 Tanu Kaskinen 2014-07-22 07:36:49 UTC
(In reply to comment #6)
> The problem remains that PA_STREAM_FIX_RATE and PA_STREAM_AUTO_TIMING_UPDATE
> are incompatible and yet 1) this is not documented 2) this does not even
> return an error.

I don't think PA_STREAM_FIX_RATE and PA_STREAM_AUTO_TIMING_UPDATE are incompatible on purpose, so documenting this doesn't make sense. Someone just needs to fix whatever bug is behind this.
Comment 8 Raymond 2014-07-23 00:58:33 UTC
if sinks is already running at 48000Hz, it is unlikely to change the rate to 44100Hz when there is another client plating at 48000Hz



       alsa_output.pci-0000_00_1b.0.analog-stereo      module-alsa-card.c     s16le 2ch 48000Hz        RUNNING
Comment 9 GitLab Migration User 2018-07-30 10:08:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/237.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.