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
