Writing a driver for this card: your thoughts?

Writing a driver for this card: your thoughts?

[Eliot Blennerhassett]

Those of you who read linux-audio-dev will recognise the following. 
Thanks for your replies over there. 

It should have gone primarily to alsa-devel, but somehow didn't. 
========================== 

Hello, 

I work for AudioScience (www.audioscience.com) 

We make excellent (how could I say otherwise) audio cards. 

The emphasis within the company has been on microsoft windows drivers. 
... but we have a Linux driver, currently proprietary, closed source, that 
exposes this 
(http://www.audioscience.com/internet/download/spchpi.pdf) API. 

(It may be possible to release the host side code, but never the DSP code 
on the cards.) 

I think it would be much better if we had an ALSA driver. 

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. 

Oh - what do you think of the cards' feature set?  


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 


=============================================
====
Eliot Blennerhassett                       *:-{)>
AudioScience, Inc. (New Zealand Office)
6 Centaurus Rd             
Christchurch 8002          Mobile: +64 21 1183531
New Zealand                Ph/fax: +64  3 3327818
eblennerhassett@audioscience.com
<http://www.audioscience.com>
=============================================
====


_______________________________________________________________

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

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

[Dan Hollis]

On Thu, 6 Jun 2002, Eliot Blennerhassett wrote:
> (It may be possible to release the host side code, but never the DSP code 
> on the cards.)

Is it possible to bundle DSP firmware code with the driver? (If it's 
uploaded by the host, and it's not in eeprom or something). It's very hard 
to distribute drivers for firmware-based devices if we can't distribute 
the firmware required :-o

But we don't need the source code to the DSP firmware. Just tell us how to 
talk to the DSP and tell it to make noise.

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

I agree :-)

> 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.

I think it would be better if it were a native ALSA driver talk directly 
to the DSP, eg ALSA->DSP rather than ALSA->HPI->DSP.

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

It looks pretty nice. But what's the price? :-o

> 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 

What's minimum latency possible with the card?

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]



_______________________________________________________________

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

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

[Eliot Blennerhassett]

On 6 Jun 2002 at 12:04, Dan Hollis wrote:

> Is it possible to bundle DSP firmware code with the driver? (If it's 
> uploaded by the host, and it's not in eeprom or something). It's very hard 
> to distribute drivers for firmware-based devices if we can't distribute 
> the firmware required :-o

Yes.  The firmware image is currently loaded from a binary data file which is 
distributed as part of our current drivers.

> But we don't need the source code to the DSP firmware. Just tell us how to 
> talk to the DSP and tell it to make noise.

I'll work out what info/code we would need to release, and see if this is 
something management would agree to.
  
> It looks pretty nice. But what's the price? :-o

Models range from $995 to $3495
:-O  no, they aren't competition for a soundblaster...
 
> What's minimum latency possible with the card?

Historically our cards have very large buffers that contain seconds of audio, so 
that they can keep playing flawlessly even if the CPU or network gets bogged 
down.  Whether this is used or not is up to the application though.

Low latency has not been a design goal.  I would say the latency is between 
about 3000 to 5000 samples depending on processing details.

> 
> -Dan


_______________________________________________________________

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

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

[Dan Hollis]

On Fri, 7 Jun 2002, Eliot Blennerhassett wrote:
> > What's minimum latency possible with the card?
> Historically our cards have very large buffers that contain seconds of audio, so 
> that they can keep playing flawlessly even if the CPU or network gets bogged 
> down.  Whether this is used or not is up to the application though.
> Low latency has not been a design goal.  I would say the latency is between 
> about 3000 to 5000 samples depending on processing details.

So it would be accurate to say this card is not suitable for live 
performance, but is mainly targeted toward post-production and archive 
broadcast?

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]


_______________________________________________________________

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

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

[Takashi Iwai]

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