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

[Ruslan Bilovol]

Hi Felipe,

On Mon, Aug 29, 2016 at 11:05 AM, Felipe Balbi  wrote:
>
> 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

Yes, sometimes it's difficult to create laconic name that shows
difference to old f_uac1. We can name it alternatively
"f_uac1_alsa" or maybe anybody else have good idea here.
I just wanted to show here that it's f_uac1 with completely
different functionality (expose ALSA card to userspace
instead of consuming existing one)

>
> 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.

Do you mean same f_uac1.ko module will be able to use existing
ALSA card (old api) and create it own as well (new api) in the same
time at runtime?

By the way, while I understand your desire to not introduce
userland visible changes, in this particular case it doesn't
make much sense, since that's, again, two opposite approaches
to consume and transfer data to userspace
Moreover, now old f_uac1 and new f_uac1_newapi have
different functionality exposed to host (first one has only
playback, second one - playback+capture), so even USB
descriptors are different.

So userspace compatibility in this case will make f_uac1
driver too difficult to maintain and add new functionality.

So I prefer to keep the new version of f_uac1 function
and let it move forward with new features.

Best regards,
Ruslan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[PATCH v3 0/3] USB Audio Gadget refactoring

[Ruslan Bilovol]

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
 - added documentation for f_uac1_newapi
 - rebased on top of v4.8-rc1

[1] https://lkml.org/lkml/2016/5/23/649

Ruslan Bilovol (3):
  usb: gadget: f_uac2: remove platform driver/device creation
  usb: gadget: f_uac2: split out audio core
  usb: gadget: add f_uac1 variant based on new u_audio api

 .../ABI/testing/configfs-usb-gadget-uac1_newapi|  12 +
 Documentation/usb/gadget-testing.txt   |  41 ++
 drivers/usb/gadget/Kconfig |  25 +
 drivers/usb/gadget/function/Makefile   |   3 +
 drivers/usb/gadget/function/f_uac1_newapi.c| 795 +
 drivers/usb/gadget/function/f_uac2.c   | 778 +++-
 drivers/usb/gadget/function/u_audio.c  | 632 
 drivers/usb/gadget/function/u_audio.h  |  93 +++
 drivers/usb/gadget/function/u_uac1_newapi.h|  39 +
 drivers/usb/gadget/legacy/Kconfig  |  14 +-
 drivers/usb/gadget/legacy/audio.c  |  52 ++
 11 files changed, 1801 insertions(+), 683 deletions(-)
 create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-uac1_newapi
 create mode 100644 drivers/usb/gadget/function/f_uac1_newapi.c
 create mode 100644 drivers/usb/gadget/function/u_audio.c
 create mode 100644 drivers/usb/gadget/function/u_audio.h
 create mode 100644 drivers/usb/gadget/function/u_uac1_newapi.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html