Re: [PATCH 0/1] USB Audio Device Class 3.0 Gadget support

[Felipe Balbi]

Hi,

Ruslan Bilovol  writes:
> On Tue, Nov 7, 2017 at 3:52 AM, Ruslan Bilovol  
> wrote:
>> Hi,
>>
>> This patch adds USB Audio Device Class 3.0 [1] function
>> support to gadget subsystem.
>> I didn't add UAC3 support to legacy gadget as it will
>> make preprocessor configuration too complex (UAC3 device
>> must have two configurations for backward compatibility,
>> first is UAC1/2 and second is UAC3), yet also I'm too lazy
>> to do that and verify all possible configurations.
>>
>> For modern ConfigFS interface I'll provide my configuration
>> for testing below; testing was done on a BeagleBone Black
>> board.
>>
>> This patch depends on uac3 header files from include dir
>> which I'll post as part of ALSA host UAC3 patch and will
>> provide the link to it here.
>
> http://www.spinics.net/lists/alsa-devel/msg69071.html

Once that patch hits upstream, then we can queue this for merge window
otherwise we will just have issues and create unbisectable points in the
tree.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4 0/3] USB Audio Gadget refactoring

[Felipe Balbi]

Hi,

Ruslan Bilovol  writes:
>> Ruslan Bilovol  writes:
>>> I came to this patch series when wanted to do two things:
>>>  - use UAC1 as virtual ALSA sound card on gadget side,
>>>just like UAC2 is used so it's possible to do rate
>>>resampling
>>>  - have both playback/capture support in UAC1
>>>
>>> Since I wanted to have same behavior for both UAC1/UAC2,
>>> obviously I've got an utility part (u_audio.c) for
>>> virtual ALSA sound card handling like we have
>>> for ethernet(u_ether) or serial(u_serial) functions.
>>> Function-specific parts (f_uac1/f_uac2) became almost
>>> as storage for class-specific USB descriptors, some
>>> boilerplate for configfs, binding and few USB
>>> config request handling.
>>>
>>> Originally in RFC [1] I've posted before, there was
>>> major change to f_uac1 after that it couldn't do
>>> direct play to existing ALSA sound card anymore,
>>> representing audio on gadget side as virtual
>>> ALSA sound card where audio streams are simply
>>> sinked to and sourced from it, so it may break
>>> current usecase for some people (and that's why
>>> it was RFC).
>>>
>>> During RFC discussion, it was agreed to not touch
>>> existing f_uac1 implementation and create new one
>>> instead. This patchset (v4) introduced new function
>>> named f_uac1_acard and doesn't touch current f_uac1
>>> implementation, so people still can use old behavior
>>
>> Do you have a pointer to the original RFC discussion where this was
>> discussed? If we really *must* keep the old implementation, I would
>> rather rename that to f_uac1_legacy. Still, I find it unlikely that
>> anybody will care about the old implementation.
>
> It is on LKML (which is down for me) [1] or alternative archive [2]
>
>>
>>> Now, it's possible to use existing user-space
>>> applications for audio routing between Audio Gadget
>>> and real sound card. I personally use alsaloop tool
>>> from alsautils and have ability to create PCM
>>> loopback between two different ALSA cards using
>>> rate resampling, which was not possible with previous
>>> "direct play to ALSA card" approach in f_uac1.
>>
>> this is really good result and will actually make it a lot easier for
>> testing things out.
>>
>>> While here, also dropped redundant platform
>>> driver/device creation in f_uac2 driver (as well as
>>> didn't add "never implemented" volume/mute functionality
>>> in f_uac1 to f_uac1_acard) that made this work even
>>> easier to do.
>>>
>>> This series is tested with both legacy g_audio.ko and
>>> modern configfs approaches under Ubuntu 14.04 (UAC1 and
>>> UAC2) and under Windows7 x64 (UAC1 only) having
>>> perfect results in all cases.
>>>
>>> Comments, testing are welcome.
>>>
>>> v4 changes:
>>>  - renamed f_uac1_newapi to f_uac1_acard that is
>>>more meaningful
>>
>> I really don't get why you wanna keep both f_uac1 and f_uac1_acard. Why
>> do we need to maintain the old uac1 implementation? Why two separate
>> files?
>
> In first RFC ([1],[2]) I did exactly what you wrote here (removed
> old uac1 implementation and replaced it by new one) but got feedback
> that it will break things for existing f_uac1 legacy users and it's better to
> have separate implementation.
>
> I'm OK with dropping legacy f_uac1 implementation.
>
> Another idea I was thinking about is to implement simple in-kernel
> driver which will do the same as existing alsaloop tool userspace
> tool does (so legacy users will need to load two kernel modules
> and get same functionality). But this seems to be a wrong way,
> since It known that Linux kernel community doesn't like to take drivers
> with same functionality as existing userspace tools already have.
>
> So bottom line: since I'm not a legacy f_uac1 user, there is no
> difference for me how to handle it - remove legacy f_uac1 completely,
> rename it to f_uac1_legacy or add separate f_uac1_acard function.
>
> So if dropping of legacy f_uac1 implementation is OK for you,
> I can do it quickly in next patchset.

Personally, I don't want duplicated functionality and I think the
virtual sound card approach is much better. Then again, removing
functionality we already support is kind of odd.

Greg, Alan, what do you guys think? Do we keep a duplicated function
around or do we just tell people to rely on alsaloop? Personally, I
think we're better off with the flexibility of the virtual sound card,
what's your take?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4 0/3] USB Audio Gadget refactoring

[Felipe Balbi]

Hi,

Ruslan Bilovol  writes:
> I came to this patch series when wanted to do two things:
>  - use UAC1 as virtual ALSA sound card on gadget side,
>just like UAC2 is used so it's possible to do rate
>resampling
>  - have both playback/capture support in UAC1
>
> Since I wanted to have same behavior for both UAC1/UAC2,
> obviously I've got an utility part (u_audio.c) for
> virtual ALSA sound card handling like we have
> for ethernet(u_ether) or serial(u_serial) functions.
> Function-specific parts (f_uac1/f_uac2) became almost 
> as storage for class-specific USB descriptors, some
> boilerplate for configfs, binding and few USB
> config request handling.
>
> Originally in RFC [1] I've posted before, there was
> major change to f_uac1 after that it couldn't do
> direct play to existing ALSA sound card anymore,
> representing audio on gadget side as virtual
> ALSA sound card where audio streams are simply
> sinked to and sourced from it, so it may break
> current usecase for some people (and that's why
> it was RFC).
>
> During RFC discussion, it was agreed to not touch
> existing f_uac1 implementation and create new one
> instead. This patchset (v4) introduced new function
> named f_uac1_acard and doesn't touch current f_uac1
> implementation, so people still can use old behavior

Do you have a pointer to the original RFC discussion where this was
discussed? If we really *must* keep the old implementation, I would
rather rename that to f_uac1_legacy. Still, I find it unlikely that
anybody will care about the old implementation.

> Now, it's possible to use existing user-space
> applications for audio routing between Audio Gadget
> and real sound card. I personally use alsaloop tool
> from alsautils and have ability to create PCM
> loopback between two different ALSA cards using
> rate resampling, which was not possible with previous
> "direct play to ALSA card" approach in f_uac1. 

this is really good result and will actually make it a lot easier for
testing things out.

> While here, also dropped redundant platform
> driver/device creation in f_uac2 driver (as well as
> didn't add "never implemented" volume/mute functionality
> in f_uac1 to f_uac1_acard) that made this work even
> easier to do.
>
> This series is tested with both legacy g_audio.ko and
> modern configfs approaches under Ubuntu 14.04 (UAC1 and
> UAC2) and under Windows7 x64 (UAC1 only) having
> perfect results in all cases.
>
> Comments, testing are welcome.
>
> v4 changes:
>  - renamed f_uac1_newapi to f_uac1_acard that is
>more meaningful

I really don't get why you wanna keep both f_uac1 and f_uac1_acard. Why
do we need to maintain the old uac1 implementation? Why two separate
files?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4 2/3] usb: gadget: f_uac2: split out audio core

[Felipe Balbi]

Hi,

Ruslan Bilovol  writes:
> Abstract the peripheral side ALSA sound card code from
> the f_uac2 function into a component that can be called
> by various functions, so the various flavors can be split
> apart and selectively reused.
>
> Visible changes:
>  - add uac_params structure to pass audio paramteres for
>g_audio_setup
>  - make ALSA sound card's name configurable
>  - add [in/out]_ep_maxpsize
>  - allocate snd_uac_chip structure during g_audio_setup
>  - add u_audio_[start/stop]_[capture/playback] functions
>
> Signed-off-by: Ruslan Bilovol 

this doesn't apply on testing/next, care to rebase?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 51/53] usb: fix the comment with regards to DocBook

[Felipe Balbi]

Mauro Carvalho Chehab  writes:

> The USB gadget documentation is not at DocBook anymore.
> The main file was converted to ReST, and stored at
> Documentation/driver-api/usb/gadget.rst, but there are
> still several plain text files related to gadget under
> Documentation/usb.
>
> So, be generic and just mention documentation
> without specifying where it is.
>
> Signed-off-by: Mauro Carvalho Chehab 

I'm adding this to my queue. If this is part of a larger series, let me
know and I'll drop it :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v3 0/3] USB Audio Gadget refactoring

[Felipe Balbi]

Hi,

Ruslan Bilovol  writes:
> I came to this patch series when wanted to do two things:
>  - use UAC1 as virtual ALSA sound card on gadget side,
>just like UAC2 is used so it's possible to do rate
>resampling
>  - have both playback/capture support in UAC1
>
> Since I wanted to have same behavior for both UAC1/UAC2,
> obviously I've got an utility part (u_audio.c) for
> virtual ALSA sound card handling like we have
> for ethernet(u_ether) or serial(u_serial) functions.
> Function-specific parts (f_uac1/f_uac2) became almost 
> as storage for class-specific USB descriptors, some
> boilerplate for configfs, binding and few USB
> config request handling.
>
> Originally in RFC [1] I've posted before, there was
> major change to f_uac1 after that it couldn't do
> direct play to existing ALSA sound card anymore,
> representing audio on gadget side as virtual
> ALSA sound card where audio streams are simply
> sinked to and sourced from it, so it may break
> current usecase for some people (and that's why
> it was RFC).
>
> During RFC discussion, it was agreed to not touch
> existing f_uac1 implementation and create new one
> instead. This patchset (v2) introduced new function
> named f_uac1_newapi and doesn't touch current f_uac1
> implementation, so people still can use old behavior
>
> Now, it's possible to use existing user-space
> applications for audio routing between Audio Gadget
> and real sound card. I personally use alsaloop tool
> from alsautils and have ability to create PCM
> loopback between two different ALSA cards using
> rate resampling, which was not possible with previous
> "direct play to ALSA card" approach in f_uac1. 
>
> While here, also dropped redundant platform
> driver/device creation in f_uac2 driver (as well as
> didn't add "never implemented" volume/mute functionality
> in f_uac1 to f_uac1_newapi) that made this work even
> easier to do.
>
> This series is tested with both legacy g_audio.ko and
> modern configfs approaches under Ubuntu 14.04 (UAC1 and
> UAC2) and under Windows7 x64 (UAC1 only) having
> perfect results in all cases.
>
> Comments, testing are welcome.
>
> v3 changes:
>  - renamed u_audio exported symbols so they don't
>conflict with old f_uac1 if both are built-in.
>
> v2 changes:
>  - do not touch f_uac1, instead created f_uac1_newapi

f_uac1_newapi What the hell man? :-s

Sure you can't change f_uac1 to newapi without introducing userland
visible changes? We really don't want to add another copy of f_uac1,
sorry.


-- 
balbi


signature.asc
Description: PGP signature