[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