[alsa-devel] [PATCH v2] ALSA: hda - Apply codec delay to wallclock.

Dylan Reid dgreid at chromium.org
Mon Apr 15 10:02:29 CEST 2013


On Apr 13, 2013 1:55 AM, "Takashi Iwai" <tiwai at 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


More information about the Alsa-devel mailing list