On Sun, Sep 8, 2019 at 5:23 PM Pavel Hofman pavhofman@gmail.com wrote:
Hi, Gathering data for USB async gadget feedback ( https://mailman.alsa-project.org/pipermail/alsa-devel/2019-August/154819.htm... ) 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.
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?
Thanks a lot,
Pavel.