Hi,
Sorry for the delay. I too got sidetracked by other work.
On 28/11/16 19:11, Takashi Iwai wrote:
@@ -1083,15 +1115,17 @@ static int snd_pcm_rate_status(snd_pcm_t *pcm, snd_pcm_status_t * status) status->state = SND_PCM_STATE_RUNNING; status->trigger_tstamp = rate->trigger_tstamp; }
- snd_pcm_rate_sync_hwptr(pcm);
- snd_pcm_rate_sync_hwptr0(rate, status->hw_ptr);
This can't work.
I can fix it in my side, but OTOH, this made me wonder how you tested the patch...
Why do you think that cannot work? I am pretty sure it is working just fine for us but I am sure that it is possible that I have missed something.
status->appl_ptr = *pcm->appl.ptr; status->hw_ptr = *pcm->hw.ptr; if (pcm->stream == SND_PCM_STREAM_PLAYBACK) {
status->delay = snd_pcm_mmap_playback_hw_avail(pcm);
status->delay = rate->ops.input_frames(rate->obj, status->delay)+ snd_pcm_rate_playback_internal_delay(pcm);
status->delay = snd_pcm_mmap_capture_hw_avail(pcm);
status->delay = rate->ops.output_frames(rate->obj, status->delay)+ snd_pcm_mmap_capture_hw_avail(pcm);Why only playback needs the special handling while the capture doesn't? Again, some comments would be helpful for better understanding your changes.
I expect that it could be useful to do something similar with capture but I could not work out what would be needed. OTOH, I think that the way that capture is used, and the way the underlying audio drivers tend to deal with this issue for capture is such that it may not be of much value.
I agree that comments are good. In general I was trying to stick with the pretty minimal-comment style of the existing code.
Alan.