Re: [PATCH 0/3] UAC2 Gadget: feedback endpoint support

[Ruslan Bilovol <ruslan.bilovol@gmail.com>]

On Thu, Dec 3, 2020 at 12:09 PM Peter Chen <peter.chen@nxp.com> wrote:
>
> On 20-12-02 17:04:47, Glenn Schmottlach wrote:
> > On Tue, Dec 1, 2020 at 4:43 PM Glenn Schmottlach <gschmottlach@gmail.com> 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://www.spinics.net/lists/linux-usb/msg205077.html

Thanks,
Ruslan