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 (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
Attachment:
signature.asc
Description: PGP signature
