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? 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. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
