Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

[Krzysztof Opasiak <k.opasiak@samsung.com>]

On 07/26/2016 10:53 AM, Jassi Brar wrote:
> On Tue, Jul 26, 2016 at 7:01 AM, Ruslan Bilovol
> <ruslan.bilovol@gmail.com> wrote:
>> On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol
>>>>> <ruslan.bilovol@gmail.com> 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.

Best regards,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics