[alsa-devel] Measuring Device Throughput - MMAP vs. RW

Takashi Iwai tiwai at suse.de
Mon Sep 9 19:44:11 CEST 2019


On Mon, 09 Sep 2019 18:30:14 +0200,
Pavel Hofman wrote:
> 
> On Sun, Sep 8, 2019 at 5:23 PM Pavel Hofman <pavhofman at gmail.com> wrote:
> 
> > Hi,
> > Gathering data for USB async gadget feedback (
> > https://mailman.alsa-project.org/pipermail/alsa-devel/2019-August/154819.html
> > ) requires measuring average data rate to/from a device. For testing I
> > added measuring/averaging code to methods snd_pcm_hw_writei, snd_pcm_hw_readi,
> > and snd_pcm_hw_mmap_commit in
> > https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_hw.c .
> > In all cases I take the parameter "size" of all the three methods as the
> > number of samples written/read.
> >
> > MMAP: When mmap is used (e.g. plughw:X + sample format conversion), I get
> > very stable results for MMAP playback on all soundcards I have tested. But
> > for capture I get identical results to playback for one soundcard (PCI
> > Envy24), while the averaged rate calculated from "size" in
> > snd_pcm_hw_mmap_commit fluctuates for capture on Intel HDA.
> >
> >
> > I suspect the size parameter of snd_pcm_hw_mmap_commit is not the actual
> > amount of samples read during the MMAP capture. Please how to calculate the
> > number of samples read from the variables available in that method?
> >
> 
> The mmap fluctuations seem to be fixed by using increases in hardware
> pointer pcm->hw.ptr values instead of frames variable. Please do these
> values wrap up or do they grow  to max long? Still contiguous after 10
> minutes of running.

Could you elaborate the requirement?  The description isn't clear to
me.

> I see the hw.ptr gets zeroed at XRUN. If I do not check for xruns (
> snd_pcm_state(snd_pcm_t *pcm)?), can I just monitor continuity of hw.ptr
> and restart the averaging if the new hw.ptr is lower than the previous one,
> or are there any quirks to watch out?

You should be able to skip XRUN check by changing the stop_threshold.
Setting it to the boundary size essentially means skipping XRUN
checks.

In anyway, I put Pierre to Cc, as he's done some works in the past for
the accurate position reporting on HD-audio and USB-audio devices.
He can give a better hint in this regard.


thanks,

Takashi


More information about the Alsa-devel mailing list