Print

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

[pgruebele]

I am running 132 on Windows 10 with a NAIM dac-v1 which supports 384/24.  In the DSP format tab everything is converted to 384Khz 2 channel.  When I use WASAPI everything works normally.  When I use Direct Sound, I get the "something went wrong with playback error".  The audio control panel settings for the NAIM are 384/24 and I can play back using direct sound from other media players such as Groove Music.  The NAIM shows 384/24 when using Groove Music or JRiver WASAPI so everything is configured correctly.

This seems to be a JRiver bug which is preventing proper playback.

Please help.  I cannot use wasapi because then my system sounds don't work.

[ferday]

Direct sound will resample all audio to whatever is set in Windows mixer, which IIRC is a total maximum of 24/192 and is always a maximum of your onboard sound card (not your external DAC)

try setting the output in MC to 192 and see if the error still shows up....

You can use WASAPI in non-exclusive mode to try and get system sounds back as well.  You should read here first

http://wiki.jriver.com/index.php/Exclusive_access

And here

https://yabb.jriver.com/interact/index.php?topic=99373.0

[pgruebele]

I will try WASAPI non exclusive mode as a workaround.

But Direct Sound was set to 384 and all other media players can play direct sound at 384 except for JRiver, so this seems to be a jriver bug and a fix would be much appreciated.

[pgruebele]

When using WASAPI non-exclusive mode I need to resample to the DS sample rate.  Since 352Khz does not show up in the windows control panel (long time Windows bug), I have to select 384Khz.  When resampling to 384Khz, JRiver produces small audible ticks (1 to 3 every second) in addition to the music.  Once again no other music players produce these ticks at 384 Khz. I tried DS and things like foobar and xmplay with WASAPI @ 384Khz and they play perfectly.

So it seems there are 2 JRiver 20 bugs:

1. Outputting 384Khz over WASAPI (exclusive and non-exclusive) produces audible ticks
2. Outputting 384Khz over DS does not work at all.

Cheers

[Spike1000]

Do you have a lot of 384/24 source material?

Does upsampling anything < 384/24 sound significantly different than playing at its native rate/resolution?

Spike

[pgruebele]

I generally prefer the sound when everything is up-sampled by the PC.  I don't have many native 384Khz audio files

So: I don't really care about using DS since I can use non-exclusive WASAPI, but the clicks make 384Khz unusable. 

Being able to play back artifact-free audio is kind of a baseline of acceptable media player performance and all other media players I tried do this perfectly so it really seems like JRiver has some bugs (possibly buffer overruns?) related to higher sample rates.

[blgentry]

Have you tried increasing the buffering in the sound settings?  Tools > Options > Audio > Audio Device > device settings

Brian.

[pgruebele]

Yes. Changing buffering there or in WASAPI settings makes no difference.

[Spike1000]

If it's not buffer size is it antivirus related?

http://yabb.jriver.com/interact/index.php?topic=86096.0

Spike

[pgruebele]

I don't use anti virus software..  I also did a clean win 10 install and the problem remains the same.

All drivers are the latest and greatest.  And as I said several other media players I tried don't have this problem.  The tick itself sounds like a single audio sample is corrupted.  It is really nothing more than a click.

[pgruebele]

Great news!  I just updated windows to the just released Windows 10 build 10586.3 and this seems to have resolved all the problems.  Both DS and WASAPI now work perfectly at 384Khz.

This must have been a windows bug that somehow only impacted JRiver out of all the players I tried.

Happiness!

[pgruebele]

I spoke too soon.  DS is indeed functional now, but the clicks persists.  It seems that when source audio is 48Khz clicks are less frequent and with 44.1 source material it is very noticeable.

So it seems to be a problem with JRiver re-sampling or buffering?

[blgentry]

How powerful of a machine are you using for playback?  What is it's JMark score? Help > Benchmark > Run Benchmark .

If it's an older or slower machine, it might not have enough power to upsample reliably.

Brian.

[pgruebele]

It's a high end machine:

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 3.085 seconds
    Single-threaded floating point math... 2.053 seconds
    Multi-threaded integer math... 0.694 seconds
    Multi-threaded mixed math... 0.443 seconds
Score: 3028

Running 'Image' benchmark...
    Image creation / destruction... 0.366 seconds
    Flood filling... 0.401 seconds
    Direct copying... 0.264 seconds
    Small renders... 1.019 seconds
    Bilinear rendering... 0.704 seconds
    Bicubic rendering... 0.411 seconds
Score: 6949

Running 'Database' benchmark...
    Create database... 0.210 seconds
    Populate database... 0.975 seconds
    Save database... 0.246 seconds
    Reload database... 0.041 seconds
    Search database... 0.737 seconds
    Sort database... 0.911 seconds
    Group database... 0.560 seconds
Score: 5845

JRMark (version 20.0.132): 5274

[blgentry]

Definitely a powerful machine.  Rather high JMark score.  The problem has to be elsewhere then.

You said you don't run anti-virus software.  Are you using MS's built in "windows defender"?  If so, you should read about how to "tame" windows defender for use with MC:

http://wiki.jriver.com/index.php/Taming_Windows_Defender

Where is your JRiver library?  The database itself, not the media files.  If it's on fast internal disk, you should be ok.  ...and what about the media files?  Local?  USB?  Network ?

Brian.

[pgruebele]

Temporarily disabling Defender real time protection has no effect.

JRiver and user files are on a SSD (I assume they are all there since I installed JRiver to SSD).   Music is on an internal HD.  I think if there were a file access problem the glitches would be larger, not just single sample clicks.  It really sounds to me like there is a single sample buffer over/under run.

[pgruebele]

Not sure how DS worked that one time either.  Now it's back to not working.  JRiver says 176.4/16 would work but the audio device only supports 176.4/24 so this makes no sense.  Maybe JRiver is getting the output bit depth confused and that is what causes the DS problems?

[pgruebele]

I also tried Kernel streaming and the clicks persist. 

This really looks like a JRiver 20 bug.