From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932641AbcH2IFt (ORCPT ); Mon, 29 Aug 2016 04:05:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:18185 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932610AbcH2IFo (ORCPT ); Mon, 29 Aug 2016 04:05:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,595,1464678000"; d="asc'?scan'208";a="2197993" From: Felipe Balbi To: Ruslan Bilovol Cc: Daniel Mack , Jassi Brar , Clemens Ladisch , Jonathan Corbet , Greg Kroah-Hartman , Peter Chen , linux-usb@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 0/3] USB Audio Gadget refactoring In-Reply-To: <1471466955-30898-1-git-send-email-ruslan.bilovol@gmail.com> References: <1471466955-30898-1-git-send-email-ruslan.bilovol@gmail.com> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.1 (x86_64-pc-linux-gnu) Date: Mon, 29 Aug 2016 11:05:20 +0300 Message-ID: <874m64dmpr.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-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, 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=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 (v2) introduced new function > named f_uac1_newapi and doesn't touch current f_uac1 > implementation, so people still can use old behavior > > 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 > > 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_newapi) 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. > > v3 changes: > - renamed u_audio exported symbols so they don't > conflict with old f_uac1 if both are built-in. > > v2 changes: > - do not touch f_uac1, instead created f_uac1_newapi f_uac1_newapi???? What the hell man? :-s Sure you can't change f_uac1 to newapi without introducing userland visible changes? We really don't want to add another copy of f_uac1, sorry. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXw+zAAAoJEIaOsuA1yqREzx4P/ih9k95YP8SNYMmAcwJh/5IN dHpVruKmfba/iatx9y7WehOngYsDItA9M24vg56eovOWTzxGhvc7n9SwmkZ7Ckta TL+vVMueRQQ5sOJ9Fqe+L5Rf7xwlAV9imyt2EeuOZOrvUy6PsmmwR3dpUNvBq3ZE Fl14oBPuqANbiBqlq/UPObBylF0fGSCxW7n2V1JPjrANJ1pkDBtHxoeY0fmqgGI3 pH5arB58ZOV4n+Pv8v1EKCRG6Y4O8g3I34sOQ96JuF9U9TRai5ln0RSjcVrHnWAa Pg5gnL/GvE+d69kQxtt3IhkDx5D4yEvR5AceMIuu6Ft0KpIYMhXWdC2+7MqVJPnP wq0yJ4xmEhryTQL59Ffvp9NZCtV8juCe7oC836cVI0gdlhS46FhK39LgfnKMnyk8 WdrxT8czjRsYpqU3iX/TFptYgMkLq1qE+tw7c7gWC8sZ+dxpv0aite75DpO+45CK VfiSqxHYPSwZLFZl3cJEQQpoajojKN4QYHl3L3nlSohKbm1aAvgIpq3oKLGsCxjv o0dq8e3Z+qDcFqG9vMCOjhpnEdS6Uto+qhbxbGYenztx5uT32yrso6ZnAHTW2fXO q8Af68p1UNVvt4zRDK9Z0Lprlg2DqomGTuv+mfaEBEz3IBMBGZrAL7rUaiUN/KyY 1tro8PMDT/a9KV9ybGWC =LOx4 -----END PGP SIGNATURE----- --=-=-=--