Hin-Tak Leung <htl10@xxxxxxxxxxxxxxxxxxxxx> 於 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
