On 20-12-10 14:59:24, Ruslan Bilovol wrote: > On Thu, Dec 3, 2020 at 12:09 PM Peter Chen <peter.chen@xxxxxxx> wrote: > > > > On 20-12-02 17:04:47, Glenn Schmottlach wrote: > > > On Tue, Dec 1, 2020 at 4:43 PM Glenn Schmottlach <gschmottlach@xxxxxxxxx> wrote: > > > > Hi Ruslan - > > > > > > > > Thanks for the feedback but unfortunately I've experienced mixed > > > > results with the gadget UAC2 driver on both Windows/Linux. Let me > > > > describe my environment. My host platform is either a Linux Ubuntu > > > > 18.04 or Windows 10 laptop while the target environment is a > > > > BeagleBone Black (Linux beaglebone 5.4.74-g9574bba32a #1 PREEMPT). I'm > > > > testing two different scenarios: > > > > > > > > Scenario #1: > > > > BeagleBone Black (BBB) runs speaker-test generating a single channel > > > > (S32_LE) audio stream containing a 1KHz tone with a 48K sample rate, > > > > e.g. > > > > > > > > > speaker-test -D hw:1,0 -r 48000 -c 1 -f 1000 -F S32_LE -t sine > > > > > > > > The host laptop is running Audacity and recording the tone over the > > > > UAC2 adapter. On the Linux host the capture is correct and the tone is > > > > bit-perfect. On the Windows 10 the capture contains numerous missing > > > > samples which translates into a lot of audible pops and clicks. > > > > > > > > Scenario #2: > > > > The Linux/Windows host plays a single channel, 48K, S32_LE 1K sine > > > > tone to the target using either Audacity (on Windows) or 'aplay' (on > > > > Linux), e.g. > > > > > > > > > aplay -D hw:4,0 -c 1 -r 48000 -t wav tone_1k.wav (Linux) > > > > > > > > On the BBB target I use 'arecord' to record the tone to a RAM disk and > > > > then copy the recorded file back to the host where I can verify the > > > > quality of the recording. In both instances (e.g. using either Windows > > > > or Linux for playback) the recording on the target results in a > > > > captured file with missing samples and audible pops/clicks. In this > > > > scenario the UAC2 gadget is configured with c_sync == asynchronous. I > > > > wouldn't expect things to improve with c_sync == adaptive since you > > > > mentioned in your patch that it always reports back the nominal > > > > frequency to the host from the feedback endpoint. > > > > > > > > Do you have any suggestions that might explain (the above) behavior. > > > > Can you describe your test environment in more detail so that I can > > > > perhaps re-create it? What Linux target are you using with your tests? > > > > You mentioned you tested an 8x8 playback/capture scenario. Can you > > > > provide any details of how you performed this test and the method you > > > > used to confirm the audio quality for the capture/playback? > > > > > > > > Thanks for any insights you might be able to offer . . . > > > > > > > > Glenn > > > > > > Hi Ruslan - > > > > > > This is a follow-up from my post yesterday. I recompiled my kernel > > > *WITHOUT* your UAC2 patches and repeated Scenario #2 where the Linux > > > PC plays a single channel tone to the BeagleBone Black where it's > > > recorded with 'arecord'. Yesterday, I recorded garbled audio on the > > > target but today, without any UAC2 kernel patches, the recorded audio > > > on the target is glitch-free and appears to be bit-perfect. > > > > > > This experiment leads me to believe your patches may be inadvertently > > > corrupting the data-path. Have you been able to repeat my experiment > > > and either confirm or refute my findings? I am interested to learn > > > more how you tested your patches and whether it's something I can > > > recreate here. > > > > > > Assuming we can sort out this data corruption issue, what are your > > > thoughts on how the Linux target device can properly provide the > > > Windows feedback endpoint with real frequency updates rather than the > > > constant nominal frequency. If I understood your patch notes correctly > > > it seems this is an outstanding issue that requires additional > > > attention. I'm a bit of a noob when it comes to how this might be > > > addressed. > > > > > > Thanks for your continued insights and support . . . > > > > > > Glenn > > > > Hi Glenn & Ruslan, > > > > Do you know why WIN10 can't recognized UAC2 device if I configure the > > sample rate as 48000HZ? Configuring sample rate as 44100HZ, the playback > > function would work well at my platforms (chipidea IP), no glitch is > > heard. At WIN10, I use Windows Media Player, at board side I use command: > > That's known issue, Windows is more strict with UAC2 descriptors, try to apply > my patch "usb: gadget: f_uac2: always increase endpoint max_packet_size > by one audio slot" that I shared in this email: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Flinux-usb%2Fmsg205077.html&data=04%7C01%7Cpeter.chen%40nxp.com%7C1c037c406a47423725e008d89d0b77c1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637432019865845335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7jE6EEi4ZifLMVNgs3%2FygUkBjCrcIrtvIjX2%2FVwbwUM%3D&reserved=0 > Better than before, the Device Manager could recognize this sound device, But Windows Media Player can't play it, see attached. Meanwhile, I find your proposal patch [1] is not based on your UAC2 patch which changed bmAttributes as USB_ENDPOINT_XFER_ISOC only at descriptor. [1] https://www.spinics.net/lists/linux-usb/msg205077.html -- Thanks, Peter Chen
Attachment:
wmp_can't_play.PNG
Description: wmp_can't_play.PNG
