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

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

[Pavel Hofman]

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.

RW: The averaging works very well for R/W access (hw:X) for playback and
capture, I get same values on the same device (playback/capture timed by
one clock).

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.

The averaging is simply summing "size" in every call of the method and
dividing by passed nanosecs every approx 10 seconds:

Working OK (Infrasonic Quartet, and all soundcards for read/write mode):
Playback
MMAP Time: 19440.900391, averaged samplerate: 48000.511829
MMAP Time: 19451.140625, averaged samplerate: 48000.360218
MMAP Time: 19461.380859, averaged samplerate: 48000.176846
MMAP Time: 19471.619141, averaged samplerate: 48000.664570
MMAP Time: 19481.861328, averaged samplerate: 48000.199970
MMAP Time: 19492.101562, averaged samplerate: 48000.589854
MMAP Time: 19502.341797, averaged samplerate: 48000.288977
MMAP Time: 19512.580078, averaged samplerate: 48000.516104
MMAP Time: 19522.820312, averaged samplerate: 48000.225282

Capture:
MMAP Time: 19454.578125, averaged samplerate: 48000.430766
MMAP Time: 19464.818359, averaged samplerate: 48000.397611
MMAP Time: 19475.056641, averaged samplerate: 48000.400049
MMAP Time: 19485.296875, averaged samplerate: 48000.293275
MMAP Time: 19495.539062, averaged samplerate: 48000.549048
MMAP Time: 19505.779297, averaged samplerate: 48000.445214
MMAP Time: 19516.017578, averaged samplerate: 48000.417299
MMAP Time: 19526.257812, averaged samplerate: 48000.376264
MMAP Time: 19536.498047, averaged samplerate: 48000.422957
MMAP Time: 19546.738281, averaged samplerate: 48000.538619
MMAP Time: 19556.976562, averaged samplerate: 48000.241647
MMAP Time: 19567.216797, averaged samplerate: 48000.447243

Fluctuating Capture (Intel HDA):
Playback - OK:
MMAP Time: 19574.498047, averaged samplerate: 47998.971874
MMAP Time: 19584.568359, averaged samplerate: 47998.871734
MMAP Time: 19594.636719, averaged samplerate: 47998.929850
MMAP Time: 19604.707031, averaged samplerate: 47998.972555
MMAP Time: 19614.775391, averaged samplerate: 47998.925531
MMAP Time: 19624.845703, averaged samplerate: 47998.893351
MMAP Time: 19634.916016, averaged samplerate: 47998.949489
MMAP Time: 19644.986328, averaged samplerate: 47998.593678
MMAP Time: 19655.056641, averaged samplerate: 47999.230857
MMAP Time: 19665.125000, averaged samplerate: 47998.777034
MMAP Time: 19675.195312, averaged samplerate: 47999.177460
MMAP Time: 19685.263672, averaged samplerate: 47998.798503

Capture - fluctuating, clearly some samples are not counted:
MMAP Time: 19539.853516, averaged samplerate: 47191.039837
MMAP Time: 19549.923828, averaged samplerate: 46369.921890
MMAP Time: 19559.994141, averaged samplerate: 47998.831508
MMAP Time: 19570.148438, averaged samplerate: 47190.998307
MMAP Time: 19580.302734, averaged samplerate: 47191.275432
MMAP Time: 19590.373047, averaged samplerate: 47998.894343
MMAP Time: 19600.443359, averaged samplerate: 47998.906779
MMAP Time: 19610.511719, averaged samplerate: 47999.174771
MMAP Time: 19620.582031, averaged samplerate: 47998.747971
MMAP Time: 19630.650391, averaged samplerate: 47998.881964
MMAP Time: 19640.722656, averaged samplerate: 47998.999974
MMAP Time: 19650.791016, averaged samplerate: 47998.769240

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?

Thanks a lot.

Pavel.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Pavel Hofman]

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.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.

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Takashi Iwai]

On Mon, 09 Sep 2019 18:30:14 +0200,
Pavel Hofman wrote:
> 
> 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.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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Pavel Hofman]

On Mon, Sep 9, 2019 at 7:44 PM Takashi Iwai <tiwai@suse.de> wrote:

> > 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 need to slave EP OUT of asynchronous USB-audio gadget  (i.e. device) to
another (output) soundcard in the system so that adaptive resampling in the
chain "USB gadget -> processing -> output soundcard" is avoided.  For that
I need to measure average throughput to/from alsa hw:X devices, to gather
data for the feedback endpoint implemented by the gadget driver.  I do not
have any control over configuration of the devices, the feedback must run
independently of the rest of the chain, of the applications used.

In snd_pcm_hw_mmap_commit I subtract the advancement of pcm->hw.ptr from
value approx. 10 seconds ago, divided by passed nanosecs measured by
clock_gettime(CLOCK_MONOTONIC). For that I need the pcm->hw.ptr either to
be monotonic, or I just reset the averaging if a non-monotony is detected
(hw pointer in previous (n-1) call of snd_pcm_hw_mmap_commit was higher
than  current value).

For better precision, would it make sense to update the pcm->hw.ptr with
snd_pcm_avail call in that method? It may not be even possible in that
method due to some locking, I really do not know. But my precision
requirements are not very strict since I can average over long time
(minutes) for the feedback (the clock difference is usually very small).


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

Actually if  xruns could be detected by discontinuity of the hw pointer, I
would not need any other method.


> 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 a lot, I very much appreciate your help. I do not know these
low-level alsa details. But I will gladly learn.

Pavel.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Takashi Iwai]

On Mon, 09 Sep 2019 21:31:49 +0200,
Pavel Hofman wrote:
> 
> On Mon, Sep 9, 2019 at 7:44 PM Takashi Iwai <tiwai@suse.de> wrote:
> 
>     > 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 need to slave EP OUT of asynchronous USB-audio gadget  (i.e. device) to
> another (output) soundcard in the system so that adaptive resampling in the
> chain "USB gadget -> processing -> output soundcard" is avoided.  For that I
> need to measure average throughput to/from alsa hw:X devices, to gather data
> for the feedback endpoint implemented by the gadget driver.  I do not have any
> control over configuration of the devices, the feedback must run independently
> of the rest of the chain, of the applications used.
> 
> In snd_pcm_hw_mmap_commit I subtract the advancement of pcm->hw.ptr from value
> approx. 10 seconds ago, divided by passed nanosecs measured by clock_gettime
> (CLOCK_MONOTONIC). For that I need the pcm->hw.ptr either to be monotonic, or
> I just reset the averaging if a non-monotony is detected (hw pointer in
> previous (n-1) call of snd_pcm_hw_mmap_commit was higher than  current value).
> 
> For better precision, would it make sense to update the pcm->hw.ptr with 
> snd_pcm_avail call in that method? It may not be even possible in that method
> due to some locking, I really do not know. But my precision requirements are
> not very strict since I can average over long time (minutes) for the feedback
> (the clock difference is usually very small).

The value read from snd_pcm_status() should give the accurate pair of
the position and the timestamp.  You need to check the delay count as
well, which compensates the in-flight samples.


Takashi

> 
>     You should be able to skip XRUN check by changing the stop_threshold.
>     Setting it to the boundary size essentially means skipping XRUN
>     checks.
> 
> Actually if  xruns could be detected by discontinuity of the hw pointer, I
> would not need any other method.
>  
> 
>     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 a lot, I very much appreciate your help. I do not know these low-level
> alsa details. But I will gladly learn.
> 
> Pavel. 
> 
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Pavel Hofman]

On Tue, Sep 10, 2019 at 9:18 AM Takashi Iwai <tiwai@suse.de> wrote:

>
> The value read from snd_pcm_status() should give the accurate pair of
> the position and the timestamp.
>
Thanks. IIUC, if I call snd_pcm_status() in that mmap_commit method, get
data between e.g. 10 seconds, and divide the increase of status._ptr
https://github.com/michaelwu/alsa-lib/blob/afb2fbd0e554e42e51325c3197a176ea96a74203/include/sound/asound.h#L422
by increase of status.tstamp, I should get the the most precise available
soundcard rate estimate referenced to system time.



> You need to check the delay count as
> well, which compensates the in-flight samples.
>
>
I need just the rate at which the soundcard consumes/produces samples, I do
not care about time at which the sound is being produced. I do not know
exact meaning of the delay field. Is it involved in this calculation?
Please is there any exact detailed description of the status fields?

Thanks.

Pavel.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Pavel Hofman]

>
>
> divide the increase of status._ptr
> https://github.com/michaelwu/alsa-lib/blob/afb2fbd0e554e42e51325c3197a176ea96a74203/include/sound/asound.h#L422
>

Of course meant the hw_ptr
https://github.com/michaelwu/alsa-lib/blob/afb2fbd0e554e42e51325c3197a176ea96a74203/include/sound/asound.h#L423
, sorry
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Pavel Hofman]

On Tue, Sep 10, 2019 at 9:48 AM Pavel Hofman <pavhofman@gmail.com> wrote:

> Thanks. IIUC, if I call snd_pcm_status() in that mmap_commit method, get
> data between e.g. 10 seconds, and divide the increase of status._ptr
> https://github.com/michaelwu/alsa-lib/blob/afb2fbd0e554e42e51325c3197a176ea96a74203/include/sound/asound.h#L422
> by increase of status.tstamp, I should get the the most precise available
> soundcard rate estimate referenced to system time.
>
>
Upon hard-coding params->tstamp_mode = SND_PCM_TSTAMP_ENABLE in
snd_pcm_hw_sw_params, the snd_pcm_hw_status method started returning hw_ptr
and tstamp. The variance of the rate calculated by these values is
perfectly acceptable for my purpose, I will use this method. 10 sec
averages of the previously "jittery" mmap arecord:

STATUS MMAP: time: 6679.12, card = 1, device = 0, averaged samplerate:
191995.485933
STATUS MMAP: time: 6689.14, card = 1, device = 0, averaged samplerate:
191995.833616
STATUS MMAP: time: 6699.17, card = 1, device = 0, averaged samplerate:
191995.589371
STATUS MMAP: time: 6709.20, card = 1, device = 0, averaged samplerate:
191995.647669
STATUS MMAP: time: 6719.22, card = 1, device = 0, averaged samplerate:
191995.740024
STATUS MMAP: time: 6729.25, card = 1, device = 0, averaged samplerate:
191995.709675
STATUS MMAP: time: 6739.28, card = 1, device = 0, averaged samplerate:
191995.588850
STATUS MMAP: time: 6749.30, card = 1, device = 0, averaged samplerate:
191995.706994
STATUS MMAP: time: 6759.33, card = 1, device = 0, averaged samplerate:
191995.641393
STATUS MMAP: time: 6769.36, card = 1, device = 0, averaged samplerate:
191995.530104
STATUS MMAP: time: 6779.38, card = 1, device = 0, averaged samplerate:
191995.764419

Do you think there is any chance a code generating the average throughput
into some file identified with card/device IDs, all of that enabled by some
environment variable, would be acceptable into upstream pcm_hw.c? It will
be a key part of the working async usb gadget. The current version
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c
does not comply with USB-audio v. 2 specs due to the missing async feedback
endpoint, and works only for the adaptive mode (requires resampling).

Thanks,

Pavel.



> Thanks.
>
> Pavel.
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel