On Mon, Aug 22, 2011 at 6:14 PM, Felipe Balbi <balbi@xxxxxx> 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
--
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
