I need to be clear; at no time did I attempt to play Binaural DSD files through Audirvana or its plug-in Architecture. They were all PCM!
1 Like
I’m quoting myself here because there’s a note beneath the RealTime switch, “except for DSD files” This led me to believe that if I were to play DSD (Binaural or otherwise), and I first tell Audirvana that my output device is not DSD capable, Audirvana will convert the DSD to PCM. What I’m not clear about is whether that internal conversion is applied before any plug-in processing is attempted. If before it would allow plug-in processing to be applied to these pre-converted files.
Perhaps @Antoine could clarify?
Look at where the SDM (sample-rate converter) algorithm is in the ‘Bufferized’ path… it is after the plug-in architecture…
That is where the user decides to apply up-sampling/format conversion; but does Audirvana apply the same path when you tell it, my audio device is not DSD capable? That’s what I’m questioning.
I don’t disagree. content is king, and each to their own listening preference.
1 Like
Are these also available as VST3 plug-ins? If so, what’s the price? Thank you.
There is only one sample-rate conversion algorithm and it needs buffering and the fact that the plug-in architecture is bypassed when a DSD file is detected for playback…The sequence makes perfect sense when you stop and think about processing/accumulator demands for all operations prior to filling the output buffers… DSD processing is memory intensive and ‘real-time’ playback latency is a genuine concern and also there is concern in regard to signal integrity and ultimate sound-quality.
DSD file → Playback Pre-load Buffer → Sample-rate Converter (DSD → PCM) → Output Packetizing → Output Buffer → Output Controller
Your explanation makes sense, thanks.
I’m confused then by the words next to the RealTime control in parentheses (Not for DSD files).
That implies to me that with RealTime control disabled, DSD files could be processed by the plug-in Architecture somehow.
There is this remaining problem for the uBACCH plug-in only, that turning off RealTime causes it to fail. So non-RealTime is unusable for that particular plug-in.
If plug-in processing can never be applied for DSD, Why isn’t that just made clear in the interface, such as…
“Plug-in processing cannot be applied to DSD files”
Interestingly the “other” player, which I may as well mention is J River, as it must be quite obvious, does it the other way around. The up-sampling conversion process is applied before any plug-ins. J River has no notion of RealTime or non RealTime. I can tell J River is using the plug-in after up-sampling because it exhibits the same behaviour as Audirvana when RealTime is switched off; but with up-sampling applied. Curious!
Yes, I have developed my convolution plugin that I deliver with the filters. You can find the pricing of the different options on this page
The rational for decimation of DSD → PCM is there for those users that have PCM-centric DAC’s that have DSD files they want to hear… The scenario that you wish could be true, is very esoteric in the least.
Some (read many pro tracking/mixing/mastering) plugins provide their own up-sampling as part of their function… There is no reason that they can not be used in the Audirvana signal processing pipeline…
Well, it’s not so common. I wouldn’t quite put it that way though. Some people have a lot of DSD files, mainly ripped from SACDs; but also downloaded. PCM only dacs are still the most common. So the only way they can listen to those DSDs is by decimation to PCM.
That’s also the only way any vst/au plug-ins can be applied to them, of which, of course, there are plenty to choose from.
J River can apply format and sample rate conversion before the plug-in architecture. So why can’t Audirvana?
That’s a good point, thanks.
1 Like
What you are wishing to do, is decimate DSD to PCM and then route the PCM result through the plug-in architecture… This is a very corner-case scenario… 
There is no advantage to up-sampling before the plug-in architecture… In fact it could cause problems depending on the sample-rate… I could not listen to all of my PCM files modulated to DSD128 (5.6MHz) with HRTF applied if the modulation (up-sampling) were applied before the plug-in architecture… Do you see the problem?
Yes, I do see that problem, if you wanted to listen to your PCM files modulated to DSD.
What I’m speaking about may be a corner case or esoteric, call it what you will; but it is the specific case where the user explicitly tells Audirvana the output device is not capable of DSD. In that case only, (which is the opposite from the case you just mentioned), I would like Audirvana to decimate to PCM before the plug-in architecture.
It’s a pity @Antoine hasn’t had any input into this thread for sometime, as I’d like to get the opinion of someone from Audirvana on this.
Anyway, for me it’s no big deal. I can always perform the decimation to PCM in J River and the plug-in will be applied to the result. That also proves it’s quite feasible programatically.
It’s not about feasibility… It’s about sensibility, pragmatism and sound-quality…
If you prefer offline conversion, of course, that’s your choice. As to whether the sound quality is better is really a subjective call.
The disadvantage is you have to store the additional files, which in the case of going to DSD will be quite large.
For modulation to DSD, I prefer HQPlayer real time. Again, though, that’s a personal subjective choice.
The more the system is taxed for memory and ‘real-time’ operations, the greater potential for buffer under-runs and over-runs that precipitate BLER (Bit Level Error Rate)… There are differences in the sound-quality of these audio-engines… Use whatever you find works for you… It’s a mistake to compromise sound-quality in an attempt to please all users… My vote is always towards sound-quality and Audirvana is at the top, from my perspective.
