Messages

A recent review by a well respected online loudspeaker magazine of a propsective competitor to the Ultimate Preamp whose product also runs Audioweaver produced the following indepedent measurements on an Audio Precision APx555 audio analyzer As can be seen the THD+N is about 1 order of magnitude worse than what we were able to measure on our dscope III analyzer and I dare say it that we were pushing the lower limits of our own analyzer so I would expect to see even better results on an APx555 which is the gold standard these days

This is a very average result and little wonder it didn't stay up long on ASR and was renmoved rather quickly

[Does DSP Concepts have a runtime for the Raspberry Pi 3 ?]

After version 6.17 of Audioweaver DSP concepts changed the base support package so you could no longer integrate your own code with the Audioweaver code so from thereon the Audioweaver code has exclusive control of the DSP and you talk to it through another host micro. Because of that, you have to write special routines in the Audioweaver base support package just to do simple things like change the master volume etc. As I do a large amount of housekeeping functions on the SHARC DSP this is not practical nor do I have a host micro on the board. Having said that, you can still leverage the latest version of Audioweaver by running it on a PC and use the audio-conduit functionality offered by the Ultimate-Preamp Plus and this will not impact on the sound quality at all whilst expanding the DSP functionality. If you don't want to use a PC or don't need to use Audioweaver then you could use something like a Raspberry Pi-5 which uses a Broadcom BCM2712 with 4-cores based on an ARM-Cortex A76 with plenty of Level 1/2/3 cache and really cheap too at $133 AUD a piece the last time I checked

And I just checked there is a version of Audioweaver that runs on a Rasberry Pi. Not sure if this will interface with the UPP but it's a possibility

https://dspconcepts.com/forums/audio-weaver-general/362-does-dsp-concepts-have-runtime-raspberry-pi-3

Does DSP Concepts have a runtime for the Raspberry Pi 3 ?

Yes, we offer two different products that can run on the Raspberry Pi 3.

1. AWE_command_line - This is the Audio Weaver Server command line application, which relies on ALSA to handle audio inputs and outputs. On the Raspberry Pi 3, to handle real-time audio we usually use a USB sound card (something like the "Plugable USB Audio Adapter"). Usage of AWE_command_line can be seen in our 'Linux Integration Guide' here: https://dspconcepts.com/support

2. AWELib - Delivered as a set of libraries with example/reference integrations, AWELib provides an API to create and tune your audio processing system and is easily integrated into other applications. With AWELib, it is up to the user to implement the audio inputs and outputs.

 

Both AWE_command_line and AWELib running on your Pi can connect directly to Designer on your PC for testing and tuning purposes. Alternatively, user created scripts or applications can be used to interact with and tune your Audio Weaver driven systems.

 

If you're interested in evaluating one or both of these products, please email info@dspconcepts.com to begin an engagement.

 

Thanks

-Axel

The following Jitter tests illustrate the benefit of using the built-in Inter-sample Overs Guard in preventing internal numerical overflow inside the asynchronous sample rate converter of the SHARC DSP. We used the same J-test methodology that we used for our other tests.

Firstly the following shows the scope screen capture of one channel of the output of the Preamp with the J-test signal from the analyzer applied directly to the USB port of the Preamp. For all intents and purposes, it should look like a 12kHz sinewave but because of Intersample Overs, there is internal overflow in the sample rate converter which manifests itself as waveform distortion similar to clipping which is a side effect of upsampling or interpolating to a higher sampling rate.



The following shows the resultant FFT spectrum and notable artifacts can be observed.



Expanding the frequency scale of the spectrum above shows in much more detail the problems caused by the inter-sample overs.



With the Inter-samples Guard switched on we noted how many times the sample rate converter was overloading in the statistics collecting mode ! Once activated the Guard reduced the signal input level to avoid any more internal arithmetic overflows and reported that the signal had to be reduced by 3dB to achieve this.



And the signal from the output of the Preamp was reduced in amplitude by 3dB but is no longer visually distorted!



Now let's see the effect on the J-test spectrum from the analyzer. A vastly much improved and cleaner spectrum is observed below when the sample rate converter is not overloading and essentially proves how transparent the SHARC sample rate convert is !



The expanded frequency scale of the above FFT spectrum is shown below !

Someone emailed me recently after I posted the results of routing digital audio through an external PC for the purposes of expanding the DSP capability of the Ultimate-Preamp and asked whether or not using a PC adds any additional noise, distortion or jitter to the audio stream ? Well I said in theory it shouldn't due to the isolation and transparency provided by this interface but there is only one way to find out and that is to measure it.

So using the same J-test methodolgy that we used for the normal jitter tests on the various inputs to the preamp we can now apply the same test methodology whilst routing the audio through an external Dell PC used in our lab and see how it affects the jitter and noise. So we setup Audioweaver on a PC to process audio from the Preamp at 192kHz in a direct input-to-output connection as in the following:-



Then we measured the jitter from the output of the Preamp using the same J-test methodology as we used on earlier tests of jitter.



The screenshot below is the same as above but with an expanded frequency scale.



We did the same for THD+Noise.



As can be seen in the test results above the PC is essentially transparent to the audio stream and does not add any noise, distortion or jitter to the incoming audio stream thanks to the hardware of the Ultimate Preamplifier Plus. This is contrary to the reputation of PC's as a noisy and hostile environment due to high speed digital design along with a switching power supply not optimized for low noise. However, the UPP mitigates these issues with ease. In other words don't waste your money with fancy re-clockers and FIFO's because the Ultimate Preamplifier does it all for you and the test results above speak for themselves

https://analog-precision.com/forum/performance-and-measurements/jitter-tests/

https://analog-precision.com/forum/performance-and-measurements/thd-n-balance-output/

.

Hate to break the bad news !!

Not as simple as the more expensive turntable the better !!

Any update on the Board?
Upgrade to all latest chips would be amazing.
ES9039PRO
ES9842PRO
Latest sharc dsp.
Dsd 512 or 1024 capability. That would be amazing😄

From what I can see from the datasheets the only thing that the 9039 offers over the 9038PRO is support for MQA but that is now dead in the water so I wouldn't want to change that part. The Rev:D board includes the new ADC but I am still using the Rev:C board for prototyping. I'm not sure if I would want to upgrade to a newer SHARC part because that means a complete board re-design using a BGA part and migration to a new development platform and for the additional performance it is probably not worth the effort. Also I don't think I can easily integrate the newer versions of Audioweaver as they changed their format after 6.17 which relies on the base support package running exclusively on the SHARC DSP so the necessity for another slave micro just for house-keeping. This means you have to write special custom functions for Audioweaver just to control things like DAC volume and input source selection etc and with all of the options that are on the existing Preamp this would become unwieldy very quickly

From a DSP perspective and given what I have been able to achieve on the UPP using an external PC it would probably be more prudent to offer an upgrade to existing UP2 owners for this capability rather than redesign a new board when the existing Rev:C board works so well Not only that you get to use the latest version of Audioweaver on the PC whilst the SHARC DSP is still locked into using the earlier version of Audioweaver. The DSD limit of DSD-256 was limited by the master clock from the Amanero USB audio interface device.

https://analog-precision.com/forum/performance-and-measurements/ultimate-preamp-vs-deqx/msg937/#msg937

For the DSD aficionados, I have Jriver outputting a DSD-256 bitstream (11.289MHz) to the Preamp which is then processing it through 8 FIR filters each with 64k (65536) taps @48kHz sampling rate and the PC is not even breaking a sweat

Reminds me of a Kick-Starter or Indiegogo campaign. How many of those ended in failure where the punters lost their money ? The ASR thread on DEQX's unfinished product should have been relegated to the Desperate Dealers forum on ASR. Ironically it's hypocritical how stereonet disables links to ASR but must have welcomed this thread with open arms. I don't think Amir got rewarded a brand new house on a 1 acre block from it

And like you said the thread extolling the virtues of a new DSP product using Audioweaver that was canvassed on stereonet not so long ago was derailed almost immediately by the same DEQX shill as being too convoluted to use Go figure ! Of course, Minidsp like the Wilsenton audio thread on stereonet gets free plugs all day long whilst the local manufacturers have to pay through the nose With stereonet it all depends on who you are and whether or not you are part of their cabal or of financial benefit to the owner. Merit has nothing to do with it

Sounds like the DEQX PRe-8 is running out of clock cycles or the Linux bloatware is stealing away valuable resources. That will learn-ya

After some waiting I have been starting to use my Pre-8, very intensive last two weeks.

Some Trouble:
-A alot of "snapping" / crackling sounds, dont know the english word. Sometimes its not even possible to listen and sometimes if I start on low volume and keep it like that there are no such sounds for hours.
If I then play loud for a while the very irritating sounds starts and they dont go away even on low volume.
Anyone alse experience the same?

-Para-eq lives it own life, it often changes the q value. I havnt really figured out when and why yet.

I hope it goes well for Deqx so we get a finished product, this Beta stege is a little painful in many ways.

This is for the DEQX shills who said that only 65k taps per channel is the only acceptable solution! I hatched up a simple test of 8 FIR filters in Audio Weaver each with 65k taps running concurrently with a sample rate of 48kHz !! Note the resource usage in the server window, hovering at around 15% ! Had no trouble running Jriver on the same PC whilst processing the eight FIR filters concurrently without any Snap-Crackle-or-Pop !! All lucky Ultimate Preamplifier owners have this capability

Recently a customer asked me about linearizing the phase of their non-minimum phase crossover they had implemented on the Ultimate-Preamp. Originally specified with two FIR filters comprising of 4096 taps per channel at 192 kHz. Why not increase the filter resolution to 32k taps per channel @192kHz which is equivalent to 128k taps per channel at 48kHz and there is plenty of room left in the tank !! Eat this DEQX shills - why would you bother using a phone chip ??

More info can be found here:- https://analog-precision.com/forum/wiki-and-qa/extending-the-dsp-capability-of-the-ultimate-preamplifier-plus/

A great read for anyone interested or skeptical of class-D amplifiers

LIFE ON THE EDGE – A PERSONAL PERSPECTIVE ON THE PAST, PRESENT, AND FUTURE OF CLASS D AUDIO AMPLIFIERS

BRUNO PUTZEYS OCTOBER 22, 2024 30TH ANNIVERSARY THE NOW

To quote:-

"20,000 taps total....2000 taps to the tweeter, 4000 taps to the midrange and 4000 taps to the bass"

Really and all at 96kHz sample rate from a pair of first gen SHARC DSP's ?? Somehow I don't think so unless they knew some undocumented SHARC instructions that nobody else knew at the time or they were able to overclock the crapper out of it which gave them 15 times the DSP capability but I doubt it very much LOL

Let's do the math. Assuming they were using a first-gen Analog Devices SHARC aka ADSP-21065L clocked at 66MHz which offers 66 MMacs (million multiply-accumulates or taps per second). This is the same device part used in the popular Behringer DSP crossover but DEQX used two of them - one for each channel. According to the datasheet for this DSP the best case timing for each FIR tap is 15nS which corresponds to a 66MHz clock or 66MMacs performance.



To calculate the number of taps per sample you divide 66 million by the sample rate of 96000 which gives 687 taps per sample for each channel at 96kHz !! And the frequency resolution of these filters would be 139Hz best case ! That's only in stereo though ! Over six channels the figure drops to 229 taps or a frequency resolution of 3x the stereo case or 417Hz !! Seriously !!

To put that into perspective the 4th gen SHARC part used in our preamp and a lot of minidsp products is capable of 800 MMacs + another 800 MMacs from the on-chip FIR accelerators with a grand total of a theoretical maximum of 1.6 G-MAcs or 16,666 taps per sample @96k which equates to a 11.52Hz resolution on both channels @96 kHz !! What on earth were DEQX offering with such a small amount of DSP capability and only until 2021 did they decide to pull this product ? With only 139Hz resolution you won't be doing too much correction below 1kHz ! Am I missing something here or is it just lots of marketing blurb covering up a mediocre product that not too many bothered to scrutinize? What kludges were being done with such a poor "group delay correction" resolution on offer ? It certainly was not 10k taps per channel like it was stated. If 10k taps per channel is now considered inadequate how on earth was a measily 687 taps per channel in the previous DEQX offerings ever going to cut the mustard ?

What on earth have they been selling to all of the punters for all of these years ? Did anyone ever bother to do the back-of-the-napkin calculations ? Was this the real reason they pulled the product around 2020 when I originally published the tap count on our website and then they realized it wasn't too long before someone put two and two together to expose the mediocrity of it all ??

Apart from exaggerating the performance of their previous offerings by a factor of 15x the representative from deqx being interviewed had trouble explaining the definition of a digital 'tap' as it applied to the basic building block of an FIR filter !! This should ring the alarm bells for anyone seeking technical advice from them. Also, the BS about the SHARC parts not offering better-performing devices compared to ARM cores is total balony as I proved in a previous post. Even the 4th gen SHARC part used in our preamps has the same capability of their current multi-core ARM device at the same 48KHz sampling rate !! The truth is they had ample opportunity to upgrade their hardware to better SHARC parts, but instead chose to sell the same bit of old rope as long as they could get away with it. Of course, using better SHARC DSP's now they would then have had to explain the mediocrity of what they have been selling to the punters for decades. Can't have that can we. Instead it was much easier from a marketing point of view to use a completely disconnected CPU/DSP such as an ARM device and then beat-up on the poor old first gen SHARC parts in classic strawman style. This makes perfect sense from a marketing point of view but fails dismally from a technical standpoint

What's even more bizarre is that the main proponent (or should I say the shill from stereonet) of DEQX's latest offerings, who is obsessed with tap count has never once mentioned this performance shortfall instead preferring to exaggerate it as well whilst bagging the competition no matter who or what it is ! Now he says the tap count on their new offerings has jumped eightfold from when he started the thread on ASR but then he also said the tap capability of their previous offering was 4096 taps per channel which is still 6x its maximum theoretical performance. Who knows but the maths certainly doesn't lie

This reason alone is why I do not consider the MiniDSP to be a "serious" solution, it simply does not have the computing power to deliver adequate correction. The older version of DEQX used the same SHARC processor as MiniDSP, but this new DEQX uses an ARM processor which is 64 bit instead of 32, and allows for 4096 taps per channel, or 32,768 taps in total. At 48kHz, this is a resolution of 11Hz, which is a substantial improvement.

Regardless, all versions of the DEQX use Linear Phase FIR filters, rather than mixed phase as per MiniDSP. To get equal performance you need a lot of taps. Older versions did not have enough taps. The new Premate 8 uses an ARM chip, which has 32768 taps per channel, for 8 channels. IMO this is still not enough, but I would consider it adequate. I would prefer 65536 taps per channel or more. But 32768 taps per channel is a substantial upgrade over older versions of DEQX.

So it's a bit of a cheap shot to compare the minidsp offering to the previous DEQX offering just because they use the same vendors DSP but fails to mention that mindsp is using a 4th gen SHARC DSP whereas the previous DEQX models use first gen SHARC DSP's ! In fact, 3 months after starting the thread on espousing the virtues of the new DEQX unit he started a thread on the "Limits of minidsp" and highlighted the fact that 1024 taps per channel was not enough! How about 229 taps per channel for the previous DEQX models ?

What's even more bizarre is the claim that the alleged 32k taps per channel for the new DEQX is not enough and the post's author would prefer 65k taps !! So how does he reconcile only 229 taps per channel for the previous DEQX offering ?? That's a huge disparity to account for. In fact, it's 143 times the last offering product from DEQX which begs the question as to how did the previous offering from DEQX ever work as claimed if they have had to completely redesign it with a substantial performance increase ? Hmmmm !

But wait there is more from Analog-Devices !!

https://www.analog.com/en/products/adsp-21837.html

Check it out. With 24 GFLOPs and 8 GMACS floating point performance That's equivalent to 41,666 taps at 192KHz or 83,333 taps at 96KHz or 166,666 taps at 48KHz. What's not to like ? That's why you use a dedicated DSP and not a phone chip when it comes to doing hi-end audio

Hey Curly have you heard the latest news ? Someone recently asked a question on DEQX's facebook page for the tap count of their latest DEQX processor for which you could hear the crickets sounding until that post was deleted as have many others on that thread. In fact out of 15 comments only 6 are displayed. Hmmm According to sources from ASR it is 32k taps @48kHz or 4k taps per channel for the 8-channel version. And bear in mind this figure of 32k taps is at 48K sampling rate. Hardly call that SOTA these days. More like entry level. At 192k (which is what our own UP2 and UPP defaults to), the tap count is reduced to only one quarter of the 48K rate or 8k in total or 1k taps per channel !!

Now a single core 5th gen SHARC ADSP-21569 DSP is capable of a best-case scenario of 4G-MACs (multiply accumulates or taps per second) from both the core and on-chip accelerator hardware. Divide this by 48KHz and you get 83333 taps per sample  @48KHz !! Sorry DEQX your 2GHz 6-core phone chip is already outclassed by a single core 5th gen SHARC DSP that only clocks at 1GHz !! Why is it so ? The ARM core relies on cache architecture to achieve its performance. Still, for long length FIR filters this is not necessarily optimum because unless the FIR fits within the data cache the cache can easily be flushed by other code and data at any time. Then you are up a creek without a paddle. Whereas the SHARC DSP has dedicated single cycle on-chip pipeline RAM which can be used for dedicated FIR filters without other code interfering with and invalidating it !! You could of course segment the FIR to run on multiple cores but for a 6-core ARM device allegedly used on the latest DEQX (for which no part numbers have been offered) you would expect a much higher aggregate tap count than a single-core SHARC DSP that runs at only half the clock rate but it aint so

Of course, you could use FFTs to do the FIRs, and this is where the SHARC has an advantage because it has on-chip hardware for FFTs. Unfortunately, the ARM doesn't, so it's probably ham-strung in the same way as it is for FIRs.

The other thing is these phone chips were never really expected to process any audio above 48KHz and why should they ? It's a phone stupid not a dedicated music server or multi-way crossover ! It simply doesn't need to process anything above 48KHz such as 96K or 192K etc. In addition, like a phone, they are running Linux or some operating system on the same processor used for DSP so you now have a layer of bloatware competing with the same resources needed for high-performance DSP. (insert face palm moji) !!

The moral of the story is always use the right tool for the job which is why AVR manufacturers use dedicated DSP's such as the SHARC instead of phone chips and that is why we use a SHARC as well.