Best regards *Timo Wischer* Engineering Software Base (ADITG/ESB)
Tel. +49 5121 49 6938 On 10/30/18 11:49, Takashi Iwai wrote:
On Tue, 30 Oct 2018 11:39:38 +0100, twischer@de.adit-jv.com wrote:
From: Laxmi Devi Laxmi.Devi@in.bosch.com
These changes are required due to the kernel commit 07b7acb51d283d8469696c906b91f1882696a4d4 ("ASoC: rsnd: update pointer more accurate")
Issue is that snd_pcm_wait() goes back to waiting because the hw_ptr is not period aligned. Therefore snd_pcm_wait() will block for a longer time as required.
With these rcar driver changes the exact position of the dma is returned. During snd_pcm_start they read hw_ptr as reference, and this hw_ptr is now not period aligned, and is a little ahead over the period while it is read. Therefore when the avail is calculated during snd_pcm_wait(), it is missing the avail_min by a few frames. Consider the below example:
Considering the application is trying to write 0x120 frames and the period_size = 0x60, avail_min = 0x120 and buffersize = 0x360 :
rsnd_pointer=0x12c -> dma pointer at the end of second write during snd_pcm_dmix_start(). Since another 0x120 buffer is available, application writes 0x120 and goes to snd_pcm_wait(). It is woken up after 3 snd_pcm_period_elapsed() to see rsnd_pointer=0x248. So hw_ptr = new_slave_hw_ptr - reference_slave_hw_ptr = 0x248 - 0x12c = 0x11c. It needs 4 more frames to be able to write. And so it goes back to waiting.
But since 3 snd_pcm_period_elapsed(), 3 periods should be available and it should have been able to write. If rsnd_pointer during the start was 0x120 which is 3 periods then 0x248 - 0x120 = 128 it could go on with write.
Signed-off-by: Laxmi Devi Laxmi.Devi@in.bosch.com
On 10/29/18 16:54, Takashi Iwai wrote: The problem is that aligning the start essentially imposes an artificial long latency, and changes the behavior out of sudden.
Now, we are only align the salve_hw_ptr which also solves our delay issue. But this change should not increase the latency because the write position is given by slave_appl_ptr. Do you see any other drawbacks?
How does this work? I thought hwptr is synced to the actual slave value soon later in anyway?
The slave_hw_ptr is initialized in reset_slave_ptr() and updated in snd_pcm_dmix_sync_ptr() with
dmix->slave_hw_ptr = *dmix->spcm->hw.ptr;
The hw_ptr will be incremented in snd_pcm_dmix_sync_ptr() by adding the diff between the last slave_hw_ptr and the current slave_hw_ptr. Due to the alignment of the slave_hw_ptr on startup (in reset_slave_ptr()) the offset between the slave_hw_ptr and hw_ptr is a multiple of slave_period. The following slave_hw_ptr will be always x * period_size + y where x is always incremented for each snd_pcm_period_elapsed() call. y can be sometimes 0 but also contain some frames due to the delay between the DMA interrupt till reading the current DMA position.
The diff between the salve_hw_ptr will be continuously added to hw_ptr. Sometimes the diff can be < period_size but anyway the hw_ptr follows the same interval as the salve_hw_ptr:
* 1 * period_size + y1 * 2 * period_size + y2 * 3 * period_size + y3 * ...
y can differ between the snd_pcm_dmix_sync_ptr() calls. But it is never <0. Therefore the application can always write one period if it writes all chunks in periods.
Best regards
Timo
thanks,
Takashi
Best regards
Timo
diff --git a/src/pcm/pcm_dmix.c b/src/pcm/pcm_dmix.c index a6a8f3a..eaa0b0f 100644 --- a/src/pcm/pcm_dmix.c +++ b/src/pcm/pcm_dmix.c @@ -560,6 +560,8 @@ static int snd_pcm_dmix_hwsync(snd_pcm_t *pcm) static void reset_slave_ptr(snd_pcm_t *pcm, snd_pcm_direct_t *dmix) { dmix->slave_appl_ptr = dmix->slave_hw_ptr = *dmix->spcm->hw.ptr;
- dmix->slave_hw_ptr = ((dmix->slave_hw_ptr / dmix->slave_period_size)
* dmix->slave_period_size);-- 2.7.4