Print

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

[mikolajek]

I've been using a simple output setup for years, having the signal just run to my DAC + speakers via WASPI. This way I didn't have to close JRiver to e.g. answer a Teams call (or operate any other app that uses sound).

I played a bit with the output options and realized I can have my sound output set as DSD (8x) and it sounds in my ears a lot better than the previous setting. The issue is that while enabled it literally steals the DAC/speakers and make it invisible for other apps. Is there any way to keep DSD output, but disable ASIO exclusive access to the DAC/speakers? I've seen some custom ASIO drivers allowing for this, but I don't want to mess around my config too much.

[Awesome Donkey]

Not possible, ASIO for DSD is always exclusive in the DAC driver itself (depending on the DAC's driver it likely has a ASIO DSD mode you can possibly see it switch to in its control panel when using it) with no way to disable that unfortunately. The alternative to ASIO is to use WASAPI exclusive if the DAC supports DoP but that's also an exclusive output. I suppose the other alternative is to convert DSD to PCM but that's likely not desirable here. As far as I know you can't output DSD without using ASIO (in its exclusive DSD mode) or WASAPI exclusive.

I assume you mean you're using the DSP Studio > Output Format > Output Encoding set the 8xDSD option? If so, do know that converts everything including PCM to DSD and is a lossy conversion and resource intensive for the system to do on-the-fly. Unfortunately, the only way to avoid the issue with needing to use exclusive mode would be to set the Output Encoding feature set to None and instead use DSD bitstreaming for playing back DSD content only and leave PCM as-is with WASAPI or ASIO. It won't solve the issue when playing back DSD content as DSD requires exclusive mode but it would allow PCM to play as it did before.

[mikolajek]

depending on the DAC's driver it likely has a ASIO DSD mode you can possibly see it switch to in its control panel when using it

Not in my case unfortunately, I use XMOS USB DAC driver and it has literally no options to configure (only streaming ON/OFF and buffer settings).

The alternative to ASIO is to use WASAPI exclusive if the DAC supports DoP but that's also an exclusive output.

I have this ability (up to 4XDSD on DoP, but I) it sounds a bit worse to me (subjectively) and ii) since it's still exclusive, then...

I suppose the other alternative is to convert DSD to PCM but that's likely not desirable here.

Indeed, it's not I'd like to have, especially not all my files are high-res.

I assume you mean you're using the DSP Studio > Output Format > Output Encoding set the 8xDSD option? If so, do know that converts everything including PCM to DSD and is a lossy conversion and resource intensive for the system to do on-the-fly. Unfortunately, the only way to avoid the issue with needing to use exclusive mode would be to set the Output Encoding feature set to None and instead use DSD bitstreaming for playing back DSD content only and leave PCM as-is with WASAPI or ASIO. It won't solve the issue when playing back DSD content as DSD requires exclusive mode but it would allow PCM to play as it did before.

Yes. that's muy current config. And, wow, thanks a million for such a comprehensive explanation!

[mikolajek]

One more thing on this config - there's no point in opening another thread.

What I experience is that when I select other music for playing (e.g. another album), I hear first 1-2 secs of the material that I just stopped playing.

Seems like the buffer needed to empty first. Is that the case? Should I somehow decrease the driver buffer size or do something else? In fact I tried decreasing the driver buffer (set as max of 32,768 samples) but once confirmed, it would auto-return to this number...

[jctcom]

I'm not sure if this will help you or not.

It sounds like you are using an external sound card?  If that's the case then there is most likely also an internal sound card.

I do something similar with this set up.  I send all my JRiver music to either direct to the DLNA on my receiver or to ASIO and then to a specific input on my receiver. 

I have the standard audio card on my PC going to another input on my receiver and send all standard windows sounds to that.  If I want to watch Youtube or receive a Teams / Skype etc... on my PC I simply change the input on my receiver to the standard sound card output.

Then my JRiver config is left untouched and I can switch back and forth at will.

You should probably be able to do that even with a single sound card if it has multiple outputs (SPDIF / Analog out etc...)

Hope that helps.

[mikolajek]

Hello and thank you for your response!

My config is a bit different. I do have an internal sound card in my laptop, but I disabled it in BIOS before I installed Windows. So currently the only sound output for my device is USB-connected DAC (SMSL DA-9).

This is why I believe when changing track, the buffer may not be empty and it first plays whatever's left from the prior track. Since I cannot change the buffer size in the DAC Drives (XMOS), I hope JRiver has some option to control it.

[mikolajek]

So I asked this question on the XMOS forums, that gathers people developing and using the DAC driver.

They told me this was the JRiver's fault actually and its "use a large hardware buffers" option enabled by default. I followed their guidance and installed Foobar2000 and tested DSD files with it. There were no remnants of the previous track whatsoever, even with the buffer set to the highest possible value (30,000 ms).

Unfortunately disabling this option and setting the buffer even to the minimum hardware size does not resolve my issue. I admit the "echo" of the previous track is a little shorter, but still exists Would that be a JRiver's bug then?

UPDATE:
I played a lot of with both JRiver and driver settings but found no feasible configuration to eliminate the "track remnants". The best config that secures this is:
- in JRiver - the "use large hardware buffers" option is off and the "minimum hardware buffer" is selected (any change - even setting the buffer to 5 ms - disrupts the sound),
- in XMOS driver - the "safe mode" is disabled and the buffer size is set at 16,384 samples (any lower causes lags).
Any other config causes the above-described issue. But even this "best" config suffers from sound lags when the computer processor is in heavier use.

[Awesome Donkey]

You can change the buffer settings in MC's Options > Audio > Audio Device > Device settings...

Personally I have all the buffer stuff set to the default and it all works fine with DSD here and no previous track remnants issue.

[JimH]

Please post a link to the XMOS forum topic.

[mikolajek]

As said earlier, I believe I tried all available settings.

It seems there's simply a conflict between the Thesyscon driver (XMOS-based) and JRiver when playing DSD files / output. Thesyscon already ditched me when reaching them... No surprise here. I hope JRiver team can be more responsive / understandable.

[mikolajek]

Please post a link to the XMOS forum topic.

Please refer to this link.

[Matt]

When you say you switch tracks and the previous remains, have you enabled cross-fading? That intentionally will play part of the previous track.

If you pick gapless, it should start fresh.

If you still have the issue in gapless, could you describe how you switch tracks? Is it stop then play, or just manually switch while it's playing?

Thanks.

[Awesome Donkey]

Yeah, posting a screenshot of your MC Options > Audio section (all the settings there if possible) would be helpful too. Here's what mine looks like and DSD plays fine without any track remnants on change.



I also have a Topping D50s DAC (made by the same manufacturer as SMSL) and it uses the same XMOS driver and it works fine too with the same settings.

Also what type of DSD media are you playing? SACD ISOs? DFF/DSF files? Might be a clue there, in my library I use DSF files extracted from a SACD ISO using sacd_extract.