From: Felipe Balbi <balbi@kernel.org>
To: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>, Jassi Brar <jassisinghbrar@gmail.com>,
        Clemens Ladisch <clemens@ladisch.de>, Jonathan Corbet <corbet@lwn.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Peter Chen <hzpeterchen@gmail.com>, Julian Scheel <julian@jusst.de>,
        linux-usb@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/3] USB Audio Gadget refactoring
In-Reply-To: <1495060654-31126-1-git-send-email-ruslan.bilovol@gmail.com>
References: <1495060654-31126-1-git-send-email-ruslan.bilovol@gmail.com>
Date: Fri, 02 Jun 2017 12:42:16 +0300
Message-ID: <87inkevi87.fsf@linux.intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3750
Lines: 98

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi,

Ruslan Bilovol <ruslan.bilovol@gmail.com> writes:
> I came to this patch series when wanted to do two things:
>  - use UAC1 as virtual ALSA sound card on gadget side,
>    just like UAC2 is used so it's possible to do rate
>    resampling
>  - have both playback/capture support in UAC1
>
> Since I wanted to have same behavior for both UAC1/UAC2,
> obviously I've got an utility part (u_audio.c) for
> virtual ALSA sound card handling like we have
> for ethernet(u_ether) or serial(u_serial) functions.
> Function-specific parts (f_uac1/f_uac2) became almost=20
> as storage for class-specific USB descriptors, some
> boilerplate for configfs, binding and few USB
> config request handling.
>
> Originally in RFC [1] I've posted before, there was
> major change to f_uac1 after that it couldn't do
> direct play to existing ALSA sound card anymore,
> representing audio on gadget side as virtual
> ALSA sound card where audio streams are simply
> sinked to and sourced from it, so it may break
> current usecase for some people (and that's why
> it was RFC).
>
> During RFC discussion, it was agreed to not touch
> existing f_uac1 implementation and create new one
> instead. This patchset (v4) introduced new function
> named f_uac1_acard and doesn't touch current f_uac1
> implementation, so people still can use old behavior

Do you have a pointer to the original RFC discussion where this was
discussed? If we really *must* keep the old implementation, I would
rather rename that to f_uac1_legacy. Still, I find it unlikely that
anybody will care about the old implementation.

> Now, it's possible to use existing user-space
> applications for audio routing between Audio Gadget
> and real sound card. I personally use alsaloop tool
> from alsautils and have ability to create PCM
> loopback between two different ALSA cards using
> rate resampling, which was not possible with previous
> "direct play to ALSA card" approach in f_uac1.=20

this is really good result and will actually make it a lot easier for
testing things out.

> While here, also dropped redundant platform
> driver/device creation in f_uac2 driver (as well as
> didn't add "never implemented" volume/mute functionality
> in f_uac1 to f_uac1_acard) that made this work even
> easier to do.
>
> This series is tested with both legacy g_audio.ko and
> modern configfs approaches under Ubuntu 14.04 (UAC1 and
> UAC2) and under Windows7 x64 (UAC1 only) having
> perfect results in all cases.
>
> Comments, testing are welcome.
>
> v4 changes:
>  - renamed f_uac1_newapi to f_uac1_acard that is
>    more meaningful

I really don't get why you wanna keep both f_uac1 and f_uac1_acard. Why
do we need to maintain the old uac1 implementation? Why two separate
files?

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlkxMvgACgkQzL64meEa
mQaY2Q//ejegWEKA6AvTdYdsD1o3MPewspvnCLYBSLFDkTmiL0abmU6h5rns0pad
Oi5q4Svv5jYjuRgJmmtEyzQJYdM95RjLtX06IhRnDmi4hDCOyg2CUSOi2zP6AwRa
7UQkc5KE3BecEIhVHh9iRir7NTlVdcOe3c7iXqWkbPuJunm+0vWy9+ckVWjAr9uv
TTUN0yxHSGLLa0cFBRWG+aG+BeiptNEy78ANJtKdx5I+Fhyw9q6TcMlRvqt116Z3
LK0POkj09FNBrjDpOJ17CeVzTOFMbGCGrZ1U5lTseP6gSw6Ex8DWqf4nFLYDT5qM
X1D53kRr5bmDtUVYsJBYUT4h9DXK2BQl2NX8V2E9rlvvItk2SjyHYSduu647OnwE
7Kj5QTCXaxZIfixVs1mwmxs051u20GkeR7VPAmXyvfXvXv16l6mOupk1V9Zc269i
TmK5dbRN67NpufgtLReJLuLt6crB+BLiGL0yMjy6C+AP+4+LEi6x0rVZm4xVv1Px
VRAKd8lgAkJRYuPUPEKKvDsWNM9kjB4BMC1bIG5BVIsxcDNKEPiw5A6xsyt+8Cw3
Bxc6gdTrUikJATHtY+3HDsqB0KBFHhxrlo2nsVMNQ50fr+r5NUxJNk0mbuxksHe5
xFXzCmvvrGy3+Z+sf8KD3E2H/r9Dw0PpiiLvGzcdR96rlDzSakA=
=lQoe
-----END PGP SIGNATURE-----
--=-=-=--