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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
