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

[Ruslan Bilovol]

On Tue, Aug 16, 2016 at 12:16 PM, Peter Chen  wrote:
> On Sun, Aug 14, 2016 at 01:21:21AM +0300, Ruslan Bilovol wrote:
>> 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.
>>
>
> I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
> kernel w/o your patch set. The windows7 can't install the driver
> successfully and the playback shows underrun (using local codec)
> using Linux host.

As Clemens already pointed, Windows 7 doesn't have
UAC2 support "out of the box". That's why I tested only UAC1 on it.

>
> Do you use the unchanged mainline kernel?

Yes, this patchset is based on v4.8-rc1 tag.

>
> My configfs parameters like below:
> echo 2 > functions/uac2.1/c_ssize
> echo 48000 > functions/uac2.1/c_srate
> echo 3 > functions/uac2.1/c_chmask
> echo 2 > functions/uac2.1/p_ssize
> echo 48000 > functions/uac2.1/p_srate
> echo 3 > functions/uac2.1/p_chmask

I usually don't change these (use default values here)

I use BeagleBone Black for this patchset verification.
Here is how I configure it through configfs:

uac_2

mkdir cfg
mount none cfg -t configfs
mkdir cfg/usb_gadget/g1
cd cfg/usb_gadget/g1
mkdir configs/c.1
mkdir functions/uac2.0
mkdir strings/0x409
mkdir configs/c.1/strings/0x409
echo 0x0101 > idProduct
echo 0x1d6b > idVendor
echo my-serial-num > strings/0x409/serialnumber
echo my-manufacturer > strings/0x409/manufacturer
echo "Test gadget" > strings/0x409/product
echo "Conf 1" > configs/c.1/strings/0x409/configuration
echo 120 > configs/c.1/MaxPower
ln -s functions/uac2.0 configs/c.1
echo musb-hdrc.0.auto > UDC


uac_1 (new api)
-
mkdir cfg
mount none cfg -t configfs
mkdir cfg/usb_gadget/g1
cd cfg/usb_gadget/g1
mkdir configs/c.1
mkdir functions/uac1_newapi.0
mkdir strings/0x409
mkdir configs/c.1/strings/0x409
echo 0x0101 > idProduct
echo 0x1d6b > idVendor
echo my-serial-num > strings/0x409/serialnumber
echo my-manufacturer > strings/0x409/manufacturer
echo "Test gadget" > strings/0x409/product
echo "Conf 1" > configs/c.1/strings/0x409/configuration
echo 120 > configs/c.1/MaxPower
ln -s functions/uac1_newapi.0 configs/c.1
echo musb-hdrc.0.auto > UDC


>
>
> Console output:
> root@imx6qdlsolo:~# arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &
> [1] 859
> root@imx6qdlsolo:~#
> root@imx6qdlsolo:~# Recording WAVE 'stdin' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Stereo
> Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz,
> Stereo
> underrun!!! (at least 36.634 ms long)
> underrun!!! (at least 36.117 ms long)
> underrun!!! (at least 42.132 ms long)
> underrun!!! (at least 40.157 ms long)
> underrun!!! (at least 36.207 ms long)
> underrun!!! (at least 39.173 ms long)
> underrun!!! (at least 36.119 ms long)
> underrun!!! (at least 36.164 ms long)
>
>

I use alsaloop tool that is more powerful than just arecord/aplay
through pipe. It is compiled with libsamplerate so can do
resampling on the 

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

[Ruslan Bilovol]

On Tue, Aug 16, 2016 at 12:16 PM, Peter Chen  wrote:
> On Sun, Aug 14, 2016 at 01:21:21AM +0300, Ruslan Bilovol wrote:
>> 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.
>>
>
> I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
> kernel w/o your patch set. The windows7 can't install the driver
> successfully and the playback shows underrun (using local codec)
> using Linux host.

As Clemens already pointed, Windows 7 doesn't have
UAC2 support "out of the box". That's why I tested only UAC1 on it.

>
> Do you use the unchanged mainline kernel?

Yes, this patchset is based on v4.8-rc1 tag.

>
> My configfs parameters like below:
> echo 2 > functions/uac2.1/c_ssize
> echo 48000 > functions/uac2.1/c_srate
> echo 3 > functions/uac2.1/c_chmask
> echo 2 > functions/uac2.1/p_ssize
> echo 48000 > functions/uac2.1/p_srate
> echo 3 > functions/uac2.1/p_chmask

I usually don't change these (use default values here)

I use BeagleBone Black for this patchset verification.
Here is how I configure it through configfs:

uac_2

mkdir cfg
mount none cfg -t configfs
mkdir cfg/usb_gadget/g1
cd cfg/usb_gadget/g1
mkdir configs/c.1
mkdir functions/uac2.0
mkdir strings/0x409
mkdir configs/c.1/strings/0x409
echo 0x0101 > idProduct
echo 0x1d6b > idVendor
echo my-serial-num > strings/0x409/serialnumber
echo my-manufacturer > strings/0x409/manufacturer
echo "Test gadget" > strings/0x409/product
echo "Conf 1" > configs/c.1/strings/0x409/configuration
echo 120 > configs/c.1/MaxPower
ln -s functions/uac2.0 configs/c.1
echo musb-hdrc.0.auto > UDC


uac_1 (new api)
-
mkdir cfg
mount none cfg -t configfs
mkdir cfg/usb_gadget/g1
cd cfg/usb_gadget/g1
mkdir configs/c.1
mkdir functions/uac1_newapi.0
mkdir strings/0x409
mkdir configs/c.1/strings/0x409
echo 0x0101 > idProduct
echo 0x1d6b > idVendor
echo my-serial-num > strings/0x409/serialnumber
echo my-manufacturer > strings/0x409/manufacturer
echo "Test gadget" > strings/0x409/product
echo "Conf 1" > configs/c.1/strings/0x409/configuration
echo 120 > configs/c.1/MaxPower
ln -s functions/uac1_newapi.0 configs/c.1
echo musb-hdrc.0.auto > UDC


>
>
> Console output:
> root@imx6qdlsolo:~# arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &
> [1] 859
> root@imx6qdlsolo:~#
> root@imx6qdlsolo:~# Recording WAVE 'stdin' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Stereo
> Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz,
> Stereo
> underrun!!! (at least 36.634 ms long)
> underrun!!! (at least 36.117 ms long)
> underrun!!! (at least 42.132 ms long)
> underrun!!! (at least 40.157 ms long)
> underrun!!! (at least 36.207 ms long)
> underrun!!! (at least 39.173 ms long)
> underrun!!! (at least 36.119 ms long)
> underrun!!! (at least 36.164 ms long)
>
>

I use alsaloop tool that is more powerful than just arecord/aplay
through pipe. It is compiled with libsamplerate so can do
resampling on the fly. Also it has few 

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

[Clemens Ladisch]

Peter Chen wrote:
> On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote:
>> Windows does not have UAC2 support.
>
> Thanks, before windows7 or all windows versions have no UAC2 support?

So far, no version has it.


Regards,
Clemens

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

[Clemens Ladisch]

Peter Chen wrote:
> On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote:
>> Windows does not have UAC2 support.
>
> Thanks, before windows7 or all windows versions have no UAC2 support?

So far, no version has it.


Regards,
Clemens

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

[Peter Chen]

On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote:
> Peter Chen wrote:
> > I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
> > kernel w/o your patch set. The windows7 can't install the driver
> > successfully
> 
> Windows does not have UAC2 support.
> 

Thanks, before windows7 or all windows versions have no UAC2 support?

> > and the playback shows underrun (using local codec)
> > using Linux host.
> 
> > # arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &
> 
> The clocks of the two devices are not synchronized.
> 
> In the ALSA API, a PCM device is assumed to have its own clock, so it is
> not possible to synchronize the USB gadget to the actual sound device
> without some separate mechanism (like the old uac1 gadget probably has).
> 

The reason for immediate underrun is the small USB request number.
The default request number of USB is 2 for UAC2, but 256 for
UAC1. I have a internal 4.1.y version which works fine for UAC2 with
only two requests, maybe ALSA has changed some recently.

Yes, we need feedback endpoint to adjust sample rate for mismatch
clocks between USB and codec.

-- 

Best Regards,
Peter Chen

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

[Peter Chen]

On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote:
> Peter Chen wrote:
> > I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
> > kernel w/o your patch set. The windows7 can't install the driver
> > successfully
> 
> Windows does not have UAC2 support.
> 

Thanks, before windows7 or all windows versions have no UAC2 support?

> > and the playback shows underrun (using local codec)
> > using Linux host.
> 
> > # arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &
> 
> The clocks of the two devices are not synchronized.
> 
> In the ALSA API, a PCM device is assumed to have its own clock, so it is
> not possible to synchronize the USB gadget to the actual sound device
> without some separate mechanism (like the old uac1 gadget probably has).
> 

The reason for immediate underrun is the small USB request number.
The default request number of USB is 2 for UAC2, but 256 for
UAC1. I have a internal 4.1.y version which works fine for UAC2 with
only two requests, maybe ALSA has changed some recently.

Yes, we need feedback endpoint to adjust sample rate for mismatch
clocks between USB and codec.

-- 

Best Regards,
Peter Chen

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

[Clemens Ladisch]

Peter Chen wrote:
> I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
> kernel w/o your patch set. The windows7 can't install the driver
> successfully

Windows does not have UAC2 support.

> and the playback shows underrun (using local codec)
> using Linux host.

> # arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &

The clocks of the two devices are not synchronized.

In the ALSA API, a PCM device is assumed to have its own clock, so it is
not possible to synchronize the USB gadget to the actual sound device
without some separate mechanism (like the old uac1 gadget probably has).


Regards,
Clemens

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

[Clemens Ladisch]

Peter Chen wrote:
> I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
> kernel w/o your patch set. The windows7 can't install the driver
> successfully

Windows does not have UAC2 support.

> and the playback shows underrun (using local codec)
> using Linux host.

> # arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &

The clocks of the two devices are not synchronized.

In the ALSA API, a PCM device is assumed to have its own clock, so it is
not possible to synchronize the USB gadget to the actual sound device
without some separate mechanism (like the old uac1 gadget probably has).


Regards,
Clemens

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

[Peter Chen]

On Sun, Aug 14, 2016 at 01:21:21AM +0300, Ruslan Bilovol wrote:
> 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.
> 

I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
kernel w/o your patch set. The windows7 can't install the driver
successfully and the playback shows underrun (using local codec)
using Linux host.

Do you use the unchanged mainline kernel?

My configfs parameters like below:
echo 2 > functions/uac2.1/c_ssize
echo 48000 > functions/uac2.1/c_srate
echo 3 > functions/uac2.1/c_chmask
echo 2 > functions/uac2.1/p_ssize
echo 48000 > functions/uac2.1/p_srate
echo 3 > functions/uac2.1/p_chmask


Console output:
root@imx6qdlsolo:~# arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &
[1] 859
root@imx6qdlsolo:~# 
root@imx6qdlsolo:~# Recording WAVE 'stdin' : Signed 16 bit Little
Endian, Rate 48000 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
underrun!!! (at least 36.634 ms long)
underrun!!! (at least 36.117 ms long)
underrun!!! (at least 42.132 ms long)
underrun!!! (at least 40.157 ms long)
underrun!!! (at least 36.207 ms long)
underrun!!! (at least 39.173 ms long)
underrun!!! (at least 36.119 ms long)
underrun!!! (at least 36.164 ms long)


-- 

Best Regards,
Peter Chen

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

[Peter Chen]

On Sun, Aug 14, 2016 at 01:21:21AM +0300, Ruslan Bilovol wrote:
> 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.
> 

I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
kernel w/o your patch set. The windows7 can't install the driver
successfully and the playback shows underrun (using local codec)
using Linux host.

Do you use the unchanged mainline kernel?

My configfs parameters like below:
echo 2 > functions/uac2.1/c_ssize
echo 48000 > functions/uac2.1/c_srate
echo 3 > functions/uac2.1/c_chmask
echo 2 > functions/uac2.1/p_ssize
echo 48000 > functions/uac2.1/p_srate
echo 3 > functions/uac2.1/p_chmask


Console output:
root@imx6qdlsolo:~# arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &
[1] 859
root@imx6qdlsolo:~# 
root@imx6qdlsolo:~# Recording WAVE 'stdin' : Signed 16 bit Little
Endian, Rate 48000 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
underrun!!! (at least 36.634 ms long)
underrun!!! (at least 36.117 ms long)
underrun!!! (at least 42.132 ms long)
underrun!!! (at least 40.157 ms long)
underrun!!! (at least 36.207 ms long)
underrun!!! (at least 39.173 ms long)
underrun!!! (at least 36.119 ms long)
underrun!!! (at least 36.164 ms long)


-- 

Best Regards,
Peter Chen

[PATCH v2 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.

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  |  56 +-
 11 files changed, 1803 insertions(+), 685 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

[PATCH v2 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.

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  |  56 +-
 11 files changed, 1803 insertions(+), 685 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