Hello all,
I was going through the product sheets/manuals for commercial multi-way cinema processors such as the Dolby CP850, Datasat AP20, LS10 etc. Though I quickly gathered how expensive these could be for most people to use at home, I kept scrolling on just to know more. To my surprise, I happened to find that such processors (like most electronic gadgets) offered several features that did not appear very necessary/useful in a home environment that most members on the forum have.
Soon, I was contemplating a basic DIY cinema processor to consolidate all the A-chain functions for a multi-way home speaker system. Based on the data from commercial units, I was able to reduce things to a list of absolutely necessary features including (but not limited to):
The main aim behind starting this thread is to arrive at an affordable DIY home cinema processor that also maintains basic functionality similar to commercial units, from a home cinema point of view. I hope that the learned members on this forum could help further improve this list by sharing their thoughts, experiences, discussions, debates, opinions, ideas etc.
I already understand that there could be several combinations of DIY/ready-made hardware/software, that could be used to achieve typical function. Though I was referring mostly to a standalone processor, all opinions aimed at the welfare of the poor man hobbyist are also welcome. A block diagram for the above scheme is also attached as a starting point, apologies to those who found this post lengthy/boring.
Thanks in advance,
Happy New Year.
I was going through the product sheets/manuals for commercial multi-way cinema processors such as the Dolby CP850, Datasat AP20, LS10 etc. Though I quickly gathered how expensive these could be for most people to use at home, I kept scrolling on just to know more. To my surprise, I happened to find that such processors (like most electronic gadgets) offered several features that did not appear very necessary/useful in a home environment that most members on the forum have.
Soon, I was contemplating a basic DIY cinema processor to consolidate all the A-chain functions for a multi-way home speaker system. Based on the data from commercial units, I was able to reduce things to a list of absolutely necessary features including (but not limited to):
- Multiple input source selection.
- Legacy 6ch AC3/DTS decoding with provision for upto 16ch input (I2S).
- 16-ch assignable outputs of 24-bit/192kHz audio with 32-bit processing with low latency.
- Digital crossover upto 4th order.
- Shelving / Parametric EQ for room/speaker compensation.
- Time alignment.
- Standard LCD display with simple GUI.
- Remote control.
- B-chain (amplifier) control.
The main aim behind starting this thread is to arrive at an affordable DIY home cinema processor that also maintains basic functionality similar to commercial units, from a home cinema point of view. I hope that the learned members on this forum could help further improve this list by sharing their thoughts, experiences, discussions, debates, opinions, ideas etc.
I already understand that there could be several combinations of DIY/ready-made hardware/software, that could be used to achieve typical function. Though I was referring mostly to a standalone processor, all opinions aimed at the welfare of the poor man hobbyist are also welcome. A block diagram for the above scheme is also attached as a starting point, apologies to those who found this post lengthy/boring.
Thanks in advance,
Happy New Year.
Attachments
Last edited:
Quite interesting topic 🙂 ... and for sure I would like one of the more professional decoders / preamps like the ones from Dolby, Datasat, Lexicon or Trinnov 😉
.... but as you say it's simply out of my league money wise ..
But to DIY such a thing I would think is a huge HW task, but even much bigger SW task .... .... but subscribing to the thread 😉
By the way I think some of the above is actually basing their design on a PC running Linux, and then adding and in-out board, at least this is true for Trinnov, and I think also for Lexicon
.... but as you say it's simply out of my league money wise ..
But to DIY such a thing I would think is a huge HW task, but even much bigger SW task .... .... but subscribing to the thread 😉
By the way I think some of the above is actually basing their design on a PC running Linux, and then adding and in-out board, at least this is true for Trinnov, and I think also for Lexicon
Last edited:
The problem with this is licensing. You can't build your own AVR even if you want to because you can't get HDCP keys. Many of the chips you would want are not available to the public in low quantities through normal channels as well. Maybe you can cobble something ugly together, but that's it.
I invite you to take a studied look at the Datasat RS20i. The Datasat RS20i is the High Home Theater version of the Datasat AP20. It does all of those things that you describe plus loudspeaker & room correction using Dirac Live. The RS20i is built on Linux and utilizes 6 DSPs to crunch the numbers. The next version of the RS20i had been planned to run Linux on a PC chassis. The DSPs would have been replaced with code running on the PC.
An audio processor that you failed to mention is the Trinnov Altitude. The Trinnov Altitude is roughly equivalent to the RS20i but runs on a highly custom PC chassis.
An audio processor that you failed to mention is the Trinnov Altitude. The Trinnov Altitude is roughly equivalent to the RS20i but runs on a highly custom PC chassis.
Licensing is an issue but a good deal of that can be resolved buying a DVD/ Blu-Ray player with the Dolby & DTS decoders builtin.
The question is also how many channels are you actually capable of installing in you room. I think I'll be more than good off if I can upgrade to a 7.4.1 installation.
Driving this you can use a receiver like the Marantz SR6015 which is around 1330 € .... one of the processors mentioned are like 10 times this price
It will not have the same flexibility, but using some decent external power amplifiers or active speakers with DSP (for say LCR) I think you will get quite far ....
Driving this you can use a receiver like the Marantz SR6015 which is around 1330 € .... one of the processors mentioned are like 10 times this price
It will not have the same flexibility, but using some decent external power amplifiers or active speakers with DSP (for say LCR) I think you will get quite far ....
So, Linux on PC can probably do something. But how does one get so many inputs and outputs? Doesn't all that need a customised (rather than standard) PC ?
I think I have seen the RS20i user manual somewhere. It has more or less the same features as most Datasat processors. In fact I got to a bare minimum by striking off many things like automation, networking, USB, preset EQ, post processing, touch screen, colour LCD, keypad etc.
Isn't is possible to shift the Room/speaker response measurement to freeware like REW to cut costs? And is it necessary that the Room EQ be automatic like Dirac?
By ugly do you mean those little black SPDIF/HDMI to RCA boxes going around on the ebay?
That's nice to hear, I thought of something like that, or the Linux / open source route otherwise.
16 channels is a number I borrowed from the commercial processor datasheets. With 16ch, you could have a 7.1 with a 4-way LCR (H/M/L/S) if the LFE is summed into the LCR subs and surrounds are 1-way or passive i.e. 3Fx4 + 4S = 16. Alternatively, you could have a 3-way LCR and still be left with two extra subs for more bass.
However, with an increasing number of channels (like in Atmos etc.) one may have to choose 2-way fronts or increase the channel count accordingly.
Unless you are willing to use the decoder Linux pc as a player, you would probably need an HDMI board that can extract the i2s audio, I would not be surprised if all the high end vendors mentioned above buy these from an ODM vendor like momentum data systems, if these boards can be bought in small quantities is another question.
On the output side things are getting pretty interesting with IP based audio (AES67 / Dante), with a proper Linux driver and an onboard Ethernet port an external multichannel DAC with Dante/AES67 input could be deployed, and also amplifiers with a dante input or active speaker with a dante interface.
On the output side things are getting pretty interesting with IP based audio (AES67 / Dante), with a proper Linux driver and an onboard Ethernet port an external multichannel DAC with Dante/AES67 input could be deployed, and also amplifiers with a dante input or active speaker with a dante interface.
Last edited:
newvirus2008 - The easiest way to handle the IO problem is to buy something made by RME (my favorite) or their competitors off of EBay, that handles many channels in & out of your PC. That way you can leave the matrix decoding to be handled by your Blu-Ray player. All of the software that you describe can be had open source and free. Take a look at PORC for loudspeaker/ room correction, and other software packages on this forum for active crossovers.
cph2000 - You are right in assuming that the HDMI cards used by Datasat, Trinnov and others comes from MDS (Momentum Data Systems). However buying one (even if you could) would not accomplish anything for you in that those cards need a lot of tedious programming to use. You might better use you BLu-Ray player to aggregate video sources.
cph2000 - You are right in assuming that the HDMI cards used by Datasat, Trinnov and others comes from MDS (Momentum Data Systems). However buying one (even if you could) would not accomplish anything for you in that those cards need a lot of tedious programming to use. You might better use you BLu-Ray player to aggregate video sources.
OK, so I guess it's safe to assume that the Linux method can get around HDMI / decoding licences. Ethernet also appears to be a good candidate for the input datastream, when compared to HDMI, SPDIF etc, especially since it's a well-understood and open standard.
Does the RME interface connect to the PC via PCI/Express slots on the motherboard? And if this method is easy, why is it not being used commonly ? Does it involve any extra programming etc.? It also defeats the "DIY" part of things.
I can see one disadvantage to PC-based methods that is driver / compatibility issues over the years, as operating systems evolve/update. Besides, with PC, all media must somehow originate from it (or an interface connected to it), say from a hard-disk or bluray drive. Further, if all this requires a separate PC, that also adds to the costs which could hurt the poor man.
Can smaller single-board computers like Raspberry be used to run Linux instead ? I'm asking since I'm illiterate when it comes to computers and software. In fact, I still have a Core2Duo PC running Win XP/7 and a laptop (also Core2Duo) running Windows Vista !
Does the RME interface connect to the PC via PCI/Express slots on the motherboard? And if this method is easy, why is it not being used commonly ? Does it involve any extra programming etc.? It also defeats the "DIY" part of things.
I can see one disadvantage to PC-based methods that is driver / compatibility issues over the years, as operating systems evolve/update. Besides, with PC, all media must somehow originate from it (or an interface connected to it), say from a hard-disk or bluray drive. Further, if all this requires a separate PC, that also adds to the costs which could hurt the poor man.
Can smaller single-board computers like Raspberry be used to run Linux instead ? I'm asking since I'm illiterate when it comes to computers and software. In fact, I still have a Core2Duo PC running Win XP/7 and a laptop (also Core2Duo) running Windows Vista !
The older RME stuff was internal to your computer and used PCI/ Express slots. However the newer stuff uses USB 3.0
and is super easy to use. RME supplies config software for both Windows and Linux. In my experience for this task, Linux is easier to work with than Windows. Raspberry Pi's won't do well in this application. You need CPU muscle to run the multiple apps that you need.
and is super easy to use. RME supplies config software for both Windows and Linux. In my experience for this task, Linux is easier to work with than Windows. Raspberry Pi's won't do well in this application. You need CPU muscle to run the multiple apps that you need.
What's the output format of the audio and where does the actual processing (xover / EQ/ delay) take place? I'm not an audio professional but still tried reading through RME's website and did not follow a thing (promise!). There's no mention of I2S etc. that is universally used by audio ICs.
If I understand correctly, things are discouraging for mainly one reason, and that is Dolby/DTS decoding and the related licensing issues. So if there's something (a box /board) that can replace the "decoder (whatever that is)", then isn't it possible to tap the I2S streams from just before the D/A conversion stage and thereafter use a couple of processing chips like TAS5518 to get the required multi-way crossings and EQ?
If I understand correctly, things are discouraging for mainly one reason, and that is Dolby/DTS decoding and the related licensing issues. So if there's something (a box /board) that can replace the "decoder (whatever that is)", then isn't it possible to tap the I2S streams from just before the D/A conversion stage and thereafter use a couple of processing chips like TAS5518 to get the required multi-way crossings and EQ?
newvirus2008 - If you use a source that can output Dolby or DTS the license issues are resolved. For example I have a 73 inch diagonal tv that has Dolby and DTS decoders built into it. As does my aging Oppo Blu-Ray player.
I see Focusrite has some multichannel DAC/ ADCs that are surprisingly inexpensive. Simply route the output of your DTS/ Dolby analog into your ADC (RME, Focusrite??) converter. Multiple channels of audio are now in your computer. Operate on the signals (ie: xovers, speaker/ room correction) and route back to your ADC/ DAC box. Feed your amplifiers and loudspeakers with what shows as output of the DACs. And that's it!
I see Focusrite has some multichannel DAC/ ADCs that are surprisingly inexpensive. Simply route the output of your DTS/ Dolby analog into your ADC (RME, Focusrite??) converter. Multiple channels of audio are now in your computer. Operate on the signals (ie: xovers, speaker/ room correction) and route back to your ADC/ DAC box. Feed your amplifiers and loudspeakers with what shows as output of the DACs. And that's it!
OK, so it's the computer that operates on the signals using software routines, which is probably why you mentioned CPU power etc. But this, way you need your Bluray/media player, computer and external DAC which, even though modular and all, looks like a lot, resource-wise. Then there's also the extra D/A/D conversion between the decoder and computer that can be avoided.
I also read through a liitle of the PORC thread, it appears to be a free, simple alternative to doing the job that commercial products take a lot of money for. I was hoping to arrive at a DIY processor layout in a similar way, as many DIYers on the forum are very capable of designing / assembling on their own, provided the initial foundations are laid out correctly and convincingly.
Now, let us (for the time being), assume that the decoder part is somehow done, using a box or device or licensed decoder etc. What could be the simplest thing that could perform the processing, if I2S data streams are already available as inputs for all channels ?
I also read through a liitle of the PORC thread, it appears to be a free, simple alternative to doing the job that commercial products take a lot of money for. I was hoping to arrive at a DIY processor layout in a similar way, as many DIYers on the forum are very capable of designing / assembling on their own, provided the initial foundations are laid out correctly and convincingly.
Now, let us (for the time being), assume that the decoder part is somehow done, using a box or device or licensed decoder etc. What could be the simplest thing that could perform the processing, if I2S data streams are already available as inputs for all channels ?
IMO the linux way is already viable. Rockchip64 ARM SoCs offer 2x 8ch I2S lines, with multiple I2S inputs, slave mode. ESS offers 8ch DACs with decent params (ES9080). All required clocks (MCLK, I2S clocks) can be generated by inexpensive yet very flexible and low-jitter Si5340/41. SPDIF inputs via SPDIF receivers hooked to the I2S inputs, the Si chips could derive the output clocks from clock recovered by the SPDIF receiver to avoid ASRC. Connection to the Win/OSX/Linux HTPC handling video via USB audio gadget with configurable channel count/switchable samplerate. DSP running on the ARM SoC derived from the open-source CamillaDSP. No HDMI inputs as that requires licences/HDCP etc. Decoding of the licences audio formats preferrably directly by the HTPC with licenced SW or linux decoders, multichannel output to the DSP box via USB audio. Basically a 16ch ultra-flexible DSP USB-audio box with analog outputs and USB/SPDIF inputs (analog inputs possible with an optional ADC via I2S inputs).
Thanks phofman, so it's PC=>USB=>SPDIF =>I2S =>ARM DSP=>ESS DAC =>Out. Any idea what these cost and how the processing on the Rockchip64 works?
Actually it would be PC => USB => ARM DSP =>I2S => ESS DAC =>Out, or SPDIF => I2S => ARM DSP =>I2S => ESS DAC =>Out, or SPDIF => I2S => ARM DSP => USB => PC, or In => ADC=> I2S => ARM DSP => I2S => ESS DAC =>Out, or In => ADC => I2S => ARM DSP => USB => PC, or anything you build 🙂
There would be linux running of the Rockchip64, a number of SBCs are available by several vendors, priced typically < 100USD. It does not have to be Rockchip64, there are other ARM SoCs with multiple multichannel I2S peripherals, I think AmLogic makes them too.
It's mostly about software, latest linux kernel, etc. But an FPGA solution is about software too and from my POV more difficult to develop and diagnose. But I am a linux guy, no FPGA experience. Others may view it differently, perfectly OK.
There would be linux running of the Rockchip64, a number of SBCs are available by several vendors, priced typically < 100USD. It does not have to be Rockchip64, there are other ARM SoCs with multiple multichannel I2S peripherals, I think AmLogic makes them too.
It's mostly about software, latest linux kernel, etc. But an FPGA solution is about software too and from my POV more difficult to develop and diagnose. But I am a linux guy, no FPGA experience. Others may view it differently, perfectly OK.
The first one (PC => USB => ARM DSP =>I2S => ESS DAC =>Out) appears to be most direct. Is the Linux programming (for the ARM processing) easy to do? If yes, then this could be the answer to most people who can write decent code. However, it needs a platform to run, bringing in an SBC or PC into the picture.
Another small question, where does Linux sit on an SBC, like is it a hard-disk or SD card, what is the bootable device that holds Linux on such small boards? Or is it an embedded OS?
Another small question, where does Linux sit on an SBC, like is it a hard-disk or SD card, what is the bootable device that holds Linux on such small boards? Or is it an embedded OS?
The other paths show optional features offered by regular AVRs (SPDIF inputs, analog inputs).
An SBC with the ARM SoC is the platform. Like RaspberryPi, which would be the preferred platform from the SW POV but offers only one 2ch I2S I/O, no multichannel. Of course it requires some linux skills, like any other solution 🙂
The SW (OS+user space) is typically loaded into some eMMC on the SBC. Examples being e.g. https://www.pine64.org/rockpro64/ or https://www.khadas.com/product-page/vim3 (I have not checked what I2S pins these offer on their pinheaders but at least the Rock64 SoC implements what's needed).
So I gather from all the previous replies from various members that Linux is a possibility that allows:
1) Getting around the licensing issues of decoding the proprietary formats.
2) Flexibility in the number of inputs / outputs for processing.
3) An easy, cost-effective and modular way of dealing with the requirements.
provided
1) One is prepared to use the PC as the source (not necessarily but mostly).
2) There's a platform (PC/SBC) for Linux to run on.
3) One has the programming skills to write routines for interfacing / processing the audio.
Further, there are free, open-source methods (PORC) available for room/speaker correction, which I believe would also work on Linux.
1) Getting around the licensing issues of decoding the proprietary formats.
2) Flexibility in the number of inputs / outputs for processing.
3) An easy, cost-effective and modular way of dealing with the requirements.
provided
1) One is prepared to use the PC as the source (not necessarily but mostly).
2) There's a platform (PC/SBC) for Linux to run on.
3) One has the programming skills to write routines for interfacing / processing the audio.
Further, there are free, open-source methods (PORC) available for room/speaker correction, which I believe would also work on Linux.