>On Thu, 2002-01-24 at 14:51, Paul Davis wrote: > >> precisely. rme are quite happy releasing specs to right a driver; they >> are not planning on releasing specs to write new FX. its worth noting >> that rme have said publically that it took them quite a long time and >> quite a lot of really deep thinking to understand how to use an FPGA >> for what they are now doing. i don't know if this is accurate, or if >> it means that they were FPGA/DSP illiterate to start with, but if >> true, i could understand why they don't want to reveal what they >> learned (even though i don't agree with that mentality). > >Dagnammit.. my prime example of spec releasing turns out to be just as >bad as creative :/ > >Just out of interest, could you enumerate what RME have given to you?
for the hammerfall DSP, at this point nothing. there are no written docs, so the current plan is to start from the windows driver source (under an NDA) and combine it with what i know about the hammerfall (classic edition). for the hammerfall classic, i got a complete spec on the card, including a description of all the registers, how to use them and small bits of sample code to handle stuff that isn't easy to describe in spoken language. >And could you say what functionality is there in the windows/mac drivers >that it wouldn't be possible to replicate with open source stuff based >on the specs they have given you? AFAIK, nothing. It might be worth noting that companies in the windows/macos world tend to consider h/w-specific utilities to be part of the "driver". RME's "TotalMix", which is a routing matrix+mixer+metering tool, is considered by them to be part of the "driver". under linux/ALSA, this would be an application that uses capabilities provided by the driver. i don't intend to write TotalMix - ardour can do all that stuff already, i'll simply extend it to support the major new feature of the Hammerfall DSP: zero latency monitoring on a channel with additional CPU-generated output mixed over the top of it. --p
