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. and this is the classic "merge or let it sit out" issue. having it in mainline gets more people coordinating on the driver. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
