On Mon, Aug 22, 2011 at 6:14 PM, Felipe Balbi balbi@ti.com wrote:
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.
No dear, not the same thing. As I said, they differ by features as well as USB-Spec... only the 'audio' thing is common.
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.
audio.c and audio2.c have almost nothing in common. Please have a look at the code. Making audio.c closer to audio2.c would mean :- * Changing all of the descriptors of audio.c {uac_1 -> uac_2} * Removing all alsa related code and adding virtual alsa sound card. At the end, audio.c would have been changed completely and Linux-usb-gadget lost the UAC_1 compliance.
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.
IIUC, you mean adding UAC_2 compliance and virtual sound-card i/f to audio.c, while preserving the it's original functionality ? But that would mean having two drivers in one file, because they are so different. Otherwise, please have a look at audio.c and audio2.c and suggest what exactly you mean.
thnx