From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161242AbcGZVzW (ORCPT ); Tue, 26 Jul 2016 17:55:22 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:35709 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161175AbcGZVzT (ORCPT ); Tue, 26 Jul 2016 17:55:19 -0400 MIME-Version: 1.0 In-Reply-To: <57975146.5090501@samsung.com> References: <1464047440-20496-1-git-send-email-ruslan.bilovol@gmail.com> <57975146.5090501@samsung.com> From: Ruslan Bilovol Date: Wed, 27 Jul 2016 00:55:17 +0300 Message-ID: Subject: Re: [RFC PATCH 0/5] USB Audio Gadget refactoring To: Krzysztof Opasiak Cc: Jassi Brar , Clemens Ladisch , Felipe Balbi , Daniel Mack , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 26, 2016 at 3:02 PM, Krzysztof Opasiak wrote: > > > On 07/26/2016 10:53 AM, Jassi Brar wrote: >> On Tue, Jul 26, 2016 at 7:01 AM, Ruslan Bilovol >> wrote: >>> On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch wrote: >>>>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >>>>>> wrote: >>>>>>> it may break current usecase for some people >>>> >>>> And what are the benefits that justify breaking the kernel API? >>> >>> >>> Main limitation with current f_uac1 design is - it can be used only on systems >>> with real ALSA card present and can have only exact number of >>> channels / sampling rate as sink card has. >>> Yet it is not flexible - can't do audio processing between f_uac1 and the card. >>> Also if someone wants to bind f_uac1 it to another sound card he has to >>> unload g_audio or reconfigure it through configfs - that means USB >>> reenumeration on host device. >>> >>> If you have a "virtual sound card", audio processing is done in userspace >>> and is more flexible. You even don't need to have a real sound card and >>> can use some userspace application for playing/capturing audio samples. >>> Moreover, existing f_uac2 (that is USB Audio Class 2.0 function >>> implementation) already uses approach of "virtual sound card" >>> >> While I agree the virtual sound card approach is the right way, I am >> not sure if we should break the userspace api that the existing UAC1 >> driver exposes. Maybe we should add another virtual-sound-card >> exposing UAC1 driver ... and hopefully very similar to (or just port >> of) the f_audio_source.c from android. > > Definitely agree with this opinion. I don't see any benefits of breaking > the API here instead of adding just another USB function. Maybe even > some pieces of code could be shared with f_uac1.c but I think that this > should be a brand new function. > So if we want to keep old API working, easiest (and cleanest) way is to create a new f_uac1.c version and kconfig symbol, for example f_uac1_newapi.c and CONFIG_USB_F_UAC1_NEWAPI There is no sence to share some pieces of code with f_uac1.c just because it is changed too drastically. So I'll implement it in v2 if there is no any objections Best regards, Ruslan Bilovol