[Please keep ML in Cc.] On Wed, 19 Jul 2023 10:10:47 +0200, Carl Klemm wrote: > > Hi, > > The values only seam nonsensical if playback and record is active at > the same time, otherwise eatch on its own is fine That's an interesting point. You mean "values" as the PCM positions? That is, when running in full-duplex mode, only the capture stream shows strange PCM positions, while PCM playback shows correctly? Or are both screwed up? And, how strange they are? They jump up/down, random values, or any patterns? thanks, Takashi > > Carl Klemm > > On Wed, 2023-07-19 at 09:27 +0200, Takashi Iwai wrote: > > On Wed, 19 Jul 2023 09:10:12 +0200, > > Carl Klemm wrote: > > > > > > Hi, > > > > > > see https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3352 > > > htimestamp returns nonesensical values when recording is active on > > > a > > > EMU20k device > > > > The driver doesn't provide any own implementation of PCM tstamp, > > hence > > it must be the standard values. That said, the incorrect values are > > rather the "avail", that is the PCM position, not the timestamp > > itself, I suppose. > > > > Is it only about recording, i.e. playback doesn't show any wrong > > values? > > > > In anyway, try to enable the tracing for snd_pcm, get the position > > and > > the system timestamp during recording, and verify whether the > > reported > > values are reasonable or not. > > > > > > Takashi >
