Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751860AbdFEJXE (ORCPT ); Mon, 5 Jun 2017 05:23:04 -0400 Received: from mga05.intel.com ([192.55.52.43]:18776 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751272AbdFEJXB (ORCPT ); Mon, 5 Jun 2017 05:23:01 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,300,1493708400"; d="asc'?scan'208";a="864639029" From: Felipe Balbi To: Ruslan Bilovol , Greg KH , Alan Stern Cc: Daniel Mack , Jassi Brar , Clemens Ladisch , Jonathan Corbet , Greg Kroah-Hartman , Peter Chen , Julian Scheel , "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: References: <1495060654-31126-1-git-send-email-ruslan.bilovol@gmail.com> <87inkevi87.fsf@linux.intel.com> Date: Mon, 05 Jun 2017 12:22:13 +0300 Message-ID: <87h8zuu6uy.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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5456 Lines: 133 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Ruslan Bilovol writes: >> Ruslan Bilovol 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 >>> 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. > > It is on LKML (which is down for me) [1] or alternative archive [2] > >> >>> 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. >> >> 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? > > In first RFC ([1],[2]) I did exactly what you wrote here (removed > old uac1 implementation and replaced it by new one) but got feedback > that it will break things for existing f_uac1 legacy users and it's bette= r to > have separate implementation. > > I'm OK with dropping legacy f_uac1 implementation. > > Another idea I was thinking about is to implement simple in-kernel > driver which will do the same as existing alsaloop tool userspace > tool does (so legacy users will need to load two kernel modules > and get same functionality). But this seems to be a wrong way, > since It known that Linux kernel community doesn't like to take drivers > with same functionality as existing userspace tools already have. > > So bottom line: since I'm not a legacy f_uac1 user, there is no > difference for me how to handle it - remove legacy f_uac1 completely, > rename it to f_uac1_legacy or add separate f_uac1_acard function. > > So if dropping of legacy f_uac1 implementation is OK for you, > I can do it quickly in next patchset. Personally, I don't want duplicated functionality and I think the virtual sound card approach is much better. Then again, removing functionality we already support is kind of odd. Greg, Alan, what do you guys think? Do we keep a duplicated function around or do we just tell people to rely on alsaloop? Personally, I think we're better off with the flexibility of the virtual sound card, what's your take? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlk1IsUACgkQzL64meEa mQabkhAAleQCXzv7kEz5+0sVYI1MY28mj0zLk0VUKNcN7PrKA4zyx8qXMBfzFkPq fuAiuw5RTVyt5TpHQXkoi3OBte+2OZJODEKjo9OosM7TjuiLmIvtK5BTtBlxamdo RJjoQmqTg8SLucZ8YlDE8aQa/pZPd1mFZddMIG6ldUQESKRvCCpsxrarq6C5q41t kMgV9/yv51BXTY2l3p1/yEVP8l5xrS/jhkFHXW5dXYcIeLVEbRTdCjkG03DgqMgK 3f7BVts0W8H8b4oyWGvW8CZ8fVYJo3eTq11EAQOwM1oM4PLjf/Tm/8N5r1vs4paC q9Cpx1ZFzywuJjRc02FOukgbz1CykWidjwRif9d/tfLu0ZLGsYSWyjLEpbKEt21D 7FfuPdWe7hgllB/55irujuDuJfRJu1QEvBHks1Yx8t5iIe76bA/Br1oFEloW1IhX 8cEbPfGnMjZ1/BiFwwvs7wAplwV8ne1o/kA5GRtjXSVUmagoiDbSaJaXSinV3U0K Xs2lPEse/ZnTD0wAPe5G7N0TGNmZxS14q6RNC02vbrQ1bAord8cUgIXcqVCLZjqY 3qkSouvK2j0vCf0ueschFPKprMPvGX0H6ntBxwr7rmu1MiC0nSiQjunJw8s5eH7Q PdSF/p+g4YpoHGunPneB1q6fgbMUu+J1KaRS6IZyBQaV2TvFOVY= =kZrw -----END PGP SIGNATURE----- --=-=-=--