[alsa-devel] alsa compliance test: H340 (USB audio) playback / capture rate asymmetry bug?

[Yu-Hsuan Hsu]

Hin-Tak Leung <htl10 at users.sourceforge.net> 於 2019年9月12日 週四 下午5:34寫道：
>
> I am using Takashi Iwai's tree grafted onto mainline as DKMS ( as in
> https://github.com/HinTak/sound-usb-dkms ).
>
> Running the alsa compliance test
> commit f6167eb77d038b5b7a0d39645e7f2ae7fee6fdc0 (origin/stabilize-12464.B, origin/release-R78-12499.B)
>
> Capture all passed, but play back failed a couple, regarding the sample rate.
> It is a small head set with stereo head phone and a mic.
> ID 046d:0a38 Logitech, Inc. Headset H340
>
> The question is, for such a cheap headset, why would the playback rate and the capture rate to be different? For many applications/ usages, with a device that's most capture and playback capable, we would like the rates to agree - both pass, or both fail in the same direction?
>
> Is this a hardware or software issue? Or, somebody suggested, I haven't looked, issue with the alsa compliance test itself, possibly regarding frame counts of usb devices?
>
> detail below.
>
> 5 passed, 0 failed
> Device Information
>         Name: hw:CARD=H340
>         Stream: CAPTURE
>         Format: ['S16_LE']
>         Channels range: [2, 2]
>         Rate: [44100]
>         Period_size range: [45, 131072]
>         Buffer_size range: [90, 262144]
> Test Params
>         Set channels 2: pass
>         Set format S16_LE: pass
>         Set rate 44100: pass
> Test Rates
>         Set rate 44100: pass
> Test All Pairs
>         Set channels 2, format S16_LE, rate 44100: pass
>
> 3 passed, 2 failed
> Device Information
>         Name: hw:CARD=H340
>         Stream: PLAYBACK
>         Format: ['S16_LE']
>         Channels range: [2, 2]
>         Rate: [44100]
>         Period_size range: [45, 131072]
>         Buffer_size range: [90, 262144]
> Test Params
>         Set channels 2: pass
>         Set format S16_LE: pass
>         Set rate 44100: pass
> Test Rates
>         Set rate 44100: fail - Expected rate is 44100.000000, measure 44092.918362, difference 7.081638 > threshold 4.410000
> Test All Pairs
>         Set channels 2, format S16_LE, rate 44100: fail - Expected rate is 44100.000000, measure 44093.049192, difference 6.950808 > threshold 4.410000

Thanks for the feedback! It seems that there is a small difference
between the measured rate and the expected rate. 7 frames difference
means if we use that device to play audio about 44100/7 = 6300
seconds, it will be one second delay. (It can be fixed if an audio
service has the rate estimation or other similar handlers.) I'm not
sure it is the hardware or software issue. Maybe you can try to test
other USB devices or test it without DKMS modules and then compare the
results. Besides, in my experience, playback and capture having
different results is normal. They may  go through different paths and
codecs.

For more details, the measured rate is computed by linear regression
for each point when the device consumes audio samples. You can use
"alsa_conformance_test -P {DEVICE_NAME} -r 44100 -c 2 -f S16_LE -d 1
--debug" to see when a device consumes samples(TIME_DIFF) and how many
samples it plays(DIFF). If you want to find out the root cause, this
information may be helpful.

Feel free to contact me if you still have questions. Thanks.

Best,
Yu-Hsuan