Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1450548

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

From Krzysztof Opasiak <k.opasiak@samsung.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 0/5] USB Audio Gadget refactoring
Date 2016-07-26 14:10 +0200
Message-ID <rZ9ln-1M4-1@gated-at.bofh.it> (permalink)
References (1 earlier) <rHGIN-64G-17@gated-at.bofh.it> <rUWwp-6vr-5@gated-at.bofh.it> <rV6cp-4aE-13@gated-at.bofh.it> <rYZvH-3YA-5@gated-at.bofh.it> <rZ6nw-8eF-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring Ruslan Bilovol <ruslan.bilovol@gmail.com> - 2016-07-26 03:40 +0200
  Re: [RFC PATCH 0/5] USB Audio Gadget refactoring Clemens Ladisch <clemens@ladisch.de> - 2016-07-26 10:10 +0200
    Re: [RFC PATCH 0/5] USB Audio Gadget refactoring Ruslan Bilovol <ruslan.bilovol@gmail.com> - 2016-07-26 23:30 +0200
  Re: [RFC PATCH 0/5] USB Audio Gadget refactoring Jassi Brar <jassisinghbrar@gmail.com> - 2016-07-26 11:00 +0200
    Re: [RFC PATCH 0/5] USB Audio Gadget refactoring Krzysztof Opasiak <k.opasiak@samsung.com> - 2016-07-26 14:10 +0200
      Re: [RFC PATCH 0/5] USB Audio Gadget refactoring Ruslan Bilovol <ruslan.bilovol@gmail.com> - 2016-07-27 00:00 +0200
    Re: [RFC PATCH 0/5] USB Audio Gadget refactoring Ruslan Bilovol <ruslan.bilovol@gmail.com> - 2016-07-26 23:40 +0200

csiph-web