Hi, On Mon, Aug 22, 2011 at 06:07:46PM +0530, Jassi Brar wrote: [big snip] > Hi Felipe, Hi > Functionality wise, audio.c hardcodes the data-path to the physical > audio-codec onboard > whereas audio2.c provides user-space with a virtual sound-card to fool around > with audio-data the way the user wants. The functionality that has > lion's share of code. > Also, although the functionality of audio.c can be achieved by audio2.c (but not > vice-versa) we'll break user-space by changing the behavior of audio.c > to audio2.c > > Besides fundamental differences in functionality, they differ by > Usb-Audio-Class > compliance as well. audio.c is UAC_1 compliant, whereas audio2.c is UAC_2 > complaint. > One can not replace the other. For ex, MS-Windows doesn't support > UAC_2 by default > yet, Linux does reasonably well. And by definition having > Linux-USB-Gadget support > UAC_2 also, is only better. So by having both we cover more ground than by > having just one. I understand your point, but then we will have two gadget drivers (and two function drivers) for the same thing (USB Audio), it's the same thing with the storage gadgets and we have decided on dropping one of them recently, so I'm not keen on accepting another gadget driver which will essentially do the same thing. If audio2.c can achieve audio.c's functionality, then you can start by re-factoring audio.c so that it come closer to what audio2.c is today. WRT UAC_1/UAC_2 compliance, you can use a Kconfig entry, or two separate USB configurations (one with UAC_1 and another UAC_2). So there are ways to make this all work while still keeping backwards compatibility. -- balbi
Attachment:
signature.asc
Description: Digital signature
