On Tuesday 16 June 2009 10:23:55 Laurent Pinchart wrote: > Hi Mike, > > On Tuesday 16 June 2009 16:12:06 Mike Frysinger wrote: > > On Tuesday 16 June 2009 10:04:36 Laurent Pinchart wrote: > > > On Tuesday 16 June 2009 15:23:07 Bryan Wu wrote: > > > > On Tue, Jun 16, 2009 at 9:15 PM, Laurent > > > > > > > > Pinchart<laurent.pinchart@xxxxxxxxx> wrote: > > > > > On Tuesday 16 June 2009 07:23:31 Greg Kroah-Hartman wrote: > > > > >> Funtions added: > > > > >> - setup all the USB audio class device descriptors > > > > >> - handle class specific setup request > > > > >> - receive data from USB host by ISO transfer > > > > >> - play audio data by ALSA sound card > > > > >> - open and setup playback PCM interface > > > > >> - set default playback PCM parameters > > > > >> - provide playback functions for USB audio driver > > > > >> - provide PCM parameters set/get functions > > > > >> > > > > >> Test on: > > > > >> - Host: Ubuntu 8.10, kernel 2.6.27 > > > > >> - Gadget: EZKIT-BF548 with ASoC AD1980 codec > > > > >> > > > > >> Todo: > > > > >> - add real Mute control code > > > > >> - add real Volume control code > > > > >> - maybe find another way to replace dynamic buffer handling > > > > >> with static buffer allocation > > > > >> - test on Windows system > > > > >> - provide control interface to handle mute/volume control > > > > >> - provide capture interface in the future > > > > >> - test on BF527, other USB device controler and other audio codec > > > > > > > > > > I've tested the driver on a TI DM355 platform and it doesn't work > > > > > correctly. I can get audio data to stream to the device, but buffer > > > > > underruns/overruns kill the experience. > > > > > > > > > > I've written another USB audio class gadget driver that doesn't > > > > > interface to the ALSA device directly but exposes an ALSA interface > > > > > to userspace. It requires a userspace application to transfer audio > > > > > data between the real audio device and this 'fake' USB audio > > > > > device. > > > > > > > > I consider that method before. But it will ask the gadget device to > > > > do some audio data format conversion. > > > > for example, if audio data from host PC is 48000 sample rate, it > > > > should be converted to 441000 sample rate to playback when the gadget > > > > device only supports 441000. > > > > > > I suppose you mean 44100. > > > > > > Conversion should be handled by the userspace application on the device > > > side, not the gadget driver. Anyway, sample rate matching needs to be > > > performed on the device side unless you can lock the audio clock to the > > > SOF clock (synchronous endpoint) or to the data stream clock (adaptive > > > endpoint). > > > > > > > So the conversion will be done at host PC side instead of gadget > > > > device with my driver. > > > > > > How so ? > > > > > > Is the driver really ready to be merged ? > > > > i think the driver is mature enough for other people to start hacking on > > it. > > It's a proof of concept. I hardly call that mature. read it again. i said "mature enough ... to merge". > > and this is the classic "merge or let it sit out" issue. having it in > > mainline gets more people coordinating on the driver. > > Ok, but be warned that I'll submit a patch in a few days with a mostly > completely rewritten USB audio class driver :-) "rewritten" means you based it on this driver which isnt true. they're two completely independent works that have fundamentally different designs. > Jokes aside, how should that be handled ? The two drivers use a completely > different model to access the sound device, and they will export symbols > that will likely clash. maybe i missed something, but my (limited) understanding of the gadget framework is you can only be operating as one thing at a time. and looking at the Kconfig, if gadget support is compiled in, you can only select one gadget driver. but if it's built as a module, then you can enable all of them and then select things at runtime by loading one module. and since gadget drivers are "leaf" drivers (i.e. things dont depend on them), they shouldnt be exporting symbols in the first place. as such, there shouldnt be any clashing problems. in other words, i dont see there being a problem with both drivers being merged and as people test things, presumably one will prove to be better. or we can argue about fundamental design decisions until we're blue and people are left waiting to use *something*. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
