On Tue, Jun 16, 2009 at 04:23:55PM +0200, 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. > > > 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 :-) Well, I don't think two of these are really bad. I think having two of them will serve wider audience than having just one of drivers. We can only have one gadget at time loaded, so lets see which approach is better in tree. It will not be reinvention of wheel, two different approaches to the same problem can lead to different kind of products. > > 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. I don't think so if done properly. Anyway, we can have only one gadget at time. > > /me crosses his fingers to get an answer different than "first-come, first- > served". ??? > > I believe that accessing the audio device directly from the UAC driver is a > bad idea. The driver should instead expose an interface to userspace > applications to sink/source audio data. I'll post a driver that exposes an > ALSA interface, but discussions on the alsa-devel mailing list (see > http://mailman.alsa-project.org/pipermail/alsa-devel/2009-May/017354.html) > showed that an alternative interface might be better. I think 'Show us the code' approach is better here. All the best, S. -- 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
