Hi Bryan, On Tuesday 16 June 2009 16:17:28 Bryan Wu wrote: > On Tue, Jun 16, 2009 at 10:04 PM, Laurent Pinchart < > > laurent.pinchart@xxxxxxxxx> wrote: > > 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 ? > > We just get the audio sound card capability on the gadget device and let > host PC know that capability via USB Audio Class Descriptor. > So the host PC application or ALSA utils will convert any other audio data > format to the one which is supported by the gadget device. > > We don't need to let gadget device user space application do the > conversion. I'm afraid that won't work. The host and device clocks are not synchronized, so you'll experience buffer underruns or overruns. 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
