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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
