Hi Bryan, 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: > > Hi, > > > > On Tuesday 16 June 2009 07:23:31 Greg Kroah-Hartman wrote: > >> From: Bryan Wu <cooloney@xxxxxxxxxx> > >> > >> 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 ? 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
