Takashi Iwai wrote:
Takashi, thanks for the patch, it works flawlessly.
OK, now committed to HG tree.
Thanks a lot. I will just resolve the conflicts now :)
Another issue - when the external clock changes rate and the stream is running (typically when starting the source playback which switches the source card (and its SPDIF-OUT) to a different frequency), the target card detects the change and the capture stream is stopped in snd_ak4114_check_rate_and_errors() by
snd_pcm_stop(ak4114->capture_substream, SNDRV_PCM_STATE_DRAINING);
How should recording applications behave with stream in this mode? I would expect arecord to close, but it does nothing. Is this correct behaviour?
It's supposed to be drained then stopped. Maybe something wrong in the handling of DRAINING state in the capture direction.
Anyway, it's a bit strange situation as is. Since the sample rate is changed, you can't call simply prepare again like normal errors...
I would expect arecord to quit with some relevant message. In larger recording apps, e.g. Audacity, it should probably stop recording and display a warning message. No idea if the controlled stop with an appropriate error message is feasible with the existing API and code.
Thanks,
Pavel Hofman.