[pulseaudio-discuss] [RFC PATCH] alsa-sink: Reduce hardware pointer update syscalls

[Raymond Yau]

>
>
> > > anyway, above patch might have fixed the issue and I was able to do
some
> > > measurements on a beagleboard (ARMv7, OMAP3, TPS65950 PMIC audio),
> > > Linux kernel 3.7 and PA shortly before the srbchannel patches...
> >
> > Even the driver use SNDRV_PCM_INFO_NO_PERIOD_WAKEUP which is necessary
but
> > no sufficient
> >
> > For timer schedulling, the driver need to report dma residue
> > and it look like some omap cannot report DMA residue granularity
> >
> > Can your hardware report dma residue granularity?
> >
> >
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/soc/omap/omap-pcm.c
> >
> > static snd_pcm_uframes_t omap_pcm_pointer(struct snd_pcm_substream
> > *substream)
> > {
> > snd_pcm_uframes_t offset;
> >
> > if (pcm_omap1510())
>
> this is true for ancient OMAP1 only, OMAP3 uses
snd_dmaengine_pcm_pointer()

@DMA_RESIDUE_GRANULARITY_BURST: Residue is updated after each transferred
burst. This is typically only supported if the hardware has a progress
register of some sort (E.g. a register with the current read/write address
or a register with the amount of bursts/beats/bytes that have been
transferred or still need to be transferred).

What is the dma brust size in this platform?

Do this mean that the period size of your omap3 is multiple of dma brust
size?

Do this imply those starttheshold,  hwbuf_unused,... need to be multiple of
dma brust size?

Do the dynamic latency range are just only finite points instead of
continuous?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20141004/80acb9bd/attachment.html>