Apox digital X-over

[harvardian]

Hi Jason,

Craig and I were just discussing the costs. We are hoping to be able to compete with the Behringer unit in terms of costs...

Based on low volume, the price may be higher, but hopefully, the performance will also be higher...

Dale

[jleaman]

Well when you get one done you could start a wikki and people would buy one then...

[Da5id4Vz]

48 MB SDRAM... Hummm,

How bout a feature set to do something like this:

http://www.dolby.com/dp564/

I understand however that the licensing process and fees

http://www.dolby.com/trademark/co.ot.0204.LicInfo.pdf
http://www.dolby.com/lic/Certification_Protocol.pdf

may be prohibitive for the small enterprise undertaking. It is however easy for me to make the suggestion.

It would really be the killer addition to the APOX.

[harvardian]

Hi Guys,

I hate to disappoint, but we will not do any form of multi-channel decoding. There is too much competition and the development licenses are way too expensive…

Dale

[Da5id4Vz]

I expected this would be the case but felt compelled to ask.

Is an OEM relationship with an existing licensed manufacture also out of the question? Im not sure, however, that the double D license allows for this much flexibility.

[ojg]

The SHARC 21161 is a great chip! I'm glad you went with it instead of the 21065. More horsepower!!!

Good luck!

[Petter]

Features:

1. Input sample rate converter. Why not use 192/32 into the chip and 64 bit internal resolution?
2. Non-resampled input as well
3. High quality clock with PLL to enable various output frequencies to clock external devices (reads sources to more or less ELIMINATE jitter).
4. 64 bit FP DSP with ample processing power!!! Don't skimp here!
5. Frequency domain filtering
6. Phase domain filtering
7. Time delays
8. Don't need SPDIF out bckl, l/rclk and mclk should be enough. S/PDIF is a troublesome format which increases parts count + adds jitter by default since it uses an embedded clock (unless you are willing to transmit MCLK next to it as well).

PC based units will be more convenient for me. Be warned of costs involved with manufacturing. I have a 2 part Audio Amateur article about a guy who did something similar (yet different ) who had total cost runaway based on in part mask manufacturing for solder application with complex chips. I can probably get you this to review if you are interested.

I believe Crystal offer multi-channel decoding hard-coded into some of their chips. I am not sure how that works in terms of licensing.

The easiest and cheapes is the integrated TI DAC chips with biquads proposef before me. They would meld nicely into the current Apox line and enable saled of more Apox and digital crossover at low cost. I have considered them, but the silly programming (which you guys are good at) through SPI or whatever killed it for me.

I seriosly doubdt that you will be able to compete pricewise with Behringer et al., but hey! Why not!!!

Petter

[dwk123]

I've been interested in DSP xovers for quite a while - 8-10 years or so since first hearing about the Meridian speakers. I've seen a couple dozen discussions like this one, about how to come up with the ultimate audio dsp box etc. None of them as far as I know ever amounted to anything, for a variety of reasons.
The biggest problem IMHO is that they start out looking at the hardware first, and this isn't where the interesting problem is. The challenges are really in the software, both the choice of algorithms/filters used as well as the 'user interface' into the unit - how do you upload/download configurtions? measure/massage/generate FIR filters? Channel mixing/routing?. As we can see already in this thread, getting anyone to even agree on what the feature set should be is hard enough, forget the problems ultimately defining it down to an implementation level and implementing it.

Furthermore, the hardware engineering is problematic in many ways - usually more expensive than originally expected, longer design cycle than expected which means that new chips are available before the board goes 'production', rather difficult to build decent expansion capabilities in to appeal to a broad enough audience for critical mass (ie 1 dsp and 4 channels for 'cheap' entry level, 2/3/4 dsp's and 8/10/12 channels for high-end theater application), funding the prototype cycles and initial production runs etc.

I went through a couple motorola eval boards (56007 and 56362) without ever really getting a system that worked, before bailing out on the whole custom hardware idea.

IMHO the only sane way to approach this problem as a part-timer/hobbiest is to implement the design on a PC with *good* multi-channel soundcard first - get the filter topologies pinned down, identify the control parameters/mechanisms, determine the actual horsepower/memory needed etc. Modern PC's have enough floating-pt capability for virtually anything you can throw at them, and the probramming environment is far far more productive for prototyping/investagative work (unless you're already a DSP expert). Furthermore, a simple linux-based pc w/ say an M-Audio Revo soundcard can be thrown together for maybe $350 or so, and is more than enough for a prototyping platform. (RME or higher-end M-Audio cards are also supported under linux if you want something better)

Once you have the system working on the PC, THEN you start looking at the custom hardware since now you have a firm functional basis on which to design. It may add a few months to the overall design cycle, but the payoff is that you *know* the system will meet the design goals before you start.

For me, I now use Jack under Linux, and really it's incredibly easy to do this - BruteFIR has Jack support for long FIR filters, there are a bunch of LADSPA hosts for simple biquad implementations, you get signal routing and switching for free etc. Input-to-output latency can be as low as a 3-5 ms for biquad based setups - long FIR's like bigger buffers for better efficiency, but I still run 32k tap FIR's in a 3-way xover w/ 16ms latency on a 1.6GHz P4, with plenty of cpu left over.

[tbla]

regarding the biggest newest top of the line meridians.....a friend of mine went for a "listening session" he drove for 3 hours and listened for less than 10 minuts - extremely disappointing.......i still believe that very few people are able to design a good loudspeaker....!!!

[Petter]

Also, it is possible to run National Instruments Labview directly on FPGA's -- which might prove to be the optimally performant system based on a simple GUI development method. I will look into this tomorrow.

Still, even remembering the long discussion about PC versus DSP about a year ago (which turned quite ugly) that the PC based method is probably the simplest. However, this means one effectively enters as a software vendor rather than a hardware vendor.

Petter