Possible solution for DTS/Dolby/Atmos+eARC+HDCP to AES/EBU - via Dante? (for Okto DAC8PRO etc)

[sfogg]

Engineers normally don’t make decisions simply for buzzword compliance. Sure they could double up the SHARC chips to get the same amount of DSP power at 24/96 as 24/48. But this adds cost and with a transparent SRC most won’t hear the difference.

Except that we had the processing power to handle multichannel 96/24 TWO DECADES ago. Ever heard of Moore's Law?

That processor did the upmixing (what isn't even being done in the SHARCs in your examples) AND the post processing in just under 800megaflops. They added another 800 megaflops for room EQ processing. That is 1.6 gflops for 12 channels.

Your own links are showing the *dramatic* increase in processing power available today. A single 21569 (<$40) is at least 3x more powerful (than the 8 SHARCs in my example above) and it doesn't even have to worry about the upmixing.

This limit has nothing to do with DSP power and everything to do with companies making it cheaper and easier for themselves.

 

[Audiovibes]

Except that we had the processing power to handle multichannel 96/24 TWO DECADES ago. Ever heard of Moore's Law?

That processor did the upmixing (what isn't even being done in the SHARCs in your examples) AND the post processing in just under 800megaflops. They added another 800 megaflops for room EQ processing. That is 1.6 gflops for 12 channels.

Your own links are showing the *dramatic* increase in processing power available today. A single 21569 (<$40) is at least 3x more powerful (than the 8 SHARCs in my example above) and it doesn't even have to worry about the upmixing.

This limit has nothing to do with DSP power and everything to do with companies making it cheaper and easier for themselves.

The Grok info I shared showed that a 21569 would be pushed to the limit with only 16 channels @96k. And that’s not accounting for the actual FIR taps the processor is using. That’s estimating an average (8192 taps/channel). If one wanted to increase the taps for more quality, the channel count could easily be cut down to 8 channels @96k per chip.

Given the most expensive Sharc based processor available (around $24000 I believe) doesn’t even process above 48k internally, I’d like to see what your dream machine would cost when it hits the market.

 

[Audiovibes]

Without discussing GFLOP’s required to preform a task, a reference to a previous piece of gear from 25 years ago provides us with no relevant information.

Here’s what a 16 channel Atmos processor will require in GFLOPS @ both 48&96K, assuming it’s using 8192 tap FIR on each channel. And in the 48K scenario it’s using SRC on the output to upsample to 96K like Storm can now do. Which uses up GFLOPS as well.

 

[sfogg]

The Grok info I shared showed that a 21569 would be pushed to the limit with only 16 channels @96k. And that’s not accounting for the actual FIR taps the processor is using. That’s estimating an average (8192 taps/channel). If one wanted to increase the taps for more quality, the channel count could easily be cut down to 8 channels @96k per chip.

Are you planning on letting GROK do all your thinking for you?

3x more power than a processor that already did 12 channels of 24/96 and you think adding 1/3 more channels with 3x the processing power is going to push it over the edge?

You could double your power again with another 21569 for about the same hardware cost as adding 8 SRC.

Given the most expensive Sharc based processor available (around $24000 I believe) doesn’t even process above 48k internally, I’d like to see what your dream machine would cost when it hits the market.

You understand there were SHARC based processors running interally at 192kHz 20+ years ago, right? It did that with 600 mflops. An outgrowth of that processor was Room EQ Wizard.

 

[Audiovibes]

Read my previous post. We need hard data based on the actual task at hand in order to determine the processing power. Not “I reckon based on a 25 year old piece of gear” “Moore’s law” etc. That provides us with no value.

 

[sfogg]

Without discussing GFLOP’s required to preform a task, a reference to a previous piece of gear from 25 years ago provides us with no relevant information.

Of course it does. In every example you have given, ATMOS processing is being done elsewhere. In other words the load of that has nothing to do with the SHARCs. That leaves the SHARCs to post processing, which is what hardware has been doing for many years. And they did it with dramatically less DSP resources and at higher sampling rates, just not quite as many channels.

This current sampling rate limit has nothing to do with DSP resources. They are cheap and plentiful.

Writing the software is not however.

 

[Audiovibes]

Of course it does. In every example you have given, ATMOS processing is being done elsewhere. In other words the load of that has nothing to do with the SHARCs. That leaves the SHARCs to post processing, which is what hardware has been doing for many years. And they did it with dramatically less DSP resources and at higher sampling rates, just not quite as many channels.

This current sampling rate limit has nothing to do with DSP resources. They are cheap and plentiful.

Writing the software is not however.

Ok you’re right that was only post processing. Here’s the required GFLOPS when we add the Atmos decoding in:

So how many ADSP-21569’s needed for 24/96 processing?

And that’s only 16 channels! Double for 32. The Storm now does 35!

 

[Audiovibes]

I asked Grok to analyze this thread and summarize which information is most accurate. The result:

 

[sfogg]

Are you planning on letting GROK do all your thinking for you?

Guess we have the answer to this question. Hilarious (or sad) using GROK provided info and then using GROK to validate itself.

Of course, instead of using AI generated 'info', we could look at the Denon A1H which has a single SHARC 21593, has 18 channels and if you read its manual, and know what to look for, seems like it runs at native sampling rates.

And even if it was only 48Khz, that one SHARC is doing it. <$40 to add another SHARC and double the DSP processing power... which GROK keeps saying is all that is needed to double the sampling rate.

 

[Audiovibes]

If you can provide more accurate data on modern atmos processor loads please share. Use any tool at your disposal. Go to the library like a real man.

If a company uses an off the shelf pre-programmed chip for Atmos, the SHARC is only used for post-processing. Post processing load can be lower by sacrificing the quality of the algorithms and using few taps in the FIR. And I can assure you none of these cheap processors are internally processing higher than 48k.

 

[Audiovibes]

Regarding the Denon A1H:

 

[sfogg]

Already have.

You keep posting that the ATMOS processing is occurring in other chips, which I agree with. But then you (or GROK) keep claiming the SHARCs have to handle the intensive processor load of ATMOS decoding. It doesn't work that way. By the time the data gets to the SHARCs it is just LPCM, not encoded ATMOS. At that point the SHARC processing load is no different than any other LPCM data with the same number of channels/sampling rate. Which is why the reference to earlier processors and what they could do with far more limited DSP resources is useful information. I have also given reference to what more current audio processor is doing with two older SHARCs.

I completely agree that more complicated room EQ will take more DSP than what the earlier processors had. Which is where the extra couple of GFLOPs that a single current SHARC can give you above and beyond what was needed to handle 12 channels at 96kHz (800mflops) come into play. A 21569 is giving you at least 3.2gflops (maybe 4.2 or more) for more advanced room EQ.

DSP resources and cheap and easy.

Writing your own code is expensive and complicated. That is the reason so many are settling on a single sample rate.

 

[Audiovibes]

I have never claimed the Storm in which I’ve mostly been discussing does Atmos processing in the SHARC. In fact I shared a link to the Atmos processor it uses. I’ve also shared processing loads with and without Atmos processing. The amount of data I’ve shared on this matter in this thread is likely the most comprehensive amount of data regarding this information ever on any forum. (Accurate data anyways). So with that being said I’m out on this topic.

 

[sfogg]

Regarding the Denon A1H

Weirdly, if you go to the library and actually read the A1H manual you will find that when you feed it some sources that have a sampling rate above 48kHz it limits some of the additional post processing you can apply.

Why would it need to do that if it just resampled everything to the same rate? (Hint: It wouldn't......)

And since I just know what is going to happen next....

But of course that isn't fully correct either since the limitation can occur on encoded high resolution sources, it isn't just native playback of PCM audio.

 

[Audiovibes]

Yeah so with PCM it goes direct through bypassing the DSP as no DSP processing is needed. Unless of course you want to use the room correction. Then it’s downsampled to 48k.

I was referring to the formats that require DSP processing. The question was about the DSP.

 

[Audiovibes]

Moving back to the Nuforce H16, I had grok do an assessment on it’s DSP capabilities:

 

[Audiovibes]

This is the Atmos processor Storm uses:

APM-110 « Momentum Data Systems

www.mds-av.com

I’m now up to date on the Storm upgrade. The DSP upgrade is from the MDS to a SHARC ADSP-21589. So it’s only the Atmos processor being upgraded. The same old ADSP-21489 post-processor chips remain. The SRC upgrade was actually released before the new DSP. And it was just firmware.

Old MDS DSP:

New ADSP-SC589 with heatsink:

 

[phofman]

These Grok assessments are really annoying, I do not see any value in that. In this light the AI policy diyaudio is currently discussing is quite useful https://www.diyaudio.com/community/threads/new-site-policy-on-ai-generated-content.431397/

 

[Audiovibes]

These Grok assessments are really annoying, I do not see any value in that. In this light the AI policy diyaudio is currently discussing is quite useful https://www.diyaudio.com/community/threads/new-site-policy-on-ai-generated-content.431397/

Is it better to share inaccurate information? And I’m not using it to write my posts. I’m using it to calculate data. Might as well ban sharing links as well. And use of any software that runs on a computer like an audio analyzer. No computerized tools shall aid us!

 

[phofman]

Since you do not tell the LLM to be short, the response is extremely eloquent - annoying to read. Since it's so long, it's no pleasure to check it for accuracy. Every current LLM is quite bad at remembering precise information from the training phase. Some excel at processing information given at the prompt, using their learned skills (including technical knowledge, I use that often myself). But they certainly do not excel at citing correct information which was transformed into their model parameters (weights between the "neurons") during the training. Most LLMs suck at math calculations - there is a reason ChatGPT has a prompt version which instructs it to send the calculations to wolfram alpha to do the math correctly during the response. No I do not trust what Grok says, certainly would not call it an accurate information. Plus Grok is no SOTA LLM.

Then the posted screenshots of text are just hard to read, impossible to search through.