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 :-) 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. /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. Best regards, Laurent Pinchart -- 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
