RE: [linux-audio-dev] Writing a driver for this card: your thoughts?
Thought I would chime in just for some extra information in case anyone cared to know. As the feature size of chips keeps getting smaller and smaller, these same issues are getting increasingly worse! At 0.18 signal integrity doesn't always have to be checked if you are careful with your rise and fall times for digital signal (plus your fanout), but as you go to 0.13um feature size, the capacitive effects start to cause big signal integrity problems. It is interesting to me that these problems are a big problem at the board level too, I didn't know that. Rick On Thu, 30 May 2002, Bob Colwell wrote: Somehow I feel the need to get even more specific. Voltage sags for two reasons: DC resistance and AC impedance. DC resistance is just plain old ohms law -- no perfect conductors exist (until the folks in the labs give us high-temp superconductors), so a current flow will always cause a voltage drop, as in E=IR. AC impedance matters because conductors also exhibit inductance and capacitance. Capacitance causes signal leakage and cross-coupling. But inductance causes AC-induced voltage spikes, because coils convert electrical energy into a magnetic field, and if you try to collapse that magnetic field quickly (as a fast-changing electrical signal does) it reconverts back into an electrical potential that acts to oppose the change in current. If one distributes capacitors of the appropriate size and speed, one can effectively decouple the downstream inductances from the current spike. Lamar knows all this but I thought it might benefit others who might not. -BobC ++---+ | T a l i t y | +--+ | ++ ++-+| | | Richard Burnett |+-+| | | Senior Design Engineer +---+ ++ | | [EMAIL PROTECTED] | | | | | | | | Phone: 919.380.3014 | | | Fax: 919.380.3903 | | | ++
RE: [linux-audio-dev] Writing a driver for this card: your thoughts?
Somehow I feel the need to get even more specific. Voltage sags for two reasons: DC resistance and AC impedance. DC resistance is just plain old ohms law -- no perfect conductors exist (until the folks in the labs give us high-temp superconductors), so a current flow will always cause a voltage drop, as in E=IR. AC impedance matters because conductors also exhibit inductance and capacitance. Capacitance causes signal leakage and cross-coupling. But inductance causes AC-induced voltage spikes, because coils convert electrical energy into a magnetic field, and if you try to collapse that magnetic field quickly (as a fast-changing electrical signal does) it reconverts back into an electrical potential that acts to oppose the change in current. If one distributes capacitors of the appropriate size and speed, one can effectively decouple the downstream inductances from the current spike. Lamar knows all this but I thought it might benefit others who might not. -BobC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Lamar Owen Sent: Tuesday, May 28, 2002 4:49 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] Writing a driver for this card: your thoughts? On Tuesday 28 May 2002 07:20 pm, Tobias Ulbricht wrote: one question: could you do this for the unsophisticated audiophile with less Acronyms? supply. Using a computer psu is going to severely limit what you are ^^^ = power supply unit? Yes. decoupling is done at the amplifier rails, along with 'sag' compensating caps ^^^ Voltage sag due to current draw. (with low ESR! Tantalum only, and preferably sintered slug) in the proper ^^^ ? electron spin resonance :)? Equivalent series resistance. The higher the ESR, the slower the cap will discharge, and the less effective it is as a 'voltage flywheel'. But again, the hardware must be able to cancel out the enevitable RFI that is ^^^ Radio Frequency Interference. Sorry. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Tue, May 28, 2002 at 07:43:14PM -0400, Lamar Owen wrote: Class A design has it's strong points. As long as you are in a good linear portion of the transconductance curve you're OK. As a sometime guitarist, I'd say Class A has its strong points well into distortion... Hey Taybin, I know you weren't really into that Sleater-Kinney show, but how did you like that Vox AC-30 that Carrie plays through? Yum! -- Paul Winkler home: http://www.slinkp.com Muppet Labs, where the future is made - today!
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Wed, 29 May 2002, Paul Winkler wrote: Hey Taybin, I know you weren't really into that Sleater-Kinney show, but how did you like that Vox AC-30 that Carrie plays through? Oh yeah! Her sound was great. Real warm. Taybin
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Wednesday 29 May 2002 11:18 am, Paul Winkler wrote: On Tue, May 28, 2002 at 07:43:14PM -0400, Lamar Owen wrote: Class A design has it's strong points. As long as you are in a good linear portion of the transconductance curve you're OK. As a sometime guitarist, I'd say Class A has its strong points well into distortion... But then the amplifier is *producing* sound rather than *reproducing* sound, and has become a form of compressor. A compressor with some interesting curves, maybe, but a compressor nonethless. And a compressor one can model and produce identical characteristics in effects plugins. :-) As a sometimes guitar player myself, that is. Still have my copy of Anderton's 'Electronic Projects for Musicians' lying around here. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Wed, May 29, 2002 at 02:22:09PM -0400, Lamar Owen wrote: On Wednesday 29 May 2002 11:18 am, Paul Winkler wrote: On Tue, May 28, 2002 at 07:43:14PM -0400, Lamar Owen wrote: Class A design has it's strong points. As long as you are in a good linear portion of the transconductance curve you're OK. As a sometime guitarist, I'd say Class A has its strong points well into distortion... But then the amplifier is *producing* sound rather than *reproducing* sound, and has become a form of compressor. A compressor with some interesting curves, maybe, but a compressor nonethless. And a compressor one can model and produce identical characteristics in effects plugins. :-) In theory, yes. In practice, I think we're still in the close but no cigar stage of modelling amplifiers. But I do think we'll get it eventually. -- Paul Winkler home: http://www.slinkp.com Muppet Labs, where the future is made - today!
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Wednesday 29 May 2002 02:50 pm, Paul Winkler wrote: On Wed, May 29, 2002 at 02:22:09PM -0400, Lamar Owen wrote: interesting curves, maybe, but a compressor nonethless. And a compressor one can model and produce identical characteristics in effects plugins. :-) In theory, yes. In practice, I think we're still in the close but no cigar stage of modelling amplifiers. But I do think we'll get it eventually. If one has the amplifier in question, one can produce a reasonable facsimile of the transfer function using various waveforms and frequencies, then interpolate (cubic splines, probably) to determine a transfer function that one cane then put into a 'transfer function engine' that would replicate said transfer function. You should be able to characterize down to the individual lot number level with enough resolution in the interpolation. Has such a 'transfer function engine' effect plugin been written? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Wednesday 29 May 2002 14:22, Lamar Owen wrote: But then the amplifier is *producing* sound rather than *reproducing* sound, and has become a form of compressor. A compressor with some interesting curves, maybe, but a compressor nonethless. And a compressor one can model and produce identical characteristics in effects plugins. :-) Fie fie, you infidel! :) Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| |DALLAS: | | The city that chose Astroturf to | | keep the cheerleaders from grazing. | |-|
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Mon, May 27, 2002 at 10:48:28PM -0400, Lamar Owen wrote: Properly designed balanced in and out A/D and D/A converters can be completely immune to the PC's internal noise. But it all goes to proper design. The Antex SX series of cards likewise contain internal A/D converters. I have measured the noise figures of the Antex SX-36 we have at WGCR using state of the art audio systems analyzers, and the noise floor is below the LSB threshold. All due to balanced I/O, sound PC layout techniques, and top of the line components. Just to try and put things in perspective, surely once you go beyond a certain level, signal-unrelated noise is one of the least important indications of sound quality? For me anyway. The quality of the noise is important also :-) In a high RF environment, unless the converters are optically isolated from the PC, you might be asking for trouble. When I say 'high RF' I'm talking 10KW of AM transmitter fifteen feet away, with a measured RF field intensity of 105V/m (the ANSI exposure limit is around 645V/m). This means a one meter piece of wire that isn't properly grounded can develop 105V of RF energy. I have suffered RF burns of appreciable intensity touching wires that weren't connected to anything on either end -- they were just oriented along the field gradient. your requirements do seem to be rather different than a recording studio :-) Also, due to the processing typical radio stations use in the air chain, in many cases the quality of playback and record hardware for on-air use must be up to the top quality of a recording studio. Typical radio stations use sophisticated compressors, multiband limiters, and many other DSP-driven techniques to maximize loudness -- and when the dynamics of the source material go pianissimo, the compressors drive up the noise floor to compensate. Noise in the outputs of a broadcast automation or music-on-hard-drive system is verboten. [] such insane amounts of compression as used by most radio stations are not usually related to 'quality' as understood by most poeple. one of the most important aspects of analogue design is a good power supply. Using a computer psu is going to severely limit what you are going to achieve. Regulators are by no means perfect. also, perhaps academic here, but using balanced audio can actually degrade the sound by cancelling out even order harmonics but leaving the odd order ones, or by increasing the component count. Very high end stuff designed for non-hostile environments tends to be unbalanced. sorry if i'm just being pedantic :-) cheers Tim Orford ok, back to trying to get Ardour compiled.(does that make me On-Topic now?)
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Friday 24 May 2002 22:11, Paul Davis wrote: By my standards, anybody who puts A-D/D-A conversion inside their computer chassis is by definition not concerned with the best in the business. The term professional audio for me doesn't include analog I/O for a computer card unless the converters are in a separate box. It might be good enough for a radio station, but for a recording studio? Sounds like you've never heard one of these cards in action. The entire analog section is mu-metal shielded, and in terms of quality can stand with the best of the external designs. Personally, I define professional as that which meets a certain standard of quality in operation and features, which these cards certainly do. *How* that is achieved is really irrelevant. BTW, these cards work very well under Linux right now, using AudioScience's HPI interface. Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| | Some changes are so slow, you don't notice them.| | Others are so fast, they don't notice you. | | -- Anonymous | |-|
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
[I may regret this... :-)] On Tuesday 28 May 2002 01:19 pm, Tim Orford wrote: Lamar Owen wrote: Also, due to the processing typical radio stations use in the air chain, in many cases the quality of playback and record hardware for on-air use must be up to the top quality of a recording studio. such insane amounts of compression as used by most radio stations are not usually related to 'quality' as understood by most poeple. What happens is that lower quality audio is made to sound that much worse by that very compression. Reverb is exaggerated, etc. As to the amounts being insane -- well, that is a big point of contention in the broadcast engineer and broadcast program director communities. one of the most important aspects of analogue design is a good power supply. Using a computer psu is going to severely limit what you are going to achieve. Regulators are by no means perfect. If the output impedance of the output stage is low enough, and proper decoupling is done at the amplifier rails, along with 'sag' compensating caps (with low ESR! Tantalum only, and preferably sintered slug) in the proper places, DC rail regulation becomes moot. The key is a properly designed feedback network, with low net gain, using a high quality op amp with as high an open loop gain as possible, and operating the output well below rail voltage. If the output voltage goes over half rail, then all bets are off. also, perhaps academic here, but using balanced audio can actually degrade the sound by cancelling out even order harmonics but leaving the odd order ones, or by increasing the component count. Very high end stuff designed for non-hostile environments tends to be unbalanced. Phase-linear balanced outputs won't cancel _any_ harmonics. Where did that concept come from? And the Carver Silver Seven sounds better than the old M400, too, right? :-) (audiophile humor) ok, back to trying to get Ardour compiled.(does that make me On-Topic now?) Hmmm. You know, a linux based broadcast compressor (on the order of an Omnia6 or Optimod 8400) would be an interesting project. Someone who wants to do serious DSP work could have a field day doing multiband limiting and the various other things broadcast processors must do. But again, the hardware must be able to cancel out the enevitable RFI that is going to be present. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Tuesday 28 May 2002 16:19, Lamar Owen wrote: Hmmm. You know, a linux based broadcast compressor (on the order of an Omnia6 or Optimod 8400) would be an interesting project. Someone who wants to do serious DSP work could have a field day doing multiband limiting and the various other things broadcast processors must do. Actually, I just heard an interesting rumor. One of the major broadcast transmitter manufacturers (the one with sales offices in Mason OH) is implementing their exciter for the new Ibiquity FM DAB system on an embedded Linux platform. This includes some very high end encoding technologies (like PAC/AAC). It'll be interesting indeed to see how this pans out. Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| |The real problem with hunting elephants is carrying the decoys. | | -- Anonymous| |-|
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
one question: could you do this for the unsophisticated audiophile with less Acronyms? What's all that: supply. Using a computer psu is going to severely limit what you are ^^^ = power supply unit? decoupling is done at the amplifier rails, along with 'sag' compensating caps ^^^ (with low ESR! Tantalum only, and preferably sintered slug) in the proper ^^^ ? electron spin resonance :)? But again, the hardware must be able to cancel out the enevitable RFI that is ^^^ thanks, tobias.
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Tuesday 28 May 2002 06:40 pm, Tim Orford wrote: On Tue, May 28, 2002 at 04:19:48PM -0400, Lamar Owen wrote: :-) bring on the flames :-) This is a flame? Tempest in a teacup... :-) and good quality audio sounds better? this is a new one to me - i've never heard anyone blame it on the source material beforehmmm...:-) Yes, actually, good quality source material sounds better. Orban's Optimod 9100 manual, circa 1987, mentions this as part of the setup instructions. I do sympathise with you, but if that much compression was desirable, then the tracks would be mixed like that in the first place. Have you checked the dynamic range (or lack thereof) on some recent CD's? They are compressed flat as a pancake. But, like I said, for AM radio coverage area is directly proportional to modulation percentage. FM radio doesn't have that excuse. And I personally process the least I can get away with. But it does compensate for much operator error in the lack of watching levels. And the six band limiter of the Optimod 9100 is pretty clean. But like you said, it has been a big point of contention for a long time, and i dont think we will solve it here :-) Yes, indeed. Phase-linear balanced outputs won't cancel _any_ harmonics. Where did that concept come from? i have seen this in balanced internal circuitry, for example in valve compressors. Its been a few years since i did much analogue stuff, so i'm gonna be deliberately vague here. Certainly in a non-linear situation (such as a tube compressor, such as the ever popular UREI leveling amplifier (got one)) balanced versus non-balanced internal to the processing will change the transfer function. But this is an I/O discussion. And the Carver Silver Seven sounds better than the old M400, too, right? :-) (audiophile humor) ok, i can see that you think that i am some kind of audiophile lunatic, which maybe i am to a certain extent. There have been several things which have changed my life in a major way in the last few years: That wasn't my intention; my apologies. One was the discovery of the Free Software movement. One was the discovery of class A, low feedback design (thereby shattering most of what i was taught at college). Class A design has it's strong points. As long as you are in a good linear portion of the transconductance curve you're OK. I'm not really disagreeing with you, but i think my point was that there are more factors to take into account that you appeared to be ignoring. There's always factors. In another forum I might detail how the assymetry of tower base impedance creates distortion in the transmitted audio of an AM station, and how silver plated coils and multi-thousand dollar vacuum capacitors with computer modeled matching networks have more of a bearing on my sound than the audio inside the studio. My matching network here is worth over $75,000, thanks to the engineering behind it. And that's just so that my 11khz sliver of audio passband will be as flat as possible. But that would be a major digression. By private e-mail, perhaps. There is a lot more to analogue audio than just keeping impedances low, wacking up the negative feedback, and measuring the noise floor, as i'm sure you realise. Certainly. Transmission line factors must be taken into account for long runs at high frequencies, etc. Lots of factors. But the question I was answering was a simple 'I've never heard of balanced drivers; what are they?' So to get back to the original point, i'm sure the cards you mentioned are indeed fine cards, but if cost is no object (ha ha!) and if quality is your objective, then you will put your analogue converters in a separate box with a dedicated power supply. Those ASI cards ain't cheap. Check them out: audioscience.com. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Tuesday 28 May 2002 07:20 pm, Tobias Ulbricht wrote: one question: could you do this for the unsophisticated audiophile with less Acronyms? supply. Using a computer psu is going to severely limit what you are ^^^ = power supply unit? Yes. decoupling is done at the amplifier rails, along with 'sag' compensating caps ^^^ Voltage sag due to current draw. (with low ESR! Tantalum only, and preferably sintered slug) in the proper ^^^ ? electron spin resonance :)? Equivalent series resistance. The higher the ESR, the slower the cap will discharge, and the less effective it is as a 'voltage flywheel'. But again, the hardware must be able to cancel out the enevitable RFI that is ^^^ Radio Frequency Interference. Sorry. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Friday 24 May 2002 10:11 pm, Paul Davis wrote: As to the AudioScience cards, they are common in radio stations and recording studios. By my standards, anybody who puts A-D/D-A conversion inside their computer chassis is by definition not concerned with the best in the business. The term professional audio for me doesn't include analog I/O for a computer card unless the converters are in a separate box. It might be good enough for a radio station, but for a recording studio? Properly designed balanced in and out A/D and D/A converters can be completely immune to the PC's internal noise. But it all goes to proper design. The Antex SX series of cards likewise contain internal A/D converters. I have measured the noise figures of the Antex SX-36 we have at WGCR using state of the art audio systems analyzers, and the noise floor is below the LSB threshold. All due to balanced I/O, sound PC layout techniques, and top of the line components. With unbalanced I/O all bets are off, of course. But I still use an Echo Layla in our production studio -- and Layla's A/D is out of the PC in a rackmount chassis. Balanced I/O on TRS 1/4 inch jacks. But no Linux drivers yet. I think you're always better off with 3rd party converters myself, so you can make you're own choices on the quality level, and possibly have multiple options (Fostex,Frontier Designs,Apogee for example) as well as upgrade/downgrade paths. In a high RF environment, unless the converters are optically isolated from the PC, you might be asking for trouble. When I say 'high RF' I'm talking 10KW of AM transmitter fifteen feet away, with a measured RF field intensity of 105V/m (the ANSI exposure limit is around 645V/m). This means a one meter piece of wire that isn't properly grounded can develop 105V of RF energy. I have suffered RF burns of appreciable intensity touching wires that weren't connected to anything on either end -- they were just oriented along the field gradient. Also, due to the processing typical radio stations use in the air chain, in many cases the quality of playback and record hardware for on-air use must be up to the top quality of a recording studio. Typical radio stations use sophisticated compressors, multiband limiters, and many other DSP-driven techniques to maximize loudness -- and when the dynamics of the source material go pianissimo, the compressors drive up the noise floor to compensate. Noise in the outputs of a broadcast automation or music-on-hard-drive system is verboten. This is particularly (and somewhat paradoxically) true on an AM station, where the processing will be much more aggressive -- the higher the average modulation, the greater the effective coverage area for an AM station. Having said that, the distortion percentages aren't nearly as important for the exact same reason. But it is wrong to state that a recording studio will automatically need higher quality than a radio station. But in theory I agree with you on the topic of analog I/O into the PC -- but I have just seen top quality hardware with on-board analog I/O that had no measureable PC-induced noise too many times to ignore. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
immune to the PC's internal noise. But it all goes to proper design. The Antex SX series of cards likewise contain internal A/D converters. I have measured the noise figures of the Antex SX-36 we have at WGCR using state of the art audio systems analyzers, and the noise floor is below the LSB threshold. All due to balanced I/O, sound PC layout techniques, and top of the line components. Just FYI, RME make all the same claims on their website about their 8 channel analog daughterboards for the Hammerfall. In a high RF environment, unless the converters are optically isolated from the PC, you might be asking for trouble. When I say 'high RF' I'm talking 10KW of AM transmitter fifteen feet away, with a measured RF field intensity of 105V/m (the ANSI exposure limit is around 645V/m). This means a one meter piece of wire that isn't properly grounded can develop 105V of RF energy. I have suffered RF burns of appreciable intensity touching wires that weren't connected to anything on either end -- they were just oriented along the field gradient. Just Say Fibre Optics :) Who needs AES or MADI when you've got ADAT? :) --p
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Fri, May 24, 2002 at 10:11:05PM -0400, Paul Davis wrote: I don't know what balanced drivers are. Balanced I/O. Professional grade. its related to the wiring of the connectors and the voltage level that corresponds to 0dB. footnote: this has nothing to do with drivers in the software sense :) OK, that was my confusion. I know balanced cabling -- I used to work in a radio station. The world would be a better place if all audio was balanced. Especially car audio. Sorry, got off-topic. So: I'm going to resume work on my Gadget Labs driver soon. Anyone have one of their cards and wants to help? Regards, Mark Rages http://mark.rages.net
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Fri, May 24, 2002 at 05:47:07PM +1200, Eliot Blennerhassett wrote: Hello, I work for AudioScience (www.audioscience.com) We make excellent (how could I say otherwise) audio cards. ... 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. You should be on the alsa-dev mailing list. Writing a driver is probably about as easy as giving the card and a copy of the Windows driver source to the right person. Otherwise, read the existing drivers for examples. 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. Common. - they have a lot of on board buffer memory (hundreds of K at least) Hopefully that doesn't hurt latency. - on board DSP handles decompression/compression Why? Which formats? - mixing Common on consumer cards. - samplerate conversion or multiple outputs at different rates Interesting. Is there an application for this? - analog and digital audio I/O, balanced drivers I don't know what balanced drivers are. Regards, Mark
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Friday 24 May 2002 01:47, Eliot Blennerhassett wrote: 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. Howdy Eliot, wonderful to see you on the list! The two basic components that would have to be addressed to get ALSA support are the kernel and user-space (alsa-lib) components. My sense is that the alsa-lib interface could be implemented as a layer between the application and HPI, much as the existing Windows sound driver is implemented. The bigger challenge would be to get the kernel part working. ALSA developers are encouraged to use alsa-lib whenever possible, but it *is* possible to use the kernel ioctls directly too. Whether it would make any sense (or would even be possible) to implement alsa-lib emulation on top of a different set of ioctls is a good question. As for supporting features on the cards, other than a few oddball functions (like the GPIO calls or HPI_SetStreamOutVelocity()), I don't think there would be a great deal of difficulty. It would be nice to have an envrionment where *both* APIs were available -- HPI is quite handy for doing some things. Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| | A rock pile ceases to be a rock pile the moment a single man | | contemplates it, bearing within him the image of a cathedral. | | -- Antoine de Saint-Exupery | |-|
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
Hi, 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. With that amount of knowledge you have about your card, it actually shouldn't be to hard to develop a driver. I wrote a linux kernel driver for a volume rendering graphics card with reconfigurable hardware and an onboard DSP with less information. I don't know about the interna of your HPI, but surely you need to include some low level code to do the PCI detection and setup of your card with linux. If that's already in your HPI it shouldn't be a problem to adapt that to write a wrapper for the alsa lib. If you want then you provide your dsp code and distribute it with alsa. At least some amount of code goes into the kernel and so has to meet Linus standards :-) Alright, then. If you have any questions, I see no problem supporting you, writing that driver. Cheers, Alex
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
On Friday 24 May 2002 01:12 pm, Mark Rages wrote: On Fri, May 24, 2002 at 05:47:07PM +1200, Eliot Blennerhassett wrote: - analog and digital audio I/O, balanced drivers I don't know what balanced drivers are. Balanced I/O. Professional grade. As to the AudioScience cards, they are common in radio stations and recording studios. The audio specs (frequency response, distortion) are nearly the best in the business. They are NOT cheap, though. But multiple balanced ins and outs on XLR's (by way of octopus cabling) works very well. One of the radio stations I engineer for has a couple of the higher end ASI cards 4336 maybe? Anyway, they have the digital I/O (for triggers and switching, not digital audio), and they are very happy with the quality of the cards. If these cards get good Linux drivers, this will be killer. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [linux-audio-dev] Writing a driver for this card: your thoughts?
I don't know what balanced drivers are. Balanced I/O. Professional grade. its related to the wiring of the connectors and the voltage level that corresponds to 0dB. footnote: this has nothing to do with drivers in the software sense :) As to the AudioScience cards, they are common in radio stations and recording studios. The audio specs (frequency response, distortion) are nearly the best in the business. They are NOT cheap, though. But multiple balanced ins and outs on XLR's (by way of octopus cabling) works very well. By my standards, anybody who puts A-D/D-A conversion inside their computer chassis is by definition not concerned with the best in the business. The term professional audio for me doesn't include analog I/O for a computer card unless the converters are in a separate box. It might be good enough for a radio station, but for a recording studio? I think you're always better off with 3rd party converters myself, so you can make you're own choices on the quality level, and possibly have multiple options (Fostex,Frontier Designs,Apogee for example) as well as upgrade/downgrade paths. --p
[linux-audio-dev] Writing a driver for this card: your thoughts?
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 ZealandPh/fax: +64 3 3327818
[EMAIL PROTECTED]
http://www.audioscience.com
=
