On Tue, Jul 26, 2016 at 3:02 PM, Krzysztof Opasiak <k.opasiak@xxxxxxxxxxx> wrote: > > > On 07/26/2016 10:53 AM, Jassi Brar wrote: >> On Tue, Jul 26, 2016 at 7:01 AM, Ruslan Bilovol >> <ruslan.bilovol@xxxxxxxxx> wrote: >>> On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote: >>>>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >>>>>> <ruslan.bilovol@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
