Re: Writing a driver for this card: your thoughts?

[Takashi Iwai <tiwai@suse.de>]

Hi,

At Thu, 6 Jun 2002 11:03:19 +1200,
Eliot Blennerhassett wrote:
> 
> (It may be possible to release the host side code, but never the DSP code 
> on the cards.) 
 
it doesn't matter so much, as long as we have an enough working dsp
binary code and know its usage.

> I think it would be much better if we had an ALSA driver. 
 
yep :))

> I'd like some idea how hard it would be to write an ALSA driver either as a 
> compatibility layer on top of our existing driver, or from the ground up.  I 
> realise that this is rather a broad question, so please consider this an 
> invitation to enter discussion, rather than a request for you to go off and 
> do a lot of work for me. 
 
if we have a driver on alsa, then we'd like to integrate it as a
"real" alsa one.  porting a driver on a wrapper is of course possible
but it will bring more difficulty for the maintainence POV.


> Oh - what do you think of the cards' feature set?  
 
looks good.

 
> Some distinctive things about our cards (not all have all features) - they 
> have on board DSP.  Code is downloaded by the driver. - they have a lot of 
> on board buffer memory (hundreds of K at least) - on board DSP handles 
> decompression/compression - mixing - samplerate conversion or multiple 
> outputs at different rates - analog and digital audio I/O, balanced drivers 

should the dsp code be loaded statically or dynamically?
we can give also a hwdep device to access (load/change) dsp codes
independently like on emu10k1 driver.

another technical question is the mmap support.  if the chip has its
own onboard memory, it's likely unaccessible via mmap - this would be
a disadvantage.
it's not a big problem if the transfer is enough fast, though.


ciao,

Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink