More > JRiver Media Center 31 for Windows
NEW: VST Latency Compensation
mumford:
--- Quote from: eve on September 20, 2023, 01:09:11 pm ---You're sort of close here (I use AES67 extensively). I'm sort of confused by your logic though, how would you route your AES67 stream from the Arvus (that you're essentially dumping into an ASIO device) back into JRiver and why?
--- End quote ---
I am thinking of doing an active crossover. So, 16 channels from Arvus out, back into a PC and crossover to 26 channels (hybrid 3 ways for the base layer -- passive between tweeter and mid, active for the woofer, just passive for the atmos, and 2 sub channels). It is not necessary to route audio back to JRiver, can be to a different convolver or even to a separate PC, as long as I have a way to accurately sync them. But, routing back to JRiver has an advantage, as JRiver can sync audio with video, skip video frames if needed.
--- Quote ---The way I'd set this up is JRiver > HDMI > Arvus > AES67 Stream > PC (how you receive the AES67 stream may matter, there's a number of VSC options) > DAW/VST Host and then from there, figure out how much delay you're going to need to add to JRiver (which is playing the video and outputting audio over HDMI).
You need to host Dirac in this case if your goal is Atmos since standalone is capped at 8ch IIRC?
--- End quote ---
Planning on doing ART as VST, running on the PC. Should not have channel limit.
--- Quote ---It's definitely a niche use case (and it's frustrating as heck that we're stuck requiring an Arvus to decode Atmos in real time)
Do you have the Arvus in hand? I've been *really* curious what the latency actually is on it.
--- End quote ---
No, I don't have one yet.
--- Quote ---AES67 on Windows can be a bit of a mixed bag, it's actually comical how bad / hacky some of the commercial VSCs are (they're just outdated IMO, it's gotten easier to work with PTP timestamps on windows in the last few years).
--- End quote ---
Ability to use global PTP timestamps would make things easier.
eve:
--- Quote from: mumford on September 29, 2023, 11:28:42 am ---I am thinking of doing an active crossover. So, 16 channels from Arvus out, back into a PC and crossover to 26 channels (hybrid 3 ways for the base layer -- passive between tweeter and mid, active for the woofer, just passive for the atmos, and 2 sub channels). It is not necessary to route audio back to JRiver, can be to a different convolver or even to a separate PC, as long as I have a way to accurately sync them. But, routing back to JRiver has an advantage, as JRiver can sync audio with video, skip video frames if needed.
Planning on doing ART as VST, running on the PC. Should not have channel limit.
No, I don't have one yet.
Ability to use global PTP timestamps would make things easier.
--- End quote ---
Okay yeah I figured it was something fancy like an active x/over setup.
So that's the thing, you're not getting any benefit going 'back into' JRiver re: sync or skipping video frames. All that is handled by the zone outputting the video (and audio to your Arvus) in this situation. Plus, other than WDM I don't really know what facilities JRiver provides for monitoring live audio. Using JRiver for the playback here is great. You just can't really come back into it in the way I think you're imagining.
This is definitely more suited to a DAW / VST Host. You're very right that it's quite arbitrary where you decide to process the audio, you don't need to be bringing it back into the same computer system that's doing the playback.
In my setup, my workstation, media playback computers, etc don't have physical audio devices actually connected. They output their audio via Dante / AES67 (irrelevant here since I relay my Dante stuff into AES67 / Ravenna and back with the same shared time source) and my various endpoints can pick up those streams. So for example, at my desk, I'm generally connected to both a surround monitoring setup as well as another endpoint that handles headphones. Both get the same multichannel audio 'stream' but of course the headphone endpoint does some fancy downmixing shenanigans', a bit of b2sb crossfeed and correction.
If you're comfortable with Linux, IEEE 1588 support is arguably much better than on Windows, and frankly the entire process for getting AES67 up and running on your own is much closer to documented.
I think Windows will get better. A library I use internally for part of my personal VSC implementation got frankly good PTP support on Windows a while back. It's not available in released builds IIRC but if you can figure out how to build it on your own, it's working quite well.
Merging's free reference VSC for Windows is honestly hot garbage, it's exceedingly unstable in my experience. This is across numerous systems and a bunch of different NICs because, oh yeah, it requires a custom NIC driver to replace your default one so I figured I should see if any of the supported NICs fared better. They didn't. Lots of BSODs on brand new fresh windows installs and different machines.
Audinate's Dante VSC is phenomenal IMO. If you're sticking with Windows it's a solid bet.
kr4:
--- Quote from: eve on October 02, 2023, 11:02:05 pm ---Okay yeah I figured it was something fancy like an active x/over setup.
So that's the thing, you're not getting any benefit going 'back into' JRiver re: sync or skipping video frames. All that is handled by the zone outputting the video (and audio to your Arvus) in this situation. Plus, other than WDM I don't really know what facilities JRiver provides for monitoring live audio. Using JRiver for the playback here is great. You just can't really come back into it in the way I think you're imagining.
This is definitely more suited to a DAW / VST Host. You're very right that it's quite arbitrary where you decide to process the audio, you don't need to be bringing it back into the same computer system that's doing the playback.
--- End quote ---
I am in the same/similar boat. Using MC/PC, Arvus and a HAPI. None Atmos sources originate from MC (using DLART plugin) and route to the HAPI. However, with Atmos (and other immersive sources), it seems appealing to send the intact files from MC to Arvus and the decoded files back to MC for DLART and output to the HAPI. If this a problem, how else can one implement it? Using another source to send the Atmos files still requires MC to receive and process them with Dirac.
eve:
--- Quote from: kr4 on October 03, 2023, 08:41:42 am ---I am in the same/similar boat. Using MC/PC, Arvus and a HAPI. None Atmos sources originate from MC (using DLART plugin) and route to the HAPI. However, with Atmos (and other immersive sources), it seems appealing to send the intact files from MC to Arvus and the decoded files back to MC for DLART and output to the HAPI. If this a problem, how else can one implement it? Using another source to send the Atmos files still requires MC to receive and process them with Dirac.
--- End quote ---
So maybe I'm misunderstanding here but it seems somewhat redundant to go back into MC for the Atmos stuff. I'll explain my thinking.
From what I'm gathering you're looking to use MC's DSP engine along with DLART.
In my mind, that is not needed. You don't really need MC for this stage.
Though you're left with a question, do you want to use MC for DSP on non atmos, and a DSP Host (I'll get into this) for Atmos, or just route everything through a DSP Host?
This is what it might look like.
For non atmos
MC > Merging's MAD (I assume you're taking advantage of this on Windows?) > AES67 Stream #1 > MAD > DSP Host > MAD > AES67 Stream #2 > HAPI
For Atmos
MC > HDMI > Arvus > AES67 Stream #1 > MAD > DSP Host > MAD > AES67 Stream #2 > HAPI
A "DSP Host" could be a bunch of different things here, you're looking for at minimum, a way to load a VST plugin, but I'm thinking you probably do some DSP in MC that would need to be duplicated in said host, so you'll possibly require additional plugins depending on what the host offers out of the box or your specific needs. Now this could be on the same system you're doing playback on but personally, it seems ideal to be it's own thing.
I'm using MAD as an example because it's probably the most ideal driver to work with the HAPI on Windows (Merging Audio hardware can enable low latency ASIO support on Windows). Your DSP host doesn't 'technically' need to be Windows, it could be a Mac, and hypothetically it could be Linux (though VSTs are going to be a little more complex)
We have 2 AES67 streams going on, 1, is what I'd call the source. It's just the audio data coming out of MC or the Arvus, ideally without any serious processing. The second comes after your DSP host, this is the one you want to be consuming on the HAPI for example, it's been processed.
Side note: using AES67 as a shorthand for AES67 or Ravenna. The distinction isn't particularly relevant here.
mumford:
--- Quote from: eve on October 02, 2023, 11:02:05 pm ---Okay yeah I figured it was something fancy like an active x/over setup.
So that's the thing, you're not getting any benefit going 'back into' JRiver re: sync or skipping video frames. All that is handled by the zone outputting the video (and audio to your Arvus) in this situation. Plus, other than WDM I don't really know what facilities JRiver provides for monitoring live audio. Using JRiver for the playback here is great. You just can't really come back into it in the way I think you're imagining.
--- End quote ---
agreed. But, if a timestamp is being carried through the entire chain.... Anyone knows how the broadcast guys do it? They must sync video with audio, just to be sure. No way, they just set a fixed audio delay on a Super Bowl broadcast or whatever.
--- Quote ---This is definitely more suited to a DAW / VST Host. You're very right that it's quite arbitrary where you decide to process the audio, you don't need to be bringing it back into the same computer system that's doing the playback.
--- End quote ---
agreed
--- Quote ---In my setup, my workstation, media playback computers, etc don't have physical audio devices actually connected. They output their audio via Dante / AES67 (irrelevant here since I relay my Dante stuff into AES67 / Ravenna and back with the same shared time source) and my various endpoints can pick up those streams. So for example, at my desk, I'm generally connected to both a surround monitoring setup as well as another endpoint that handles headphones. Both get the same multichannel audio 'stream' but of course the headphone endpoint does some fancy downmixing shenanigans', a bit of b2sb crossfeed and correction.
--- End quote ---
noted
--- Quote ---If you're comfortable with Linux, IEEE 1588 support is arguably much better than on Windows, and frankly the entire process for getting AES67 up and running on your own is much closer to documented.
I think Windows will get better. A library I use internally for part of my personal VSC implementation got frankly good PTP support on Windows a while back. It's not available in released builds IIRC but if you can figure out how to build it on your own, it's working quite well.
--- End quote ---
I am actually much much better with Linux than Windows, as I have been using Linux server for a long, long time. Windows, I just use it to play games, and default on everything. The only reason that i even consider Windows is because Dirac does not support Linux.
--- Quote ---Merging's free reference VSC for Windows is honestly hot garbage, it's exceedingly unstable in my experience. This is across numerous systems and a bunch of different NICs because, oh yeah, it requires a custom NIC driver to replace your default one so I figured I should see if any of the supported NICs fared better. They didn't. Lots of BSODs on brand new fresh windows installs and different machines.
Audinate's Dante VSC is phenomenal IMO. If you're sticking with Windows it's a solid bet.
--- End quote ---
The reason that I am researching Merging's eco system is because Arvus H1-D uses AES67. We are cooking a DIY Storm Audio box over at ASR.
https://www.audiosciencereview.com/forum/index.php?threads/new-product-arvus-h1-d.47117/
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version