On Apr 13, 2013 1:55 AM, "Takashi Iwai" tiwai@suse.de wrote:
At Fri, 12 Apr 2013 10:55:27 +0200, Takashi Iwai wrote:
At Thu, 11 Apr 2013 19:17:10 -0600, Pierre-Louis Bossart wrote:
For playback audio_timestamp = wallclk - codec_delay_in_nsec for capture audio_timestamp = wallclk + codec_delay_in_nsec
Hmm... I'm confused, too. From a pretty generic view,
- hwptr = the samples (frames) transferred on the (memory) buffer
- hwptr + PCM delay = the point being currently captured
Which position does the wall clock correspond?
you now have 3 positions:
For capture: hwptr = sample in memory hwptr+ delay = sample recorded on link (tracked by LPIB and wallclock) hwptr+ delay + codec_delay = sample recorded by A/D
For playback hwptr = next sample in memory to be DMA'ed hwptr - delay = sample pushed on link (tracked by LPIB and wallclock) hwptr - delay - codec_delay = sample played in A/D
the wallclock is only at the soc/chipset level, it doesn't know
anything
about the peripheral. Makes sense?
Thanks, now it's clearer.
Dylan, could you care to submit the fix patch?
It will be the first thing I do when I get to the office tomorrow morning.
Thanks,
Dylan
thanks,
Takashi