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

[Jassi Brar]

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.