On Tue, Jun 16, 2009 at 10:27 PM, Laurent Pinchart<laurent.pinchart@xxxxxxxxx> wrote: > 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. > That is OK on our Blackfin board. Since I don't have any boards, I'm not sure about your problem. As soon as we get your code, we can do some test on Blackfin board. Thanks -Bryan -- 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
