Hi, Ruslan Bilovol <ruslan.bilovol@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
