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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABb+yY35-o6MDcwZ2kFJYAN2dkow4T7zQJgAGnhSW27vY29cPg@mail.gmail.com>
Date:	Tue, 26 Jul 2016 14:23:14 +0530
From:	Jassi Brar <jassisinghbrar@...il.com>
To:	Ruslan Bilovol <ruslan.bilovol@...il.com>
Cc:	Clemens Ladisch <clemens@...isch.de>,
	Felipe Balbi <balbi@...nel.org>,
	Daniel Mack <zonque@...il.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

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