Take a look at WiSA. Major tv/speaker manufacturers (will) support it and there are decently priced (compact) devices that take HDMI/USB/analog as input and send to the speakers. There are also DIY options in the form of modules that you can integrate yourself if you have the skills. But you no longer have to deal with multichannel DACs and get the low latency needed for video out of the box. You also break-up the system into smaller (and arguably simpler) parts and get rid of a bunch of cables in the process.
Wireless? No thank you. In fact, wireless (Wifi, Bluetooth etc.) is one of the things I thought was not very useful (and struck off the list) in multi-way multichannel audio. There are similar schemes like Airplay etc. In my opinion, wires, cables and racks are often alright (and reliable) as long as they're managed properly.
Also, I think it's better if you're not stuck to somebody's proprietary protocols, as that would then restrict every piece of equipment you can get thereafter, for example, speakers in WiSA's case. The best (professional) speakers in the market are wired (only) ones. And just imagine what would happen if you want DIY speakers?
However, I happened to note the word "latency" that you mentioned (thanks for reminding me), that might be another parameter that needs to be considered, even in a wired setup. I guess using IIR filters for the processing would solve that issue.
Also, I think it's better if you're not stuck to somebody's proprietary protocols, as that would then restrict every piece of equipment you can get thereafter, for example, speakers in WiSA's case. The best (professional) speakers in the market are wired (only) ones. And just imagine what would happen if you want DIY speakers?
However, I happened to note the word "latency" that you mentioned (thanks for reminding me), that might be another parameter that needs to be considered, even in a wired setup. I guess using IIR filters for the processing would solve that issue.
newvirus2008 - The total propagation delay (ie: latency) using a typical ADC to a computer, using software to create xovers and apply loudspeaker/ room correction and back out to a DAC as I described previously, typically will not exceed 25ms. A 25ms lag in audio behind your video is not detectable.
While appropriate DSP filters can delay very little, the problem is when using a general-purpose OS (like linux or windows) where streams are processed in chunks and the necessary input/output buffers add to latency. Shortening the chunks increases the likelyhood of buffer over/underruns. Of course linux fares much better in this regard because it can be tweaked much more finely, a soft-RT kernel can be used, every part of the sound stack down to the source code is available for optimization. Still the chain requires some reasonably large buffers to make sure it's really reliable.
Should linux be used for the embedded linux AVR ("LAVR"), there would be 3 buffer places within the chain: playback app -> USB-audio driver in the HTPC, USB-audio receiver driver -> DSP app in the LAVR, DSP app -> physical soundcard driver. I guess at least 40-50ms for a reliable playback which is too much for lipsync.
But IF the audio chain latency can be kept constant, consistently between restarts (up to some precision), most video players allow to configure delay of the video stream.
(At least some) video players adjust the video delay with audio latency as reported from the audio subsystem. Windows WASAPI and linux alsa have API for the latency report (OSX probably too). The USB audio specifications include a standardized field with this information. With that a USB-audio device can report its internal delay upstream to the host. If the linux UAC2 driver does not read and report this value already, the code could be added there https://mailman.alsa-project.org/pipermail/alsa-devel/2022-January/194497.html , allowing e.g. mpv to use this latency in AV sync out of the box. The gadget could calculate and report the latency to the host as needed. That's the SW work I was talking about in the previous posts 🙂
Should linux be used for the embedded linux AVR ("LAVR"), there would be 3 buffer places within the chain: playback app -> USB-audio driver in the HTPC, USB-audio receiver driver -> DSP app in the LAVR, DSP app -> physical soundcard driver. I guess at least 40-50ms for a reliable playback which is too much for lipsync.
But IF the audio chain latency can be kept constant, consistently between restarts (up to some precision), most video players allow to configure delay of the video stream.
(At least some) video players adjust the video delay with audio latency as reported from the audio subsystem. Windows WASAPI and linux alsa have API for the latency report (OSX probably too). The USB audio specifications include a standardized field with this information. With that a USB-audio device can report its internal delay upstream to the host. If the linux UAC2 driver does not read and report this value already, the code could be added there https://mailman.alsa-project.org/pipermail/alsa-devel/2022-January/194497.html , allowing e.g. mpv to use this latency in AV sync out of the box. The gadget could calculate and report the latency to the host as needed. That's the SW work I was talking about in the previous posts 🙂
Yes, phofman, thanks for the Linux inputs there. Unfortunately, I do not know any Linux, nor have I used it as an OS. Thus, to me the learning curve could be too steep to handle, pushing me further towards choosing hardware (IC) methods for the processing.
Nevertheless, I'm quite sure that there's a sizable population on this forum that is very capable of Linux programming, and that makes these ideas from members like you highly valuable. This population usually consists of the newest generation kids who not only grew up with a computer but also realised very early in their careers the importance of Linux in open-source software development. To most others, Linux is just an operating system to manage computer files using cut, copy, paste etc. that they may or may not have used. 🙂
Nevertheless, I'm quite sure that there's a sizable population on this forum that is very capable of Linux programming, and that makes these ideas from members like you highly valuable. This population usually consists of the newest generation kids who not only grew up with a computer but also realised very early in their careers the importance of Linux in open-source software development. To most others, Linux is just an operating system to manage computer files using cut, copy, paste etc. that they may or may not have used. 🙂
Last edited:
I did not a mean the regular DSP that needs programming, but a chip meant exclusively for multichannel audio processing applications, like TAS5518 or STA309A. Only the control registers need to be loaded by the user (from a microcontroller), as the DSP routines (filtering etc.) are already loaded from the factory.
I think I'll rather go with ASIC hardware with minimal programming, as my hardware skills are much better than my programming skills. Even if I somehow manage to pick up some programming in the near-future, it's still very unlikely to be sufficient enough to result in a good product that is comparable to commercial units.
So, here's what I'm looking at now (attached).
So, here's what I'm looking at now (attached).
Attachments
Sounds like a very good plan, if you can source the first and most crucial block - the HW proprietary-digital-formats -> PCM decoder. Any ideas about its availability?
a) I have a few STA310 (AC3/DTS/MPEG) with me from sometime ago but unfortunately, this chip is not in production now. If nothing else, I might use it.
b) I also have a Yamaha RX-V571 which, according to the following database (below), seems to use the PCM1681 DAC chip. So, I guess, I just have to pull out the I2S connections from pins 5-8 & 10-13. The bits are probably 24 with 32 bits per slot, giving BCLK of 64fs. Fs could be variable though.
http://www.yamaha-laboratory.ru/Receivers yamaha_2011_Customer.xls
c) Use DVD/Bluray pre-outs through ADCs (not very interesting).
b) I also have a Yamaha RX-V571 which, according to the following database (below), seems to use the PCM1681 DAC chip. So, I guess, I just have to pull out the I2S connections from pins 5-8 & 10-13. The bits are probably 24 with 32 bits per slot, giving BCLK of 64fs. Fs could be variable though.
http://www.yamaha-laboratory.ru/Receivers yamaha_2011_Customer.xls
c) Use DVD/Bluray pre-outs through ADCs (not very interesting).
I decided to stop at 5.1 channels. Decoding the formats was the biggest issue. I am planning to use the Blu-ray and dvD/SACD players to do the decoding. They will send it out as LPCM. I bought a multichannel HDMI to I2S converter board to eBay. We will see how that works. I plan to send the I2S signals to a computer via USB for processing. Processed signals will return via the usb and converted to I2S and fed to Ian’s McFIFO and then fed to 4 AKM 4493 DACS. I am mostly concerned with playing multichannel musical records ripped from dVD-A and Blu-rays.
I think that the AppleTV does all the decoding and sends it out as LPCM. I haven’t bought one yet to try it out.
My Marantz AV receiver is 10 years old and an HDMI computer connection to the receiver doesn’t work.
I think that the AppleTV does all the decoding and sends it out as LPCM. I haven’t bought one yet to try it out.
My Marantz AV receiver is 10 years old and an HDMI computer connection to the receiver doesn’t work.
Yes, wcwc, many people are satisfied with 5.1. The higher configurations use more resources for the surround "immersive-ness" than they do for the fronts, making them somewhat overkill, especially in small rooms.
Once you're I2S, you're in a nice position to do whatever you want with your signals. Though there have been many (really) short threads on HDMI=>I2S/PCM on this forum, it would be very helpful to many if you write your assessment of the said ebay HDMI=>I2S board here. Proper licensed decoding using Blu-ray/DVD is probably the best, but this board could also be useful to those who use their PC / media player as the source.
Maybe you're good at computers and programming, interfacing audio into and out through USB, which is probably why you have that kind of confidence. My Yamaha is also 10 years old and fully functional, and I just feel really bad whenever I think of cannibalising (part of) it.
Once you're I2S, you're in a nice position to do whatever you want with your signals. Though there have been many (really) short threads on HDMI=>I2S/PCM on this forum, it would be very helpful to many if you write your assessment of the said ebay HDMI=>I2S board here. Proper licensed decoding using Blu-ray/DVD is probably the best, but this board could also be useful to those who use their PC / media player as the source.
Maybe you're good at computers and programming, interfacing audio into and out through USB, which is probably why you have that kind of confidence. My Yamaha is also 10 years old and fully functional, and I just feel really bad whenever I think of cannibalising (part of) it.
I’m trying to understand which blu-ray players output a decoded Atmos stream that would be steered to 16 output channels by a receiver that has no Atmos chipset/license. Afaik, the chipset in the receiver is responsible for holding the Atmos speaker configuration meta data - how would you deal with this part?
Can HDMI even pass more than 8 channels of LPCM audio? Not sure of any Bluray players that can decode Atmos to LPCM. I think they are only able to bitstream Atmos.
In my opinion, all those who want Atmos will have to hack an AVR's internals, like I have mentioned above for the Yamaha family. That way, you have a licensed decoder, do not compromise decoder fidelity and also get all features of the AVR except its power amplifier, like source selection, volume control, remote etc.
Alternatively, someone has to come up with a method that allows two graphics cards with accompanying software that would then possibly allow the use of a PC.
However, a 7/1/4 can still have 2-way LCR and an extra sub with a 16ch processing setup.
Alternatively, someone has to come up with a method that allows two graphics cards with accompanying software that would then possibly allow the use of a PC.
However, a 7/1/4 can still have 2-way LCR and an extra sub with a 16ch processing setup.
Multichannel PCM output is no problem, USB UAC2 can handle 42 of 192/24 channels, USB audio gadget 14 192/24 channels out of the box as it does not implement high-bandwidth (multiple transactions) mode.
But decoding Atmos to PCM on a PC is a no go:
https://www.avsforum.com/threads/atmos-decoder-in-2021.3214420/#post-61060229
Most likely the above claim is true, googling revealed no other Atmos decoder for computers, let alone open source.
But decoding Atmos to PCM on a PC is a no go:
https://www.avsforum.com/threads/atmos-decoder-in-2021.3214420/#post-61060229
Most likely the above claim is true, googling revealed no other Atmos decoder for computers, let alone open source.
The AVR hacking method can work but the "hacker" needs to know the sampling frequency and OS ratio to set up the processing interface. If not, the processor must be capable of auto-detecting the same. However, this problem could be simplified by using a fixed sampling frequency ,say 48kHz, all the time.
What extra features would the hacked AVR + the DIY cinema processor combo offer compared to the original non-hacked AVR?
The main idea behind the DIY processor is to operate active multi-way speakers with lots of paraEQ per channel, that most AVR's do not support. However, AVRs are good with the decoding part of things, in fact, they're excellent. For example, my AVR supports only LR bi-amping with a fixed crossover frequency at the expense of the rear surrounds (which is pretty much a useless feature), but it can decode all HD audio formats without any issues.
If, by any chance, you happen to have an Atmos unit that supports at least LCR bi-amping, then you may not need this DIY processor. In short, this kind of stuff is for poor people who can't afford to get themselves the real thing.
If, by any chance, you happen to have an Atmos unit that supports at least LCR bi-amping, then you may not need this DIY processor. In short, this kind of stuff is for poor people who can't afford to get themselves the real thing.