Print

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

[chrtob]

After years of almost flawless operation with several versions of JRM me and some of my friends to whom I recommended JRM warmly since months experience the same unsolvable problem with several versions of JRM and several macs from 2008 to 2018. We assume the problem is caused by an exreme delay while buffering a file to be played. The delay causes a pause between pressing the play button in JRM and starting to reproduce audio of about 9 selconds! This is an extreme value we cannot live with. We are all DJing in a special field of dance music without the need for crossfade but cannot confront our audience with such a disadvantage. We would love to continue with JRM. But if this problem cannot be solved completely within a few weeks we all will have to switch to another software player. 

2 screenshots show the most important options defined in JRM. A video shows under what circumstances the problem appears - reliably reproducable in 9 of 10 cases. 2 screenshots show the delay calculated by JRMs with and without a plugin being equal. Reducing the recommended prebuffering of 6 seconds to 2 seconds leads to a recalculation of the delay arround 2 seconds by JRM. But the actual delay before starting to play a file remains around 9 seconds. Deactivating SoX for resampling does not help either. The problem occurs with a variety of different macs - for example: mac book 12" / early 2015 / 1,3GHz dualcore M / OS 10.15.7 8GB RAM / with SSD - mac mini server used as a single station / late 2012 2,3GHz dualcore i7 / OS 10.15.7 | 16GB RAM / with SSD.

We would appreciate help very much. The screenshots are enclosed here. The video (to big for this forum) can be downloaded here:

https://mega.nz/file/8DEimQhQ#RP8lw7GbYQ8PCmXgdWIpgkWhf6S94wM_SO43udMuAak

[blgentry]

I've never experienced much of a delay when starting playback with MC.  I usually use a USB connected DAC.  I have used 3 or 4 over the years and don't remember any delay of any significance.

I just tested on my work machine, which uses a USB dock with a sound card (DAC) built in.  There was essentially no delay.  Less than 1 second.

I see that you are playing to some mysterious "virtual audio device".  Their web site doesn't really work, so I can't get any real detail on it, but this appears to be software, not hardware.  Presumably this does something that you like and eventually ends up at some piece of audio hardware.  The very little info I have suggests that this driver talks to audio devices over a network.  Both of these things seem like potential problems.

What happens when you play directly to real hardware?

Brian.

[cassiel]

Unfortunately I discover the same behaviour as mentioned in the opening post in this thread. Sometimes (not predictable) I experience a delay of approximately 10 seconds while starting a new track. I have checked all the settings mentioned above and I tested to alter the settings - nothing really helped me.

I have added a screenshot from my mainly used Playback-machine (MacMini late 2012 I7 2,6 GHz 16 GB RAM SSD) but I observe the same phenomenon while using my laptops (2 MacBook Pro late 2012 I7 2,6 GHz 16 GB RAM SSD)

The Benchmark runs with the following results:

Code: [Select]

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

Running 'Math' benchmark...
    Single-threaded integer math... 4.101 seconds
    Single-threaded floating point math... 2.724 seconds
    Multi-threaded integer math... 1.159 seconds
    Multi-threaded mixed math... 0.832 seconds
Score: 2155

Running 'Image' benchmark...
    Image creation / destruction... 1.956 seconds
    Flood filling... 0.545 seconds
    Direct copying... 0.839 seconds
    Small renders... 1.173 seconds
    Bilinear rendering... 0.796 seconds
    Bicubic rendering... 1.799 seconds
Score: 3095

Running 'Database' benchmark...
    Create database... 0.235 seconds
    Populate database... 1.626 seconds
    Save database... 0.452 seconds
    Reload database... 0.140 seconds
    Search database... 1.510 seconds
    Sort database... 1.078 seconds
    Group database... 0.921 seconds
Score: 3606

JRMark (version 29.0.87 64 bit): 2952
What is special in my setup?
My setup is pretty normal, but I prefer to store my music-files and my database on an external (FireWire 800) drive (it is very easy to backup my files and my database). Maybe that's the reason for the unexpected freezing in performance? (I've just checked the energy saving function. Disk-Spin-Down is deactivated.)

I am using mainly two DACs:
Focusrite Saffire Pro 24 DSP (connected via FireWire) or
Chord Mojo (connected via USB)
The problems occur in both setups.

[blgentry]

A video shows under what circumstances the problem appears - reliably reproducable in 9 of 10 cases.

I watched the video twice and I think I see the delays.  It's hard to tell since there's no audio on the video at all.

I notice you are using the spectrum display.  That display chews CPU like crazy.  I've had it turned off for several years.  I doubt that has anything to do with this, but I'd still turn it off to test.

Brian.

[chrtob]

Hi Brian,

the problem appears with several macs of very different age and with several top quality audio interfaces, and none of them is of mysterious origin. I used to worked with: RME Fireface 400 – Prismsound Lyra 2. I now work with: Lynx Hilo – Merging Anubis ( https://www.merging.com/products/interfaces/merging+anubis ) – Chord Mojo.

The problem appeared, appears with all of them. My main audio interface exchanges data through an ethernet LAN reserved for that purpose only (Ravenna / AES67) an extremely powerful AoE solution that can handle dozends of highres channels without any delay. The Anubis is very real hardware (see picture) and using it with a professional DAW brings perfect results only. And if I connect the Lynx Hilo through USB the buffering problem in JRM remains the same. The problem is definitely caused by JRM internally.

I use the spectrum analyser in the display since many years and it never caused any problems or delay. A check in the activity tool of Apple shows that JRM only requests 18% of the cpu power and the network connection you suspect causing problems only requests 0,2% of the cpu power. I remain with my guess: The problem is definitely caused by JRM internally.

In the video you can se me starting the new file after 40 seconds with a click. But only after 12 more seconds the new file starts to play. And this delay with that use always remains in that range. Rarely the display shows the message: buffering. But mostly there ist no information about the problem. The delay just takes place.   

greeting – Christian

[blgentry]

The "mysterious" comment I made was because this virtual audio driver is unknown to me.  ..and that company's web site does not work to show product information on that product.   No insult was intended.  I was mostly trying to eliminate variables.

When did this problem first appear?  What change in one or more of your systems produced the change in behavior?  As I said, neither of my JRiver systems have any significant delay.  The most I've seen with random clicking and fresh startup is about 3 seconds. 

I notice that you, and the other person reporting, are using older machines.  This shouldn't necessarily be a problem, but you are reporting bad behavior on a 14 year old Mac, which almost certainly is running a rather old version of OSX.  If you are running MC30 on a Mac with an OS that is several major revisions old, that might be producing a behavior that most of us would not see.

My two test subjects are both M1 Macs and are running recent versions of Mac OS 11 and Mac OS 12.

The big thing here, in my opinion, is to locate a scenario (OS + hardware + audio device + JRiver version) that works.  Then find the thing that makes it not work.  Reading what you have written, I suspect that this might be a combination of MC30.<something> and an older version of Mac OS (version 10.X).  But I'm just speculating based on available data.

Finally I should mention that I am just a customer.  I do not have any relationship with JRiver.  I do not speak for them. I am not employed by them.  JRiver staff might have different advice or observations.

Best of luck.
Brian.

[cassiel]

At least in my case I found the solution today. I left the Logging-option (Help-Menu) from a former debugging active (for over a year or so). Today I did a reset and deactivated the option and guess what … my instance of JRiver is responsive as expected. I told the thread-opener chrtob about my solution but unfortunately this wasn't helpful in his situation (the Logging-option was not activated in his setup).