TI biquad filters
Hi Petter,
Great suggestion. We did not know these exist. From 5-16 biquad filter stages.
1) Are the ones with built-in ADC/DAC good enough?
2) Should we use the all digital ones and use better ADC/DACS?
Dale
Hi Petter,
Great suggestion. We did not know these exist. From 5-16 biquad filter stages.
1) Are the ones with built-in ADC/DAC good enough?
2) Should we use the all digital ones and use better ADC/DACS?
Dale
Out of interest, what are you considering as competition for multi-channel decoding? Is there a DIY solution for this, whether in the form of a board that can be integrated or a total kit?
I'm contemplating building both a DAC and a Preamp, but see it being obsolete in no time. I could build multi-channel units, but how do I get the (DVD) signal into multi-channel?
Hi Scraggles,
I guess that I was referring to all of the inexpensive HT preamps/receivers on the market. The licenses are geared towards shipping lots of units. Dolby Labs wants a bundle just to play.
There are no DIY solutions, and I fear that this is beyond most people, including me!
Dale
I guess that I was referring to all of the inexpensive HT preamps/receivers on the market. The licenses are geared towards shipping lots of units. Dolby Labs wants a bundle just to play.
There are no DIY solutions, and I fear that this is beyond most people, including me!
Dale
active speakers
What do people think about a system like this?
First there is a small PCB board: Call it BOARD A
BOARD A features:
(SPDIF and/or analog input)-> (I2S)->(differential output I2S (For long cable lengths) onto ethernet type cable)
a microcontroller to act as CAN Master node and have a USB PC interface.
The CAN bus is also placed on the ethernet cable.
There would probably be three RJ-45 jacks on this board. (one for each
speaker)
Then embedded inside each one of your speakers (maybe?) is BOARD B.
BOARD B: features
(differential input I2S )->(I2S)->(DSP digital filters with three
outputs)->(3 x 24 bit audio DAC outputs)->(volume controller)->(your power amp here)
There would be some sort of switch on the board where you would select L, R,or L+R (for example, even though the digital input would contain both L and R data.
The board could ignore the data it didn't need it for that particular speaker. or could mix L&R for bass managment etc..)
a microcontroller would act as a CAN Slave node and would send all received commands to the DSP.
BOARD A: could then receive all of the filter parameters via the USB bus.
BOARD A would then pass all of this filter parameters over the CAN bus
to the microcontroller on BOARD B, where they would be passed to the DSP
and to volume controller. That way you have digital going all the way to
your speaker.
The microcontroller would then store these parameters into EEPROM for later
use.
Does this seem like a good idea to anyone, or am I nuts!
Thanks,
Craig Beiferman
What do people think about a system like this?
First there is a small PCB board: Call it BOARD A
BOARD A features:
(SPDIF and/or analog input)-> (I2S)->(differential output I2S (For long cable lengths) onto ethernet type cable)
a microcontroller to act as CAN Master node and have a USB PC interface.
The CAN bus is also placed on the ethernet cable.
There would probably be three RJ-45 jacks on this board. (one for each
speaker)
Then embedded inside each one of your speakers (maybe?) is BOARD B.
BOARD B: features
(differential input I2S )->(I2S)->(DSP digital filters with three
outputs)->(3 x 24 bit audio DAC outputs)->(volume controller)->(your power amp here)
There would be some sort of switch on the board where you would select L, R,or L+R (for example, even though the digital input would contain both L and R data.
The board could ignore the data it didn't need it for that particular speaker. or could mix L&R for bass managment etc..)
a microcontroller would act as a CAN Slave node and would send all received commands to the DSP.
BOARD A: could then receive all of the filter parameters via the USB bus.
BOARD A would then pass all of this filter parameters over the CAN bus
to the microcontroller on BOARD B, where they would be passed to the DSP
and to volume controller. That way you have digital going all the way to
your speaker.
The microcontroller would then store these parameters into EEPROM for later
use.
Does this seem like a good idea to anyone, or am I nuts!
Thanks,
Craig Beiferman
Sounds good Craig, but do we really need another volume stage? It would only really be of any use if you just had one source, such as a cd player, and used the crossover as a pre as well. And you will also lose sales of the Apox kits!
Maybe you could also make the B board a basic 2 channel system, with extra add on boards each with another two channels worth of processing/DAC, for those with greater crossover needs. This might make it cheaper for those with lesser requirements, or the financially challenged😉
Maybe you could also make the B board a basic 2 channel system, with extra add on boards each with another two channels worth of processing/DAC, for those with greater crossover needs. This might make it cheaper for those with lesser requirements, or the financially challenged😉
The crossover is really geared towards DIY'ers that want to build "active" loudspeakers. For them, there would be a fully digital link from the source (CD) to the speaker. There will also be a ADC for those with analog inputs.
For this application, the volume control should be after the crossover in the analog domain.
We envision this system as just another choice in the APOX system. You could, of course, bypass the volume control on the crossover board and use one of the other APOX boards.
Of course, one could put all boards in a chassis and run amp outputs to the speakers. The break up of the boards lets the user choose either method.
Dale
For this application, the volume control should be after the crossover in the analog domain.
We envision this system as just another choice in the APOX system. You could, of course, bypass the volume control on the crossover board and use one of the other APOX boards.
Of course, one could put all boards in a chassis and run amp outputs to the speakers. The break up of the boards lets the user choose either method.
Dale
You definitely need volume control in crossover modules to adjust volume for individual drivers. But the question remains if it should be as elaborate as APOX, or a simple trimpot which later can be replaced with fixed resistor would be enough? As you gear it towards DIY'ers, the latter could be cheaper and probably better sounding solution😉
Hi Peter,
Here is our thought on the subject.
If you are actually doing an active speaker and would like the crossover/amps at the speaker, you would need to control the volume at the speaker. The crossover is acting like a preamp in this case.
Dale
Here is our thought on the subject.
If you are actually doing an active speaker and would like the crossover/amps at the speaker, you would need to control the volume at the speaker. The crossover is acting like a preamp in this case.
Dale
This makes sense, but I guess you need a source switching unit in case you want more than one source.
harvardian said:
I understand completely that you want to make a killer system, and I see how the on board volume controls fit in with that idea. However, I think you are limiting your potential market by having this as a built in expense that I suspect most users will not use, as they already have pre amps and multi channel decoder systems.
How about just having a plug in option that will just transfer data to one of the standard Apox system boards if people want this facility, and can be bypassed by those that have existing system components to integrate.
BTW, I can't wait for the IS1, as I am in need of a simple way to remote my GCs for my bedroom system😉
I guess that I am either very confused or not explaining myself correctly.
Here is one use of the system:
1) User has CD/DVD player with SPDIF (digital) output. User connects to our board A (input/driver board). This is a raw digital signal. How does one control volume? Some CD's can control in the digital domain, but this may reduce resolution.
For the other analog inputs, you could feed the raw analog or a pre-amped signal.
Of course, one could just not install the volume chips and bypass the signals. They are expensive!
Dale
Here is one use of the system:
1) User has CD/DVD player with SPDIF (digital) output. User connects to our board A (input/driver board). This is a raw digital signal. How does one control volume? Some CD's can control in the digital domain, but this may reduce resolution.
For the other analog inputs, you could feed the raw analog or a pre-amped signal.
Of course, one could just not install the volume chips and bypass the signals. They are expensive!
Dale
Just FYI, have you all seen the SHARC XO project in AudioExpress May-July 2001? (June has the meat of the design) Uses 2 ADSP21061 DSPs.
Looks like the author's web site no longer functions so code might be difficult to obtain.
Looks like the author's web site no longer functions so code might be difficult to obtain.
Surround decoding
Surround decoding is EASY on the PC, because there are several vendors who offer such functionality at a reasonable cost.
I would personally like to see a PC based solution, perhaps with some external stuff, ideally all controlled from the PC (or an Apox).
I have played with the Behringer GUI some, and it is probably very labour intensive to create such a GUI, particularly the GUI on the device itself. Download the PC software and judge for yourselves.
Petter
Surround decoding is EASY on the PC, because there are several vendors who offer such functionality at a reasonable cost.
I would personally like to see a PC based solution, perhaps with some external stuff, ideally all controlled from the PC (or an Apox).
I have played with the Behringer GUI some, and it is probably very labour intensive to create such a GUI, particularly the GUI on the device itself. Download the PC software and judge for yourselves.
Petter
Re: Surround decoding
In addition, I want to suggest that the software interface should interact with this box using an "open" standard. I feel the "right" way to visualise the digital xo box is as a server, and the control program on the PC/Mac/whatever is a client which connects to the server, reconfigures it, sends parameters, gets status, etc. That way, the protocol between server and client will be a clean dividing point, allowing independent DIY paths of development for the two. If you build the digital xo box on a PC, you can actually embed a small HTTP server on it, and control the box over an Ethernet cable from anywhere.
I feel that if HTTP is not an option, then USB could be used. USB devices come in various classes, and the simplest class is "memory" or "storage" devices. Such a device just appears as an array of bytes to the computer. If your digital xo box can pretend to be a "storage USB device", then people can write programs on any OS, on any type of hardware, to control it. All commands from the control program to the xo box can be transmitted by writing specific messages to specific locations in this "storage" area, and return values can be communicated from the box to the computer by messages in other parts of the "storage" area. In essence, a chunk of memory on the xo box becomes a message passing area. If the designers adopt this design and publish the message protocols first, then software design and hardware design can proceed in parallel. And then, we don't have to worry about USB support on this or that OS. It will always be possible to "mount" the USB device as a "storage" device in any modern OS, and then any program can be written in any programming language to communicate by reading and writing messages in that storage area. Issues of shared data structure locking will not arise, because all communication will be initiated by the "client" (i.e. the computer) and the "server" (the xo box) will only respond, using a kind of remote procedure call mechanism.
Hope this makes sense. I've seen a disproportionate focus on hardware in other threads sometimes, leading to ignoring some critical software design issues. I understand software better than hardware, so this hurts. 😀 Let's hope this one will be different.
I don't care if the designers use proprietary hardware or build on a PC. I know that if I had to build it, I'd start with a PC, in order to "stand on the shoulders of" that hardware. However, all of us stand to lose if ease of use, generality or functionality is compromised because "it would be too much work to provide it on our proprietary hardware design" but could have been provided trivially using off-the-shelf hardware on a PC (e.g. USB interface, Ethernet interface, etc.) Today, even Ethernet-ready laser printers have HTTP servers embedded; I'm sure it's easier writing a printer's firmware than the xo box.
Personally, I think it will be a big tragedy if such a lovely xo solution is built, but is built in such a way that only some proprietary software programs on some specific OSs can control it. It'll kill the growth of the use of the box, and I will almost certainly never use it.
Tarun
I agree. I too believe a PC-based solution makes more sense. In this context, dwk123's post about first building a prototype on a PC makes total sense. And I feel that if the aim is just to build an xo, BruteFIR and Friends seem to prove that one modern PC can handle a 4-way stereo xo + eq quite well.Petter said:
In addition, I want to suggest that the software interface should interact with this box using an "open" standard. I feel the "right" way to visualise the digital xo box is as a server, and the control program on the PC/Mac/whatever is a client which connects to the server, reconfigures it, sends parameters, gets status, etc. That way, the protocol between server and client will be a clean dividing point, allowing independent DIY paths of development for the two. If you build the digital xo box on a PC, you can actually embed a small HTTP server on it, and control the box over an Ethernet cable from anywhere.
I feel that if HTTP is not an option, then USB could be used. USB devices come in various classes, and the simplest class is "memory" or "storage" devices. Such a device just appears as an array of bytes to the computer. If your digital xo box can pretend to be a "storage USB device", then people can write programs on any OS, on any type of hardware, to control it. All commands from the control program to the xo box can be transmitted by writing specific messages to specific locations in this "storage" area, and return values can be communicated from the box to the computer by messages in other parts of the "storage" area. In essence, a chunk of memory on the xo box becomes a message passing area. If the designers adopt this design and publish the message protocols first, then software design and hardware design can proceed in parallel. And then, we don't have to worry about USB support on this or that OS. It will always be possible to "mount" the USB device as a "storage" device in any modern OS, and then any program can be written in any programming language to communicate by reading and writing messages in that storage area. Issues of shared data structure locking will not arise, because all communication will be initiated by the "client" (i.e. the computer) and the "server" (the xo box) will only respond, using a kind of remote procedure call mechanism.
Hope this makes sense. I've seen a disproportionate focus on hardware in other threads sometimes, leading to ignoring some critical software design issues. I understand software better than hardware, so this hurts. 😀 Let's hope this one will be different.
I don't care if the designers use proprietary hardware or build on a PC. I know that if I had to build it, I'd start with a PC, in order to "stand on the shoulders of" that hardware. However, all of us stand to lose if ease of use, generality or functionality is compromised because "it would be too much work to provide it on our proprietary hardware design" but could have been provided trivially using off-the-shelf hardware on a PC (e.g. USB interface, Ethernet interface, etc.) Today, even Ethernet-ready laser printers have HTTP servers embedded; I'm sure it's easier writing a printer's firmware than the xo box.
Personally, I think it will be a big tragedy if such a lovely xo solution is built, but is built in such a way that only some proprietary software programs on some specific OSs can control it. It'll kill the growth of the use of the box, and I will almost certainly never use it.
Tarun
By the same token I would not be interested in a PC based system. I would be very interested in a simple digital in digital out with 3-4 bands of EQ on the outputs, but it really needs to be plug and play, set and forget, etc etc.
Sure use a PC to configure, as TACT does, but I like my little reliable quiet moveable boxes.
BTW, what timeframe are we talking about?
Steve
Sure use a PC to configure, as TACT does, but I like my little reliable quiet moveable boxes.
BTW, what timeframe are we talking about?
Steve
I just downloaded media player: Foobar - it is quite possible this machine has the required functionality, but since i have moved to other methods (Behringer) have less time pressure to figure this out 🙂
Petter
Petter
The two approaches don't need to be mutually exclusive. The hardware designer can build using a PC motherboard, and this motherboard can go into a box which looks like a VHS videocassette player. Such cabinets exist. Of course, serious DIYers will probably build their own cabinet. In either case, it'll look just like a set and forget box for the user. Only the hardware designer will know it's a PC inside. No keyboard, mouse, etc needs to remain connected. You'll plug in the USB or Ethernet port whenever you need to configure/monitor it, that's all.sfdoddsy said:
In fact, I too would be totally disinclined to use something which looks and sounds like a PC (noisy fans, keyboard, monitor, etc) next to my audio system. I want a box, 17" wide, a foot deep, and black in colour. 😀
A PC is no longer a PC, check the Mini-ITX Website
You lost me here. Timeframe for?
Tarun
- Status
- Not open for further replies.