Hi Clemens,
(Apr 6 2014 23:52), Clemens Ladisch wrote:
+static int pcm_open(struct snd_pcm_substream *substream) +{
- ...
- /*
* When source of clock is not internal or any PCM streams are running,* available sampling rate is limited at current sampling rate.*/- if ((clock_source != SND_EFW_CLOCK_SOURCE_INTERNAL) ||
amdtp_stream_pcm_running(&efw->tx_stream) ||amdtp_stream_pcm_running(&efw->rx_stream)) {There is already a mutex for everything in start_duplex(), so the only unprotected piece of data is this counter.
Yes. I think atomic_t mostly solves the issue.
But these codes (in PCM .open) includes another issue which brings a great headache to me.
The driver uses SNDRV_PCM_INFO_JOINT_DUPLEX. So sampling rate for playback/capture should be the same. But there is a case to allow applications to break this rule.
Let's assume that two applications try to use PCM functionality. Application 1 is for 48.0kHz playback, and Application 2 is for 88.2kHz capture. In this case, Application 1 write 48.0kHz samples on 88.2kHz streams:
Application 1: snd_pcm_open() for playback Application 1: snd_pcm_hw_params() at 48.0kHz (snd_pcm_prepare() and AMDTP streams start) Application 2: snd_pcm_open() for capture Application 2: snd_pcm_hw_params() at 88.2kHz (snd_pcm_prepare() and AMDTP streams re-start) Application 2: read PCM samples Application 1: write PCM samples
The reason to allow snd_pcm_prepare() to restart streams at different sampling rate is to continue MIDI substreams at different sampling rate.
I've been considering about this issue for several months but still have no good ideas...
But I think this is actually too rare. I assume most applications write/read samples after snd_pcm_hw_params() as soon as possible and most sound server uses the same sampling rate for its capturing/playbacking.
So I hope this issue pending for my future work.
Thanks
Takashi Sakamoto o-takashi@sakamocchi.jp