Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Energy]

Whenever I try to encode a PCM file through DSD Native Format in anything higher than DSD256 (4xDSD), such as DSD512 (8xDSD) for example, I would get stutters within the music.

Even when buffer has been set to 500 milliseconds and ASIO drivers set to Extra Safe, it still lags during playback.
I check hardware monitor and it seems the DSP work is only being processed by a single core and thread of the CPU.

Is there any way to use multiple cores or CUDA offload to the GPU?

 

[Awesome Donkey]

What kind of CPU do you have? Converting to DSD on-the-fly is probably one of the biggest CPU operations in MC.

[Hendrik]

I've been thinking about the multi thread capability of DSD encoding, but unless you have multiple channel it is a bit complicated.

[Energy]

I have a decently speedy quad-core i7. The process takes up 1 core completely along with it's thread while my other 3 cores just sit idle. Is there any way to fully take advantage of DSD encoding with all cores?

[JimH]

It's probably not worth the resources it would take. 

[Energy]

That's disappointing to hear.   

PCM being streamed through DSD Native sounds much better for certain DAC's rather than playing PCM natively.
I think it would be a good feature to have. Being able to operate at multiple cores for DSD encoding.

Is there no other way currently to make use of this? 

[kr4]

I have a decently speedy quad-core i7. The process takes up 1 core completely along with it's thread while my other 3 cores just sit idle. Is there any way to fully take advantage of DSD encoding with all cores?

I have found that Process Lasso helps (https://bitsum.com/). 

[Fitzcaraldo215]

That's disappointing to hear. 

PCM being streamed through DSD Native sounds much better for certain DAC's rather than playing PCM natively.
I think it would be a good feature to have. Being able to operate at multiple cores for DSD encoding.

Is there no other way currently to make use of this? 

So, I think your best bet would be to obtain master files in DSD64, 128, 256, etc. and play them natively.  Personally, I don't think upsampling, especially not hi rez files, offers any worthwhile improvement.  But, if you think it does, there is always HQPlayer.

I disagree.  I would find the feature useless if JRiver added it.

[Energy]

I have found that Process Lasso helps (https://bitsum.com/).

I appreciate the program. It unfortunately didn't solve the stuttering problem.

When music is played like below, the music plays smoothly.



Sadly, it stutters when navigating through windows or browser processes which makes me think the core being used for DSD encoding is still being used by window background processes. Even when using Process Lasso to separate them by setting the affinity to isolate the DSD encoding to an unused core, the problem still remains.

So, I think your best bet would be to obtain master files in DSD64, 128, 256, etc. and play them natively.  Personally, I don't think upsampling, especially not hi rez files, offers any worthwhile improvement.  But, if you think it does, there is always HQPlayer.

I disagree.  I would find the feature useless if JRiver added it.

I would agree with you that this might be useless for people without a DSD capable DAC and not a significant amount of people would play PCM upsampled to DSD Native, especially going as far as DSD512 CPU intensive processing.

HOWEVER, it makes a night and day difference in the DAC that I am using (Holo Audio Spring).
Sounds like I upgraded from a mid-fi DAC to the MSB Signature V. Yeah... that big of an improvement.

Most material out there is redbook PCM 16 bit / 44.1KHz. If playing these files through DSD Native makes that big of a leap (especially at the higher render DSD512), multi-core will help tremendously in the pursuit of higher quality audio.

It may not make sense for some people to have to convert a file to DSD rather than just playing it directly, but it seems some audio circuits sounds better converting digital to analog using DSD, even if it's upsampled from PCM. That's my conclusion.

[tyler69]

So, I think your best bet would be to obtain master files in DSD64, 128, 256, etc. and play them natively.  Personally, I don't think upsampling, especially not hi rez files, offers any worthwhile improvement.  But, if you think it does, there is always HQPlayer.

I disagree.  I would find the feature useless if JRiver added it.

I think what Energy means is that certain DAC's have a sweet spot in decoding DSD. So he is only implicitly gaining quality from upsampling. the benefit he gets is by decoding, as his DAC seems to decode DSD in a better sounding way than it decodes PCM.

Using several threads for DSD encoding is a good thing in my opinion. Even if people do not encode to 8xDSD but 2xDSD, it would reduce stress on the CPU and therefore lower the hardware requirements for people that upsample to DSD.

[Energy]

Thank you tyler69 for making it easier to understand. That is exactly what I meant.

I didn't believe that a DAC could sound better decoding DSD opposed to PCM. I encourage everyone to try to encode their PCM files to 2xDSD, 4xDSD, or 8xDSD if you have a DSD capable DAC and see for yourself.

Being able to run more cores/threads will place less strain on the computer causing fewer hiccups during music playback while still being able to do everyday task. Running on a single core causes programs like Google Chrome (or any program for that matter) to stutter the music whenever the user interacts with it (changing website, clicking links/buttons, scrolling, etc).

I tested three computers of varying performing CPU's.

A computer with a 2009 CPU (AMD Phenom II X4) stutters quite a bit while playing, almost listenable.
A computer with a 2013 CPU (Intel Core i7 4700MQ) plays smoothly but stutters when doing everyday task.
A computer with a 2015 CPU (Intel Core i7 6700K) plays smoothly regardless.

It would be nice not needing to rely on single core performance and ultimately having to buy a gaming computer just for smooth playback. If JRiver Media Center could offer multicore processing to distribute the workload onto other idling cores that would be great.

[JimH]

We're not going to try to solve this problem by rewriting the program, so you'll need to find a work-around or use a less demanding format.

[tyler69]

We're not going to try to solve this problem by rewriting the program, so you'll need to find a work-around or use a less demanding format.

imho the statement and its implication as well as jriver's attitude towards the topics 64-bit and client/server architecture is what i find ignorant.

[kr4]

Sadly, it stutters when navigating through windows or browser processes which makes me think the core being used for DSD encoding is still being used by window background processes. Even when using Process Lasso to separate them by setting the affinity to isolate the DSD encoding to an unused core, the problem still remains.

Have you:
1.  Monitored what is going on in all the cores/processes with PL?
2.  Configured program and CPU priorities and program restraints?
Those might help but, if even with balanced core use, you still have the problem, your system/CPU may just be inadequate to this task. 

[Hendrik]

imho the statement and its implication as well as jriver's attitude towards the topics 64-bit and client/server architecture is what i find ignorant.

We only have limited resources, we can't work on every single thing. Not everyone always agrees with how we allocate our resources, but realtime 8xDSD upsampling is not any high-priority topic by any means, not for the effort that would be required here. We always have to weigh the cost/benefit of most things we work on. If its a simple thing to do, we would just do it, but if it takes a serious investment it also has to give a tangible benefit to a large portion of the userbase.

Users often have to face the fact that just because one or two people asked for something, that doesn't mean its going to happen. Some things that sound simple are actually very complex tasks. On top of that your personal priorities may not match the priorities of the majority of the userbase, or the priorities and direction we have planned for MC. Ultimately, you'll just have to accept which tasks we work on and which we don't consider worth spending significant resources on (especially if there is only little gain).