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