[pulseaudio-discuss] [PATCH 0/8] Rate update fixes

[Tanu Kaskinen]

On Mon, 2013-08-12 at 13:48 +0200, David Henningsson wrote:
> On 08/12/2013 01:33 PM, Tanu Kaskinen wrote:
> > On Mon, 2013-08-12 at 13:24 +0200, David Henningsson wrote:
> >> On 08/12/2013 12:34 PM, Tanu Kaskinen wrote:
> >>> On Mon, 2013-08-12 at 09:34 +0200, David Henningsson wrote:
> >>>> On 08/09/2013 08:57 AM, Tanu Kaskinen wrote:
> >>>>> While investigating a bug[1], I found several bugs in the rate update
> >>>>> code related to monitor sources. This should make things work
> >>>>> properly for non-passthrough streams. Things are probably still broken
> >>>>> for passthrough streams, but that's a complex topic that I don't want
> >>>>> to spend time on at the moment.
> >>>>
> >>>> And trying to understand the last patches, what is the scenario? You
> >>>> start recording the monitor source at 48 kHz while the sink is silent,
> >>>> and then sink starts playing back a 44.1 kHz stream. What happens?
> >>>
> >>> The scenario for "source: Don't update the monitor source rate, if the
> >>> sink is running" is that something is playing to the sink at 44.1 kHz,
> >>> and then something connects to the monitor source at 48 kHz. What
> >>> happens (without the patch) is that the monitor source rate changes, and
> >>> the client thinks it's getting 48 kHz audio, while in reality the rate
> >>> is 44.1 kHz.
> >>>
> >>> The scenario for "source: When updating a monitor source's rate, update
> >>> the sink rate too" is that nothing is playing and the device is
> >>> configured to 44.1 kHz and then something connects to the monitor
> >>> source. Again, without the patch, the monitor source changes rate to 48
> >>> kHz, so that's what the client thinks it's getting. In reality, the sink
> >>> runs at 44.1 kHz, so that's what's being fed to the monitor source too.
> >>> At this point it's all silence, so it doesn't matter that much (the
> >>> recorded audio length is just surprisingly short) but if something
> >>> starts to play to the sink, that audio will be 44.1 kHz, while the
> >>> client thinks it's 48 kHz.
> >>>
> >>> I'll add something to the commit messages to make this clearer.
> >>>
> >>
> >> So what happens instead in the scenarios above, *with* the patch? Is a
> >> resampler automatically inserted on the source output?
> > 
> > If the sink is running, trying to switch the monitor source rate fails,
> > so the source output will have to use resampling. If the sink is not
> > running, both the monitor source and the sink rate will be switched.
> > 
> 
> So if the sink is idle, the monitor source and the sink are both
> switched to 48 kHz and then a stream of 44.1 kHz starts playing on the
> sink. Will the sink then switch back and that will in turn add a
> resampler on the monitor source? Or is it the sink input that will be
> resampled?

The sink input will be resampled, because the sink can't change its rate
if the monitor is running.

> I guess it will be preferred to have the resampler at the monitor
> source, but it seems like an unusual situation, so as long as we don't
> end up with the wrong rates I think it's good enough for now.

I agree.

-- 
Tanu