Print

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

[glynor]

That's pretty good.

The problem is that they can't raise priority level without elevating (renice, and the pthread API version, requires root to increase priority).

There's an API they're supposed to use to accomplish this properly without root for CoreAudio (by setting a thread profile that tells the scheduler to set the priority appropriately).  The problem there is that they're already doing that.  It might need some tweaking, but... Everything I read indicates that they're doing it right already.

Question for anyone seeing issues?

How much RAM do you have?  I strongly suspect this might be a memory pressure issue now. Even if you set the thread profile, the scheduler won't favor any user application above system services.  If my theory is right, then activating the memory playback should make it worse, not better. Later on, I might be able to replicate forcibly reducing my available RAM to 4GB or something to test.

OSX really doesn't like to run on 4GB of RAM anymore...

[blgentry]

Based on my testing, I'm *guessing* RAM isn't an issue, as long as it has some breathing room.  Here's a portion of the log I was keeping a few weeks ago showing the dropouts and my observations of RAM use right after the dropouts:

------start log -----------
5/27  18:34  Pressed Play to resume
5/27  18:36  Dropout.  Read and Write at the same time.  com.apple.Webki Writing and reading.  Then Webkit writing and Media Center reading.  Had just refreshed a page in Safari.  About 150MB RAM free, with over 1GB dedicated to disk cache.
5/27  18:40  Quit Safari, reopened Firefox
5/27  19:24  Pressed Pause

5/27  21:23  Pressed Play to resume
5/27  21:55  Dropout.  700 MB RAM free.  2GB cache.  Small blip on disk meter.
5/27  22:22  Pressed Pause

5/27  22:24  Pressed Play to resume
5/27  22:42  Dropout. 450MB RAM free.  Read and write blip (medium sized) on disk graph.
5/27  23:04  Dropout.  450MMB Ram free.  Small write blip on disk graph.
5/28  00:08  Pressed Pause

5/28  18:20  Installed Media Center 20.0.112
-----end log ---------

As you can see, this has happened with what you would think is ample RAM, especially considering the large disk cache that existed at the time.  As I'm sure you are aware, the disk cache is dynamically allocated and can be shrunk at any time to give RAM to applications that need it.

If you've got some testing in mind, by all means, don't let me stop you.  Just giving you my data also.

Thanks for your continued interest and help!

Brian.

[wakajazz]

Add me to the group..... Experiencing random <1 sec audio dropouts. May get 3 or 4 within a 1 hour timeframe, may get none during a longer period. Totally random. A dropout is not reproducible by rewinding the track after a dropout and replaying.

Hardware is a Mac mini (Late 2014), 2.6 GHz Core i5, 8GB, olde fashioned spinning HDD (OS only), WD USB external drive (library) OS X 10.10.3 fully updated. MC 20.0.116. USB DAC Teac UD-501. Using both eos & JRemote (Android & iOS versions). MC20 is configured for 'Audio Only' mode, other than that audio settings are default value with Integer mode enabled for the DAC.

Mac mini is running headless and is only used for MC and has been from time of purchase. Time Machine, Spotlight, Notifications, Update and PM have all been disabled. No other applications running concurrently. The only application that has been installed recently was Audirvana Plus 2.0 (since removed). I used Audirvana for several days without a single dropout. This has been the extent of any attempt to troubleshoot the MC20 dropouts.

I don't have the time to roll up my sleeves and delve deeply into this, sorry. But I wanted to add my case to the statistics. It's a annoyance to me, and I certainly drop a few expletives each time a dropout occurs but have to keep priorities in perspective. If a log file or other easily produced dataset would be helpful let me know.

WJ

[glynor]

Hardware is a Mac mini (Late 2014), 2.6 GHz Core i5, 8GB

Well, there goes that theory.

Very, very strange.  I played music literally for 6 hours last night (and another two or three this morning) on my Macbook Pro and had no blips or dropouts at all.

Both my Macs have 16GB of RAM, but I regularly run my laptop with a Windows VM running that sucks down some of that.  I don't think RAM is the issue if it happens with 8GB.

Does everyone who has the issue have the OS on a spinning disk?  I don't have any machines left with an OS on a spinner anymore (I can't imagine tolerating it).

Also, anyone willing (Brian, maybe) to test out MC19 to see if it behaves differently?  You can run it in trial mode if you don't have a license.

[lobo85]

Yeah the ram probably isn't as I occasionally (but not consistently) have dropouts on my 2011 2.5 Ghz i5 iMac that has 28 Gigs of RAM, renicing did seem to work for the dropouts but I don't think it is something I want to have to do a lot. I also have the OS on a spinning disc at 7200 rpm which might be faster than the Mini or Macbook that have the same isuue ocurring. I only happen to have this occur once or twice a day though.

[tortuga_Bob]

So are these problems only occurring with MC for Mac? Is the Windows version not having the same issues? I moved over to MC as I started having significant problems with the iTunes-integrated music player that I had been using for over two years. Problems started several months ago, apparently out of the blue. I have done no updates to my Mac mini except for security updates and Safari updates (also security related), yet something had changed that made the music player, in my opinion, unusable. Disappointing that after only two weeks I have already encountered problems with MC as well. Maybe the Mac is not a good platform for a music player? What is so frustrating to me is that this computer is dedicated to music playing, has 16 GB of RAM, no other applications are running at the same time and CPU usage is only a few percent, so why should there be problems?

[blgentry]

Hmmm.  I've now gotten several dropouts while listening with nice set to -5.  I seem to be experiencing multiple failure modes.  I've talked about freezes and hangs before.  I won't detail those, as I think they probably belong in another thread.

But I've also had MC get to a state where it drops audio every 1 to 5 minutes.  Almost like it's extra, extra busy internally and can no longer handle playing audio.  So the dropouts get WAY more frequent.  In every case of that happening, simply quitting MC and then launching it again right away makes the problem go away.  This hasn't happened very many times.  Maybe 4 or 5 total in the few months I've been using MC.  I don't know if my dropouts at Nice Level -5 were the normal failure mode or related to this other "extreme dropout" condition I've described.

I don't enjoy giving all of these negative reports guys.  I would have abandoned many, many other players way before this point.  I like JRiver SO MUCH I'm willing to continue down this path because I want it to work properly.  I was just bragging on MC in a thread at head-fi a few minutes ago in fact.  Here's hoping a good solution is right around the corner. 

Edit:  I've just gotten two dropouts in 3 minutes at nice level -10.  I was playing a 24/96 file at the time (from local disk).  Firefox has been open for more than 24 hours.  Currently essentially zero free RAM, but over 700 MB of file cache.  I don't know what to think at this point.

Brian.

[blgentry]

I can now re-create the dropout behavior at will.  I don't know that I have reproduced the *only* way, but I definitely have *one* way of doing it.  As Glynor theorized before, memory pressure is a trigger for this.

I wrote a program that consumes a fixed amount of memory and then does random writes to different memory locations.  My procedure for testing is:

1.  Quit web browser, media player, and memory chewing test program.
2.  Launch web browser and media player.  Wait for a few minutes for everything to quiesce (settle).
3.  Look at Activity Monitor to determine how much RAM is free and how much Disk Cache is being used.  The goal is to use all available RAM and leave around 500MB or so available for disk cache.  So if I've got 3.5 GB of RAM used and 800 MB of disk cache, and a total of 8 GB of RAM, that means I want to chew up about:  7.5 - (3.5 - 0.8 )  = 4.8 GB . 
4.  Set program to chew up the target amount of RAM and launch it.
5.  Play music from media player.
6.  Open web pages in a normal way.  I'm using larger web pages for testing since they tend to allocate more memory.  Sites like cnn.com and yahoo.com.
7.  Listen for drops while web browsing.

With this method I get dropouts every 1 to 2 minutes, or sometimes even faster.  This has been tested with MC 20.0.116 and 20.0.122.  I've gotten similar dropout behavior on both, though .122 seems to take longer on average between drops.  I got 5 drops in 8 minutes with .122 in my last test.

I've also tested this with VLC and got no drops at all in about 11 minutes of testing/listening.

If anyone wants my memory chewing program, I'll post it.

EDIT:  Math on RAM above was wrong so I changed it.  The real key is to look at Activity Monitor during the test and see that all RAM is used up and that there is a small-ish disk cache (500MB or so).  That way the system is memory constrained, but not swapping and killing itself.  Of course your user experience is important too.  The system should not seem slow or unresponsive during this test.  If it is, the memory chewer is taking up too much RAM and should be adjusted down.

Thanks,

Brian.

[glynor]

Brian: Have you tried disabling App Nap for MC?

It dawns on me, only just now, that MC is almost certainly not really optimized for App Nap, and it might be coming into play here (assuming you're running Mavericks or later).  It happens to some people even on iTunes and Quicktime without disabling App Nap. I know EyeTV has had issues too, and a big pile of other applications.  It should not be impacted, since it is audible (which is one of the excluded "classes" of processes that are exempted from App Nap) but perhaps because of the oddball cross-platform nature of MC it doesn't get seen correctly by the OS feature.

It may also be worth testing disabling Timer Coalescing (separately from the above), to see if that is the thing causing issues:
http://www.timoliver.com.au/2014/01/25/disabling-timer-coalescing-in-os-x-mavericks/

If either of these things have an impact on your issue, then I think there are things JRiver can do to play nicer with these features of the OS, with a little legwork.

[glynor]

I can now re-create the dropout behavior at will.  I don't know that I have reproduced the *only* way, but I definitely have *one* way of doing it.  As Glynor theorized before, memory pressure is a trigger for this.

Yeah... I'm not sure how useful that is. I'm not surprised at all that MC will behave badly if the system is very memory starved.

Though, it is an interesting additional data point. I do strongly suspect that machines with lower amounts of RAM, and a slow system disk, are the ones most impacted here.

[JohnT]

I can now re-create the dropout behavior at will.  I don't know that I have reproduced the *only* way, but I definitely have *one* way of doing it.  As Glynor theorized before, memory pressure is a trigger for this.

I wrote a program that consumes a fixed amount of memory and then does random writes to different memory locations.  My procedure for testing is:

1.  Quit web browser, media player, and memory chewing test program.
2.  Launch web browser and media player.  Wait for a few minutes for everything to quiesce (settle).
3.  Look at Activity Monitor to determine how much RAM is free and how much Disk Cache is being used.  The goal is to use all available RAM and leave around 500MB or so available for disk cache.  So if I've got 3.5 GB of RAM used and 800 MB of disk cache, and a total of 8 GB of RAM, that means I want to chew up about:  7.5 - (3.5 - 0.8 )  = 4.8 GB . 
4.  Set program to chew up the target amount of RAM and launch it.
5.  Play music from media player.
6.  Open web pages in a normal way.  I'm using larger web pages for testing since they tend to allocate more memory.  Sites like cnn.com and yahoo.com.
7.  Listen for drops while web browsing.

With this method I get dropouts every 1 to 2 minutes, or sometimes even faster.  This has been tested with MC 20.0.116 and 20.0.122.  I've gotten similar dropout behavior on both, though .122 seems to take longer on average between drops.  I got 5 drops in 8 minutes with .122 in my last test.

I've also tested this with VLC and got no drops at all in about 11 minutes of testing/listening.

If anyone wants my memory chewing program, I'll post it.

EDIT:  Math on RAM above was wrong so I changed it.  The real key is to look at Activity Monitor during the test and see that all RAM is used up and that there is a small-ish disk cache (500MB or so).  That way the system is memory constrained, but not swapping and killing itself.  Of course your user experience is important too.  The system should not seem slow or unresponsive during this test.  If it is, the memory chewer is taking up too much RAM and should be adjusted down.

Thanks,

Brian.

Thanks much for your patience and all the testing/reporting you've done, we'll get it figured out yet.  Could you try a test build here:
http://files.jriver.com/other/MediaCenter200123.dmg
The only difference in this one is that it implements the Mach thread relative "importance" policy for the non time critical threads.  It did improve the performance on our "low end" system here, which is the only one we had been able to reproduce the problem on.  It's an old Core Solo Mac Mini running 10.6.8, 1GB ram and an SSD drive.  With this test build, playing 1.4 mb/sec files we couldn't get it to hiccup at all while maximizing cpu load.  Playing an 8 mb/sec file it would hiccup once or twice per minute at full cpu load.

Regarding the memory chewing program, I'm using the memory_pressure command line tool provided on OSX.  On my Macbook Pro (8 GB ram, i5, SSD) I can reproduce audio glitches in Media Center (playing ~5mb/sec flac files) when pushing memory above 85%.  In this test, the playback display briefly shows "Buffering..." during the dropouts.  This sounds like the best repro of what you're experiencing.  Looks like another thread may need adjustment.  Back to XCode... 

[blgentry]

Thank you and anyone else at JRiver who are continuing to work on this problem John. 

I've downloaded and tested .123 and run it with the memory chewer.  Unfortunately it dropped audio also; perhaps a bit more resistant, but nothing dramatic.  As I'm doing with each new build, I'm leaving behind the older ones and just testing with the most recent.  So I'll continue to use this new build normally and see what I observe.

For the record, more than 99% of my library is 16/44.1 files, so I'm testing with 1.4 MB/sec or less files.  In my experience, CPU doesn't seem to be much of a driver of the problem.  The memory chewer uses about 15% CPU, but it's big thing is memory obviously.  It induces audio problems every 30 seconds to 4 minutes.  Conversely, I can drive up the CPU to 75% with the silly command line:

yes > /dev/null &

Each one of those sucks up approximately one core thread.  So eight of those should take nearly 100% (on my 8 core system).  Six should be 75%.  Pushing the CPU to 75% doesn't seem to have any effect in my (limited) testing.

Regarding Apple's memory pressure tool, versus my testing:  I didn't know that tool existed!  Thanks, I'll have to look into it.  I'm unclear on what their metrics are in memory_pressure.  Like, what does "85% memory pressure" mean?  I can tell you what I see in Activity Monitor when I run my program "correctly":

Memory Used:  7.95 to 8.0 GB  (this system has 8 GB of physical RAM)
File Cache:  350 - 450 MB
Pressure status line at the bottom:  Stays green.  Not sure if it rises higher than my normal "loaded" system or not

I'm guessing I'm pushing memory harder with my tool than you guys are with the Apple tool.  I didn't do this just to try to break it or something.  I did it because this is what I observed on my system (7.99 GB RAM used, very small disk cache) during normal system operation when Firefox had been open for a long time and had used up a bunch of memory.  Under those "normal" conditions, I started getting audio drops more and more frequently.  I was also able to induce drops by launching applications and doing command line processes.  That's what lead me to write the memory chewer:  So I could simulate what Firefox is doing naturally the way I use it.

Again, thank you for your help and hard work.    Let me know if I can do any more testing that might help.

Brian.

[glynor]

Brian, the AppNap stuff I mentioned above might be relevant.  Easily tested.

[JohnT]

Are you seeing "Buffering..." in the playback window during the dropouts?

And what are your buffering settings in Audio options?  Please set hardware buffer to Maximum if it isn't already.

[blgentry]

Glynor,

Thanks for your work on this too.  I just tried disabling AppNap globally per the article (including rebooting the system).  After testing that, I disabled the timer coalescing also (no reboot).  Unfortunately, neither prevented dropouts when using my memory chewer.  Again though, I'm going to leave those settings set, using 20.0.123 and see if this happens in normal usage at all.

Brian.

[blgentry]

Are you seeing "Buffering..." in the playback window during the dropouts?

I've never seen this, but I'm almost never looking at MC when the dropouts occur.  I'm usually in another window, usually a web browser.  I guess I could run a test and stare at MC during the test...

And what are your buffering settings in Audio options?  Please set hardware buffer to Maximum if it isn't already.

I've experimented with several combinations of prebuffering, software buffering, and hardware buffering.   Currently those three are set to the defaults.  I just double checked and Maximum is now the default!  I think it was different before.  Also, I'm CERTAIN that maximum power of 2 used to be an option and it's now gone.  Must be a program change?

Brian.

[tortuga_Bob]

Why is there no "Prevent App Nap" check box in the Get Info window?

[blgentry]

Are you seeing "Buffering..." in the playback window during the dropouts?

Ok, I've now done the "stare at it until it drops" test.    I kept MC in the foreground during the whole test.  Using my memory chewer of course.  I got three drops in 5 minutes and saw no change in the display during that time.  No "buffering" indicated, no stopping of the time counting, or anything else.  Just some very short audio interruptions.

Brian.

[glynor]

I just tried disabling AppNap globally per the article (including rebooting the system).

Ok. You don't have to do it that way. Just disable it in the Get Info dialog on the Media Center 20.app file.  But... It turns out, it isn't there:

Why is there no "Prevent App Nap" check box in the Get Info window?

There is, normally. I suspect this is because MC does actually have it disabled in their plist.  I could look, but that's probably what it is.  So, perhaps that isn't relevant. If you want to be sure (but not disable it globally) you can also disable it this way:
http://apple.stackexchange.com/questions/121386/missing-prevent-app-nap-button-on-app

EDIT: I think they took this checkbox away in Yosemite. No, that's not right. Photoshop still has it on my Mini.

Note that this method is a temporary change (meaning the setting does not survive a reboot when done via Terminal).

You can see in activity monitor if App Nap has been engaged. It should NOT happen while MC is playing audio, but one of the other conditions is when no part of the UI is visible (covered up by a browser or whatever).  So, I thought it was worth testing.  Plus, either way, I provided John with some details that could be relevant for audio playback, though.

For Timer Coalescing, it might be disabled anyway if App Nap is disabled.  I'm not sure... But, I was interested in seeing how the two things behaved separately.  So, maybe test with the timer coalescing disabled, but with App Nap still enabled globally.  This is branded as part of App Nap, but is really something separate. I can see it being at play here.

Again, though, I wouldn't expect this to have an impact when the system is under an obscenely heavy memory load. If it has no memory, bad things will happen, and there's nothing to do to prevent that.  I'm interested in day-to-day impact.

[blgentry]

Again, though, I wouldn't expect this to have an impact when the system is under an obscenely heavy memory load. If it has no memory, bad things will happen, and there's nothing to do to prevent that.  I'm interested in day-to-day impact.

Let's get specific.  A really bad out of memory condition induces paging.  That is, it swaps to disk.  This slows memory access by something like a factor of 1000 and is really, really bad for performance.  MUCH less of an issue with an SSD, but still not great.  If this was happening, we would most likely see much more than sub-1 second dropouts.  I'd expect much longer ones, and probably repeated in short intervals (like a few seconds in between drops).

But that's not what's happening.  Even when I test with memory chewer, this does not happen.  I usually get at least 30 seconds between drops and usually more like 1 to 2 minutes.

Yes, I'm loading memory, on purpose, to near the edge, with a little tiny buffer (of disk cache).  I'm doing this to emulate what I saw with Firefox running after being open for something like 48 hours.  That's "normal use" to me.  That is my "day to day". I'm not trying to argue with you.  I'm just emphasizing what I stated above in case you missed or dismissed it.

Further, the memory chewer makes the drops happen rapidly, so testing is easy.  Otherwise, it's literally an hour or more in between random drops.  Waiting for this to happen is psychologically a bit exhausting.  Kind of like waiting to be hit in the back of the head when you're not looking.  Which is why it's nice to reproduce the problem rapidly.   

Finally, I've only tested it a few times, but VLC hasn't dropped audio with my memory chewer.  So it's not effecting the system strongly enough to influence another app that plays the same audio files.  In fact I just ran another test with VLC, with memory chew running, pulling free memory to zero, and disk cache down to under 400MB.  This is how I've been testing MC.  I played VLC for just over 30 minutes and got no dropouts.  I thought I heard a little click once, but that song had similar sounds in it, so I can't be sure.  With MC, I get real dropouts in 4 minutes or under with this test; usually every 1 to 2 minutes.

Again, I'm not trying to argue.  I'm presenting my thinking and my evidence.

Thanks,

Brian.

[blgentry]

I've been running 20.0.123 for a handful of days now.   I've experienced maybe 4 or 5 dropouts in that time period.  Some of them were with Firefox hogging lots of memory.  A few others were with several gigabytes of memory devoted to cache (so memory wasn't starved).  I can't remember if there was actually "free RAM" at that point and I didn't keep notes. 

I've taken to quitting MC each time this happens, and anecdotally it seems to be helping to keep the recurrences low.  But it's hard to say for sure.

Thanks,

Brian.

[dfortney]

I experience the exact same behavior since MC20 began which was also incidentally around when I switched to Yosemite.  I have a 2013 Macbook Pro 16G highest model they sold with all the upgrades, SSD etc.  Media library is on external USB3.0 disk on it's own internal port not shared by anyone.  I used to use Safari no plugins and it happened and now i use Chrome no plugins and it happens as well.  DAC is a McIntosh D100 also not sharing it's port.  Happens with even over 8G of free ram and cpu loads under 10%.  iTunes does not cause dropouts.

[glynor]

Media library is on external USB3.0 disk on it's own internal port not shared by anyone.

Interesting. One thing:

Make sure your Library isn't on the external disk. It is okay if your generic "library" is, of course (the files themselves).

Also, can you maybe do a disk random access test on the USB3 drive and post the results? I think we're seeing storage bottlenecks related to the newer (since 10.9) power saving features of OSX. I've been reading through developer documentation from Apple and helping John (et all) via a private thread.

I suspect, perhaps, that they don't have quite all the threads they need to marked as "high-priority" and so they're getting disk access stalls somewhere in the chain under certain conditions.

I use MC on my Macs to play video from an external disk all the time (and a slow one at that, often connected via USB2) without issue. But I generally play my music off of my internal 1TB SSD. I used to do it the other way (before I had the big SSD), but I think that may have been when I was on 10.8 still... And video is, of course, different because it is using the GPU, usually running fullscreen, and obviously not minimized and whatnot (where it is possible that OSX's power saving stuff could be interfering).

[JohnT]

I experience the exact same behavior since MC20 began which was also incidentally around when I switched to Yosemite.  I have a 2013 Macbook Pro 16G highest model they sold with all the upgrades, SSD etc.  Media library is on external USB3.0 disk on it's own internal port not shared by anyone.  I used to use Safari no plugins and it happened and now i use Chrome no plugins and it happens as well.  DAC is a McIntosh D100 also not sharing it's port.  Happens with even over 8G of free ram and cpu loads under 10%.  iTunes does not cause dropouts.

Does it also happen playing music from the local disk?

[JohnT]

Please try the latest build (20.0.124) and let us know if it's any better.  This has the feeder and CoreAudio output threads given equal time slices but with the priority (policy.importance) of the output thread higher than the feeder.  It plays really solidly on our Mac Mini even with memory at a minimum and the cpu getting pounded.

[blgentry]

I've been getting infrequent dropouts with version .123.  Seems like a LOT less than in earlier versions.  This is in day to day "normal" use.

I just downloaded and tested .124.  I ran my memory chewer to tax the system and JRiver.  Unfortunately it still produces dropouts every few minutes.  However, I've noticed that the dropouts on this version are mostly VERY quick.  The original dropouts were an obvious (but fast) bit of silence.  These new "fast dropouts" are more like a blip or a click in the music.  Still very audible, but definitely different.  I'm not sure if that helps at all, but I think it's important to report all behaviors in case they help troubleshooting.

Again, this is while running my memory chewer which taxes the system pretty hard.

I'll of course continue to use version .124 for my day to day use and see if I note any dropouts under more normal conditions.

Thanks you for your continuing efforts on this issue!  Really and honestly:  Thank you.

Brian.

[AndyU]

Please try the latest build (20.0.124) and let us know if it's any better.  This has the feeder and CoreAudio output threads given equal time slices but with the priority (policy.importance) of the output thread higher than the feeder.  It plays really solidly on our Mac Mini even with memory at a minimum and the cpu getting pounded.

Hi, just tried this. Still get plenty of clicks when firing off the dozen or so apps in my toolbar all at once - clicks seem to coincide with app waking up. Similarly plenty of clicks when quitting the same apps. Then things quieten down, modest browsing seems ok, but  firing off a folder full of 77 tabs in Safari brings the clicks back. iTunes and Audirvana don't click under same loads. This is just listening from the headphone socket.  But am sitting now just idly browsing and typing this and it is fine, and if I open another app just one at a time it seems ok too, so I would say that 124 is better than whatever version I had before. The activity monitor says memory used 2.77GB out of 4.00 physical. I have 9 days left in my trial, will move my Mac mini through to my stereo and try later tonight with my DAC. Any particular  buffering/memory replay settings etc. you would recommend?

Edited 10 minutes later to add ... Just had a couple more clicks, was changing the date on a couple of photos in the Photos app, and checking mail. Absolutely not hammering the machine in any way. So unless I am missing a setting or some other magic, I can't say version 124 has fixed this issue.

[blgentry]

I've been using 20.0.126 for several days now and .124 for about a week prior to that (give or take a few days).  I'm still getting essentially the same behavior I've seen for the last 3 or 4 releases.  Something like once and hour (of playback time) I get a dropout.

I had previously reported that the "new" dropouts were shorter.  That seems to have been isolated, as I've gotten numerous dropouts with .124 and .126 that were the same as I'm used to:  About a quarter of a second or so.  Every now and then a longer one.  I think I had something like 5 to 8 seconds yesterday and I was *sure* MC was going to lock up and/or crash... but it didn't.  It settled back down and played normally for a long time after.

Brian.

[adamt]

Just had a couple more clicks, was changing the date on a couple of photos in the Photos app, and checking mail. Absolutely not hammering the machine in any way. So unless I am missing a setting or some other magic, I can't say version 124 has fixed this issue.

I've been using 20.0.126 for several days now and .124 for about a week prior to that (give or take a few days).  I'm still getting essentially the same behavior I've seen for the last 3 or 4 releases.  Something like once and hour (of playback time) I get a dropout.

Thanks for reports.  This is a tricky one to track down.  Would you be willing to provide a log of one of the listening sessions that you're sure included a dropout?  The current build has some logging that will provide some information.  Thanks!

[blgentry]

^ Sure.  I'll turn on logging the next time I listen and stop when I get a dropout.  I'll attach here, or ask for an email address if it won't fit.  I should have something within 24 hours I'd expect.

Brian.

[couchjr]

Chiming in on this issue. I'm working on so many moving parts getting my server and MC and JRemote and my NAS up and configured that I haven't really worried about the intermittent dropouts until now, when I've actually had time to do a few extended listening sessions. I noticed dropouts and freezes in MC 19 and early versions of 20, but my setup was in constant flux so they might be red herrings; will focus on current setup (which will evolve again soon).

Server: Nov 2014 Mac mini 500GB SSD, 16GB RAM (headless; runs MC, Splashtop Streamer, Safari, WiFi, antivirus, period), Yosemite.
Media storage: Synology 1515+ NAS, direct-attached via Cat 7a ethernet (no hub, switch, or router) 5 x 5TB Seagate ent. class drives
External DAC: Oppo BDP-105D asynch USB DAC input, 0.7M Supra USB2.0 cable. No other USB devices connected.

I run this server headless; control the Mac with Splashtop and the Synology using Safari with DiskStationManager. Audio files are almost exclusively "single" DSFs. MC may stay on for several hours; Safari usually not, but sometimes. Never have multiple tabs open.

Relevant symptom is ~1 second dropouts, usually after some time (an hour or so) of play. May then get two or three within a few minutes, then often another hour or several before a repeat.

I'm not actively using the computer for anything but music and managing the NAS. I think I have most MC settings as recommended; I've played with integer and exclusive modes but can't attribute any effect on the occasional dropouts, likewise with memory play. Can test if desired.

I'll note one other symptom that may be entirely unrelated, but who knows: to bitstream DSD via asynch USB to the Oppo, I have to select it in the output device list in the System Prefs->Sound pane. I intermittently (but too often) lose all sound, very often just before the end of a playing track (noted in JRemote) with no action on my part, and also if I have to restart Splashtop or otherwise address the Mac. Turns out these are always cases where the Mac has released the Oppo device and switched to something called SoundFlower. This is more annoying and more frequent than the dropouts, but I experience both, and perhaps they're related.

Not to derail the thread, but does MC install and use this SoundFlower thing? If it's needed, is there some way to make sure the Mac stays defaulted to the Oppo once I set it? Can that setting be made persistent across reboots or set as a startup item in the user (admin) account? (Please move this to a new thread if appropriate).

I doubt I'm competent to assist in troubleshooting the dropout issue but wanted to report my setup and experience in case it's useful. MC is so powerful (and getting more so all the time) that it will be quite a while before I feel I can really drive this Ferrari with anything like skill or grace.

One final thought: in a month or so I expect to be acquiring an exaSound e22 DAC to replace the Oppo DAC. I know George has written custom Mac drivers; I don't know whether they supplement or substitute for any MC drivers. If the latter, do we know whether any MC users of those drivers are also experiencing the dropouts?

Thanks to everyone for all your hard work!

[blgentry]

Not to derail the thread, but does MC install and use this SoundFlower thing? If it's needed, is there some way to make sure the Mac stays defaulted to the Oppo once I set it?

SoundFlower is a third party application.  It's not part of MC at all.  I would recommend uninstalling it.  BUT realize that it is not a normal application, in that it uses a kernel extension.  It requires it's own uninstaller to be run.  The uninstaller is supposed to be in Applications/Soundflower .  I haven't used it, so I can't give you any real details.  Just what I've read.  I would want it gone if it was my system.

Brian.

[couchjr]

Many thanks, Brian. It's a little scary--I didn't know how it got installed in the first place. Turns out Splashtop installs it to enable sending sound to the remote device. I don't need that function, just the remote desktop access for the headless mini. I've filed a support ticket with Splashtop to ask whether uninstalling Soundflower will affect the UI/input aspects of Splashtop--if not, it's gone ASAP. I've suggested they make its installation a user-selectable option so those who don't need remote sound won't get hit by this problem (and I won't have to repeat the uninstall with every new Splashtop upgrade). Thanks again.

[blgentry]

I just had a very brief dropout and I was logging, so here's the log.  The dropout occurred less than 1 minute before I pressed the "report" button.  I seeked back in the track to make sure it wasn't related to the media itself.  It played fine the second time.

Log is attached.

Brian.

[couchjr]

Update on SoundFlower to restore focus to main topic: Splashtop says the program will operate correctly without SoundFlower (just no sending of audio to iOS device) so I can and will uninstall it tonight. Hope this info helps any others using Splashtop to run a headless Mac server on Yosemite.

Now I'll be able to pay attention to the dropouts (had one last night, longer than a second) without the confusing variable of the output device releasing.

I'm running the latest MC build. Where do I turn on logging? I'll be happy to try to send a log if the problem recurs.

[adamt]

I'm running the latest MC build. Where do I turn on logging? I'll be happy to try to send a log if the problem recurs.

Here is how to turn on logging: http://wiki.jriver.com/index.php/Logging

Thanks for the log blgentry.  For some reason it isn't logging the dropouts where I'd hoped. 

Couchjr, if your dropouts are lasting longer than a second, we might have a better chance of catching them in the log. 

[couchjr]

Thanks, Adam. Hope to turn this on tonight after I uninstall SoundFlower.

[couchjr]

Update: listened last night for a single session of about an hour (one album) then had to correct a few tags so subsequent sessions were short. No dropouts. I'd uninstalled SoundFlower and logging was on. Oddly, System prefs still showed output device switching away from the DAC, now to internal speakers, so I think Splashtop is still trying to steer. However, I didn't get any sound losses, so we'll see. I won't post again on this thread until unless I experience the dropouts again. I'll leave logging on for a while and reset between sessions.

[couchjr]

OK, it happened again. Two-thirds through the first movement of Jacqueline Du Pre's Elgar (aargh!). . . . I had forgotten to reset the attached log, but it was around 11:22 p.m. EDT tonight (7/16/15) so hopefully you can find it. The dropout lasted several seconds and then play resumed on its own. I had only been listening about half an hour via MC (I'd played a new physical SACD prior to that) and this was the second album I'd listened to tonight in MC (I'd skipped to specific tracks in the previous one). However, MC had been running for much longer than that tonight, since I have it set to open when the computer launches and I'd had to do some file copying and maintenance on the NAS earlier from that computer. That work is done via Safari (web interface to Synology's DiskStation Manager) but I had closed Safari before starting this listening session.

Let me know if there's anything other info I can try to provide. Thanks!

[AndyU]

Thanks for reports.  This is a tricky one to track down.  Would you be willing to provide a log of one of the listening sessions that you're sure included a dropout?  The current build has some logging that will provide some information.  Thanks!

Sure thing. Sorry about delay in replying, have been out of the country.  What build do you want me to try? And how do I get a log made?

[blgentry]

See how to turn on logging here:  http://wiki.jriver.com/index.php/Logging

I would guess they want you to use build 126 (at the top of the forum here), but that's me guessing.

Brian.

[AndyU]

Thanks for reports.  This is a tricky one to track down.  Would you be willing to provide a log of one of the listening sessions that you're sure included a dropout?  The current build has some logging that will provide some information.  Thanks!

OK. Downloaded .126 (for which I paid for a Master Upgrade as my mac trial had expired).

Ran it, and fired off all the apps in my task bar.  Safari, Apple Mail, Contacts, Calendar, Notes, Maps, messages, FaceTime, iPhotos, Pages, (skipped iTunes), iBooks, AppStore, Word, Excel, OneNote, Outlook, Google Maps.

Was quiet for a few seconds, then got at least 22 dropouts as the apps came to life. Happened to have task manager visible, didn't seem to be any memory pressure.

Quit all the apps. Turned on logging in MC and repeated firing off all the apps and then quitting them. Got 11 dropouts.

Log should be attached.

Any particular settings you want me to try, let me know.

Edited to add: Been listening normally for half an hour or so, just browsing and typing - i.e. normal light use. No drop outs. So this version is a lot  better than whatever I had when I originally posted, which dropped out while I was posting on here.

Edited 30 secs later to add: Ha! Spoke too soon!! Just out of idle curiosity I clicked on the link to the zip file in this post. As then icon bounced into the download folder I got a drop out. Tried it a second time and didn't get another one though.

[couchjr]

Update: changed several things at once (poor experimental procedure, I know). Checked settings, and adjusted based on recommendations in this thread. Device settings: exclusive access and integer mode now on (were off). Software buffering upped from 100 to 250 milliseconds. Hardware buffering upped to maximum (was on device default). Prebuffering upped from 5 to 10 seconds. I also tried opening MC and setting the output device from Apple Remote Desktop rather than from Splashtop, before switching to JRemote as usual to select tracks and control playback. I thought maybe Splashtop activity or processes might be contributing to the problem.

So far, after an hour and a half, playback has been rock-solid. Listened through one complete album (finished the Du Pre Elgar) and then have been playing a few tracks each from several others. After about an hour I closed out Apple Remote Desktop and opened Splashtop, thinking if I opened and closed Splashtop a few times, and dropouts started occurring, that might be diagnostic. After half an hour or more, and several openings and closings of Splashtop, still no dropouts. So I'm hopeful that the device settings may have solved it for me (along with your hard work in 126). Given the flaky behavior I was having with the output device selection in System Prefs, I suspect the new settings may have helped stabilize things. For good measure, I also just enabled memory play--not sure how much difference that will make, given buffering, but hey.

I have the impression that the new device settings may have slightly improved SQ; hard to tell, and subtle if so. Since my new Mac mini is stock at present (no power supply, fan controller, or OS tweaks other than turning off obvious stuff) it may be that things like integer mode and exclusive access help improve efficiency enough to make a difference. The PCie SSD ought to help.

Finally, I note that when I reopen System prefs while MC is playing away happily, the output device window in the Sound pane is showing "internal Speakers" rather than "OPPO USB AUDIO 2.0 DAC" which is the actual output device in use. This is true whether I access the headless Mini with Apple Remote Desktop or with Splashtop. (But it also still says "The selected device has no output controls" which applies to the Oppo USB DAC, but not the internal speakers!) Very odd that the indicator and the behavior don't match. I begin to think there's some weirdness in sensing the handshake between the OS and the Oppo--I'm hoping activating exclusive mode in MC has helped stabilize things. After two hours, so far so good.

I won't post in this thread again unless the dropouts recur. Thanks to all for amazing, tenacious troubleshooting and assistance.

 

[AndyU]

Update: In two or three hours of moderate computer use - browsing, typing, reading etc. I got 3 more drop-outs. These seemed to be provoked by doing something for the first time (I've just returned from holidays, so booted my machine from scratch) - a spotlight search, a search of trash can, opening the zip file that was attached to my previous post. When I repeated the same action I didn't get a dropout. Just to repeat that I am using a base level current Mac mini and listening from the headphone socket, so there can be no issues with DACs etc., and other players (iTunes, A***+)  appear to work fine under similar loads.

[blgentry]

Finally, I note that when I reopen System prefs while MC is playing away happily, the output device window in the Sound pane is showing "internal Speakers" rather than "OPPO USB AUDIO 2.0 DAC" which is the actual output device in use.

The Sound preferences pane shows you what device is producing your sound effects by default.  If you click the output tab, it should have a highlight on the device that it wants to use for sound output by default.  Of course that's just the default for things like your web browser, and other programs where you don't explicitly tell it which device to use.

It's slightly more clear to use the Audio Midi Setup program instead.  It's in Applications > Utilities.  Audio Midi will show you icons next to each device to indicate how they are being used.  It will also show you the current settings for sample rate and depth for each device individually.  Audio Midi is more of the "power tool" for audio in OSX; it shows a lot more info and allows you to change a lot more if you want.

In summary what you see is probably totally normal.  I'm happy to hear that your trouble with MC seems to be over. 

Brian.

[couchjr]

Thanks, Brian. Good to know. I would expect that when I select the Oppo as output device it would stay the default until I changed it, but I guess not. I'll see if Auio MIDI setup makes any difference. But as long as it plays, I'm happy!

[czapp]

Thought I should add my name to the list. I am running 126 on a late 2012 mini, 16 gigs RAM, Solid State drive, OS is Yosemite, run headless, usb into playback designs MPS-5. The mini is completely dedicated to playing music. I am getting dropouts that last >3 seconds. When they begin to occur, it seems as though it has shut down, then it comes back.
I was playing some music for a good friend, telling him how great jriver was. After the fourth dropout he looked at me and said no thanks, I'll stick with Amarra.
It seems this problem is getting worse with every update. I'm committed to staying with jriver because I feel it offers the best sq and love the interface, but this is getting ridiculous. From what I have been reading, many others are experiencing the same problems, some for quite a while, but I don't see any resolution from jriver. What's up??

[xtraktz]

It's seems like that I have a similar problem.
I have described it here:
http://yabb.jriver.com/interact/index.php?topic=98827.0

[lobo85]

For my iMac I tried searching google for a terminal command to disable App Nap system-wide in Yosemite, I executed it and since then I have had no audio dropouts with JRiver.
Please do note that I would only consider doing this if your Mac is a DESKTOP otherwise you will probably greatly reduce your battery life. For laptop users I would wait for MC too be updated with a option to disable App Nap for it specifically when you right click and select get info on the application icon.

[JohnT]

Could other people having the audio dropout problem try disabling the "App nap" feature and see if it takes care of the problem?  If this is the case, we'll implement it in our code.  It would just be nice to verify it is in fact the problem.

Here's how to disable (from a terminal window):

  defaults write com.jriver.MediaCenter20 NSAppSleepDisabled -bool YES

and how to re-enable:

  defaults write com.jriver.MediaCenter20 NSAppSleepDisabled -bool NO

Let us know your results.  Thanks.