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: <CAB=otbTr8iRnxp6y74URZA7qWp=vLdi738cThj4uhWB7co534Q@mail.gmail.com>
Date:	Wed, 27 Jul 2016 00:38:41 +0300
From:	Ruslan Bilovol <ruslan.bilovol@...il.com>
To:	Jassi Brar <jassisinghbrar@...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 11:53 AM, Jassi Brar <jassisinghbrar@...il.com> wrote:
> 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

This approach is quite easy to implement and I though about it when
started to work on this patch series, but due to my lazyness I wanted
to get some comments before doing extra work.

> ... and hopefully very similar to (or just port
> of) the f_audio_source.c from android.

Current patch series reuses code from f_uac2 (in u_audio) and
makes it in some sense similar to f_audio_source.c.

The f_audio_source.c implementation has additional functionality
like more accurate data transferring (w.r.t timings), that can be
ported to u_audio separately.

Best regards,
Ruslan