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]
Date:	Tue, 26 Jul 2016 14:02:14 +0200
From:	Krzysztof Opasiak <k.opasiak@...sung.com>
To:	Jassi Brar <jassisinghbrar@...il.com>,
	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 07/26/2016 10:53 AM, Jassi Brar 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 ... 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

Powered by blists - more mailing lists