Topic: Audio Dropouts / Mac Performance (Read 85910 times)

blgentry · « **Reply #200 on:** July 20, 2015, 11:26:02 am »

Quote from: JohnT on July 20, 2015, 10:25:50 am

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

I've had App Nap disabled globally (for all apps) since June 23rd. I just checked again to make sure:

Code: [Select]

localhost:src blgentry$ defaults read NSGlobalDomain NSAppSleepDisabled
1

I didn't see any difference after I disabled App Nap globally. I've been running that way ever since and I'm continuing to get dropouts.

Brian.

blgentry · « **Reply #201 on:** July 20, 2015, 11:31:11 am »

I wanted to report one more thing. A few days ago I went back through the last parts of this thread and saw this again:

Quote from: JohnT on June 23, 2015, 11:42:15 am

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

I checked and mine was set to Hardware Default. So I set it to Maximum (recommended). Almost immediately I started getting clicks in the audio. Not dropouts. Clicks. I verified and re-verified by listening to the same song in several spots 3 or 4 times per spot. I had sporadic clicks, but not in the same spots each time. I changed back to Hardware Default, stopped and restarted MC, and the clicks went away.

I don't think that's related to the dropouts at all, but I thought I should mention it in case my results are somehow not typical and/or point to some other issue. I'm guessing I simply found the correct setting for my system and DAC (Schiit Modi 2).

Thanks for the continuing effort guys.

Brian.

xtraktz · « **Reply #202 on:** July 20, 2015, 12:46:42 pm »

My problem described here http://yabb.jriver.com/interact/index.php?topic=98827.0

Yesterday I returned on 112 version. Currently I don't have any problem with sound.

I see one difference in buffer size menu between 112 and 126:

.126 Hardware Maximum - recomended (I tried to change it but nothing)
.112 Hardware Default - recomended

I did not try test it on following versions 113, 115, 116, 122

adamt · « **Reply #203 on:** July 20, 2015, 02:21:33 pm »

Has anyone experiencing this problem tried disabling Media Network? If not, please try disabling it and reporting back. Thanks.

blgentry · « **Reply #204 on:** July 20, 2015, 10:47:55 pm »

Quote from: adamt on July 20, 2015, 02:21:33 pm

Has anyone experiencing this problem tried disabling Media Network? If not, please try disabling it and reporting back. Thanks.

I've been trying this for the last several hours. After around 3 hours of play time, I thought I might have heard a couple of dropouts, but it was very difficult to tell because what I heard were not the normal "obvious" dropouts; they were very quick. So I decided to hit the system with my memory chewer. I set it up as normal to leave about 700 MB of memory free (including cache) and let it run. After 5 minutes or so... nothing. I started my timer at that point and started keeping track.

I let it run with the timer for 21 minutes and got 3 total dropouts in that time. This is MUCH improved because the memory chewer normally makes dropouts happen as quickly as about 30 seconds and as long as maybe 3 minutes. I should have seen 7 to 10 (or more) dropouts in 21 minutes.

I killed the memory chewer, which normally causes more dropouts as it deallocates memory. None happened.

Then I decided to do something I never do. But someone else on this thread uses it as a test: Firing off a half dozen or more applications from the dock. Well, that did it. I got a ton of dropouts in a short time. Darn.

I'm encouraged by this! I'll continue testing with Media Network turned off and see if any dropouts happen during more normal usage.

Thanks,

Brian.

AndyU · « **Reply #205 on:** July 21, 2015, 04:38:51 am »

Quote from: JohnT on July 20, 2015, 10:25:50 am

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.

OK. This is what I did and what happened:

Disabled mediaserver (re suggestion in earlier post)
Disabled app nap
Started MC
Fired off apps in toolbar as per previous posts.
Got 4 dropouts.

Bumped off apps including MC
Reenabled app nap
Fired off apps in toolbar (and did a bit of browsing cos it was getting tedious) and bumped off same apps
Got 8 dropouts

Disabled app nap again
.. same procedure - but also typed this post
Got 9 dropouts, including 2 while typing this.

So, don't think it can be app nap or media server. The only hunch I have is that I am more likely to get a drop out when doing something for the first time in a session - e.g. typing this, opening a new app, searching .. as though my mini is too absorbed doing the new thing and forgets to give MC a go.

JimH · « **Reply #206 on:** July 21, 2015, 06:42:20 am »

We'll keep chasing this, but it just smells like an OS bug. Doing something in another program, like a browser, should have minimal effect on MC.

Maybe someone with the time could search for similar problems with the latest verson of OSX. I know someone posted a USB problem with OSX recently.

AndyU · « **Reply #207 on:** July 21, 2015, 06:56:12 am »

Quote from: JimH on July 21, 2015, 06:42:20 am

We'll keep chasing this, but it just smells like an OS bug. Doing something in another program, like a browser, should have minimal effect on MC.

Maybe someone with the time could search for similar problems with the latest verson of OSX. I know someone posted a USB problem with OSX recently.

If it is an OS bug, why would iTunes and Audirvana+ not be similarly affected? Or what do they do to avoid the bug that MC doesn't?

JimH · « **Reply #208 on:** July 21, 2015, 07:00:37 am »

People often say similar things about bugs. Every program interacts differently with other software (like drivers) and bugs are usually triggered by specific circumstances. So saying that it works with other software is only a data point. It doesn't eliminate the possibility of a bug in the other software.

As I said, we will continue to chase it, but please keep an open mind until the cause is found, and if you want to help, please do a thorough search for similar problems with OSX.

AndyU · « **Reply #209 on:** July 21, 2015, 07:05:38 am »

Quote from: JimH on July 21, 2015, 07:00:37 am

.. and if you want to help, please do a thorough search for similar problems with OSX.

I've already spent quite a bit of time (not to mention a little money) trying to help, but I think you guys should be way more competent than me to search thoroughly for similar problems with OSX and interpret the results, so I'll leave that to you.

JimH · « **Reply #210 on:** July 21, 2015, 07:14:56 am »

I can understand that you may be tired of this, but we're not thrilled about it either.

For your reference, this is a list I've kept (over ten years now) of problems that were reported to be bugs with MC, but turned out to be caused by other software:
http://yabb.jriver.com/interact/index.php?topic=24031.0

It's a pretty long list.

What puzzles me is that blgentry can so easily reproduce the problem by stressing his system. It is the job of an OS to handle this kind of situation, and audio playback is the lightest of duties for a computer. It just points to something more basic, in my opinion.

We will continue to look at this problem, but we've already spent a lot of time on it.

xtraktz · « **Reply #211 on:** July 21, 2015, 08:45:38 am »

I do not have this problem, using 112 version, only 124 and 126.
I think that it is not OS or hardware problem.

JimH · « **Reply #212 on:** July 21, 2015, 08:56:15 am »

Quote from: xtraktz on July 21, 2015, 08:45:38 am

I do not have this problem, using 112 version, only 124 and 126.
I think that it is not OS or hardware problem.

Again, you can't rule out the OS.

couchjr · « **Reply #213 on:** July 21, 2015, 04:48:43 pm »

JimH and other MC paladins: I hear the frustration in your virtual voices, and I'm popping back into this thread just to say that my last listening session of several hours, after updating settings as posted, and using Splashtop (minus SoundFlower) for basic control of the server and JRemote to control MC, continued rock solid under 126. So thanks again for the (no doubt unbudgeted) time you've spent on this. It's hot as blazes here and my older house has only window air-conditioners, so I'm not really able to listen for "normal" periods at present, but so far your changes have apparently moved my system below the threshold that triggers this problem. I have faith that eventually that will happen for everybody, whether there are causes outside MC or not. Thanks again.

Peregrino · « **Reply #214 on:** July 21, 2015, 05:04:14 pm »

Quote from: JohnT on July 20, 2015, 10:25:50 am

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.

I've been having similar dropouts to those described above with the last few updates of JRiver and Yosemite. I have 16gb ram and don't use any other programmes. This morning I disabled app nap with the command line (although Media Server is still running) and have had no dropouts at all today. My Mac mini runs headless controlled with JRemote.

Hope this is helpful

JimH · « **Reply #215 on:** July 21, 2015, 05:24:51 pm »

It is. Thanks.

blgentry · « **Reply #216 on:** July 21, 2015, 09:30:37 pm »

Reading the recent posts here I decided to try several things. First, I re-enabled App Nap globally on my system. I've had that disabled for a month now and it hasn't made a difference. Then I ran John's command to disable App Nap specifically for JRiver MC.

Next, seeing the success of another poster, I checked my Sound Device hardware and software buffering. I had played with these quite a bit when I first started this and had gradually returned them all to default values. I found software was set to 100 mS, so I increased it to 250 mS. Hardware is set to Hardware Default, which is the only setting that works well on my system.

Then I tried some tests: If fired off 5 or 6 apps while listening. No dropouts.. Not like yesterday when I did this and got a half dozen dropouts in under 2 minutes. I listened for a short time, then killed the extra apps and ran my memory chewer. After running the chewer for about 10 minutes, I had no problems. So I fired off a half dozen apps, including Safari. When Safari loaded I got one dropout. That's *with* the chewer running.

I listened for a total of 26 minutes with the chewer running and did things to try to make it drop out. I opened quite a few browser windows. Some on "heavy" sites like CNN and Yahoo. At one point I opened many apps again, and got a single dropout. I killed the chewer and then fired off a bunch of apps. Nada. I fired off other apps that hadn't been used recently. No dropouts.

An hour later or so I started listening again and periodically opened a bunch of apps. I also did the "load the browser" thing again. I got the browser loaded pretty heavily, with it consuming over 2 GB of RAM and over 100% of CPU. Then I fired off a bunch of apps. No problems.

I've got 2 to 3 hours of listening in with this configuration, with the last 2 having ZERO dropouts. It's too early to be super duper sure, but this is encouraging.

For the record the things I have changed:

1. Disabled Media Network.
2. Disabled App Nap for MC specifically via command line.
3. Increased software Sound Device buffering to 250 mS.

If this keeps working with no dropouts at all, I guess I'll try reversing the above changes one by one until I find the key setting or settings. Keeping my fingers crossed here.

Brian.

glynor · « **Reply #217 on:** July 21, 2015, 11:57:12 pm »

I'd happily bet you a beer that it is this:

Quote from: blgentry on July 21, 2015, 09:30:37 pm

For the record the things I have changed:

2. Disabled App Nap for MC specifically via command line.
3. Increased software Sound Device buffering to 250 mS.

And not this:

Quote from: blgentry on July 21, 2015, 09:30:37 pm

For the record the things I have changed:

1. Disabled Media Network.

Of course, if I'm proven wrong, you need to come to me to collect.

But, I think there's been some real progress made here, which is awesome. Those two things should be simple to implement within MC (change the default software buffering, perhaps dependent on the detected stats of the machine in use, and do the thing with App Nap they already know how to do).

Assuming your situation holds, please try it with Media Network re-enabled, but the other two things left alone. After that, you can try other possible combinations, but from reading this (and what I know about App Nap impacts in audio players) this totally makes sense that these two things could be interacting under certain conditions.

AndyU · « **Reply #218 on:** July 22, 2015, 03:13:34 am »

Quote from: glynor on July 21, 2015, 11:57:12 pm

I'd happily bet you a beer that it is this:

I'll take that beer - most welcome since it's 35C outside.

I have just:

disabled app napp for MC
verified that software buffering was unchanged at 250ms (as it has been for my previous posts)
verified that hardware buffering was unchanged at Maximum
verified that Media Network was OFF
turned "Play files from memory" OFF, (it had been ON)
turned Integer Mode OFF (it had been on).
Went through my app firing sequence
Got 9 dropouts
Quit the same apps
Got another 7 dropouts - including one extremely long one.

leezer3 · « **Reply #219 on:** July 22, 2015, 06:39:58 am »

Haven't got a Mac here (Well, I've got a PowerMac G3, but that's not much help

), so unfortunately I can't test any of this personally.

Something you haven't mentioned is *how* you're connecting to your network. One of your standard test routines appears to be firing off an internet browser, which I'm presuming loads page(s) as it does so.

This is somewhat of a hunch, but are you connecting using both wired and wireless connections, depending on where you are or what you're doing?
The other distinct possibility I can see is your wireless signal quality if you're only connecting via wireless.

Whilst your playing files are local, or at least that's what I've read into your post, the kernel networking stack will be doing all sorts of things, both loading webpages inside MC, and when you open Finder, webbrowsers etc.

JR can't reproduce this properly on a Mac mini, which has only ethernet (by default anyways), and the variable quality of reproduction on this makes me want to look very much outside of the box. I've seen wireless mentioned numerous times throughout the thread-
A wireless connection can drop a variable number of packets based upon where the laptop is positioned, atmospheric conditions etc. and this is very easily overlooked.

Would you be willing to post a couple of wireshark traces, one dropping and one not dropping?
If this is networking related, then it may shed a little light on what's throwing a fit.

-Leezer-

AndyU · « **Reply #220 on:** July 22, 2015, 08:40:59 am »

leezer - My Mac mini is connected to my router using a 3m Ethernet cable and wifi is off. The test library I am using consists of 4 CDS all FLAC and it is on the hard drive. When I fire off Safari that's all I do with it - I don't load any pages until maybe 10 minutes later, by which time I've had some dropouts so I typically come to this thread to report them, or maybe browse the odd site while I'm waiting for the apps to finish starting. But I get dropouts way before I do any browsing. But several of the standard apps I fire off, such as mail, Photos etc , will I suppose access the web. Nonetheless, If you can tell me what a wire shark trace is and how to make one I'll gladly post it. The only intuition I can offer is that it "feels" like I get a dropout at the moment an app comes to life, as though my machine is somehow momentarily distracted. But I wouldn't swear to that either.

leezer3 · « **Reply #221 on:** July 22, 2015, 09:13:51 am »

Wireshark is this app:
https://www.wireshark.org/download.html

Essentially, it records *everything* that's passing through your network connection.
To record a trace, follow this tutorial (Windows based, sorry, but you can probably figure it out):
http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/

Some notes:
Please don't do anything sensitive (Passwords etc.) whilst Wireshark is running; Some badly designed programs/ sites send these in plain-text, and they can be read from a Wireshark log.
Don't have a torrent client running- These generate massive amounts of network traffic.

When you have a dropout or two, stop the capture in Wireshark and save it.
Zip this up and attach here- From this we'll be able to see what's actually accessing the network, and what it's sending.

A list of your 'standard' apps may also be enlightening

Edit: Sorry, another networking related thought-
Your router model and DNS servers may also be enlightening if you know them.

-Leezer-

AndyU · « **Reply #222 on:** July 22, 2015, 09:35:14 am »

Quote from: leezer3 on July 22, 2015, 09:13:51 am

Wireshark is this app:
https://www.wireshark.org/download.html

Essentially, it records *everything* that's passing through your network connection.
To record a trace, follow this tutorial (Windows based, sorry, but you can probably figure it out):
http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/

Some notes:
Please don't do anything sensitive (Passwords etc.) whilst Wireshark is running; Some badly designed programs/ sites send these in plain-text, and they can be read from a Wireshark log.
Don't have a torrent client running- These generate massive amounts of network traffic.

When you have a dropout or two, stop the capture in Wireshark and save it.
Zip this up and attach here- From this we'll be able to see what's actually accessing the network, and what it's sending.

A list of your 'standard' apps may also be enlightening
Edit: Sorry, another networking related thought-
Your router model and DNS servers may also be enlightening if you know them.

-Leezer-

I'm sorry I'm not sure I can do the wireshark thing as most of the apps I use involve logging in and/or will bring up personal information as they launch. (Though I will typically already be logged in - don't know whether that makes a difference. You already have a list of the apps I use and the order in which I use them - see a previous post of mine on this thread. They are all pretty standard. I don't have a torrent client running. Or even have one.

My mac mini is connected by ethernet to an apple Time Capsule, which is itself connected to a NETGEAR N600.

Have to say I have been sitting listening to music and idly browsing for the last hour-ish with no trouble - but then I haven't launched many apps.

blgentry · « **Reply #223 on:** July 22, 2015, 10:12:08 am »

Quote from: leezer3 on July 22, 2015, 06:39:58 am

This is somewhat of a hunch, but are you connecting using both wired and wireless connections, depending on where you are or what you're doing?....

Quote

JR can't reproduce this properly on a Mac mini, which has only ethernet (by default anyways), and the variable quality of reproduction on this makes me want to look very much outside of the box. I've seen wireless mentioned numerous times throughout the thread-
A wireless connection can drop a variable number of packets based upon where the laptop is positioned, atmospheric conditions etc. and this is very easily overlooked.

I don't get your reasoning on this. Mac Minis all have wireless and always have. Do you have some reason to suspect that network activity from other programs is impacting JRiver?

Brian.

leezer3 · « **Reply #224 on:** July 22, 2015, 11:18:56 am »

Yes and no; I'll admit that I hadn't noticed the fact that all Mac Minis have wireless, but that's relatively irrelvant to the point

The first thing I noticed was that just about everyone on this thread at some point or another is using a network related program, usually Firefox/ Safari. Sure, this is 'normal' usage but it's a major point of correlation.
As we've got users who have tested with files on a local drive, as well as on NAS boxes of various descriptions, this tends to rule out the SAMBA [This is the feature that allows OSX to 'talk' & share files with a non-Apple box] implementation.
Similarly, we've played with just about every setting including Media Network and the buffering settings, and so whilst these may help to hide the problem, they're clearly not at it's root

So, looking deeper into *possible* causes, I went ferreting into Google. One of the more interesting sites I ran across was this:
http://macperformanceguide.com/blog/2015/20150104_1942-network-performance.html
I've also seen various complaints about the network stack in Yosemite randomly deciding to eat CPU and freeze itself solid, which again make me suspicious of networking in general.

The article in question is relatively technical, but in essence, it's showing the OSX networking stack completely locking up for ~30s at a time under high CPU/ memory load conditions.
Whilst this is more extreme than we're seeing here, it fits the same pattern. I also suspect that packet loss from wireless connections is very likely to exacerbate this.
Whilst obviously this isn't a direct connection to MC, I'm very suspicious that something somewhere in the works is waiting on the networking stack to unstick itself.
A Wireshark trace would hopefully show what MC is sending and recieving in terms of network packets, and whether the whole network stack decides to freeze

My main experience is in Linux & Windows, but you simply can't change the fundamentals of how operating systems work-
If a major component used by every app gets into a deadlock state, no matter how briefly, then anything relying on that component will have issues

-Leezer-

JimH · « **Reply #225 on:** July 22, 2015, 11:22:38 am »

Thanks, Leezer.

AndyU · « **Reply #226 on:** July 22, 2015, 02:23:11 pm »

Quote from: leezer3 on July 22, 2015, 11:18:56 am

...
I also suspect that packet loss from wireless connections is very likely to exacerbate this.
...
-Leezer-

This cannot possibly account for my problems, as my wifi is turned off. I am only using an Ethernet connection.

leezer3 · « **Reply #227 on:** July 22, 2015, 04:30:19 pm »

Quote from: AndyU on July 22, 2015, 02:23:11 pm

This cannot possibly account for my problems, as my wifi is turned off. I am only using an Ethernet connection.

I said exacerbate, not cause

A wireless connection is effectively sending out '00s of little packets of data into the air. Not all of these arrive at the destination point (your router), and so those which do not must be resent.
Now, the more packets that must be resent, the harder the networking stack must work, thus if this is related to the networking stack it's more likely to occur on wireless

The article I linked to above shows one case of the OSX networking stack effectively freezing under extremely heavy load. Here's another one (I believe fixed in the latest version of Yosemite, but I can't test):
http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/
https://discussions.apple.com/thread/6662210

Again, this is *not* conclusive of anything, I'm rather trying to think out of the box based upon the common causality factors

-Leezer-

glynor · « **Reply #228 on:** July 22, 2015, 09:46:51 pm »

Quote from: leezer3 on July 22, 2015, 04:30:19 pm

I said exacerbate, not cause

A wireless connection is effectively sending out '00s of little packets of data into the air.

Not if it is turned off.

Also, Apple shelved the new discoveryd daemon and reverted to mdnsresponder in 10.10.4, so even if the issue was with multicast DNS, it wouldn't be applicable anymore on the current version. I have certainly seen issues with my Macbook and wifi occasionally, and this does include issues that have impacted performance here and there, but only under fairly specific circumstances. Almost all of these issues were corrected with 10.10.3 and I have had absolutely no issues since 10.10.4 (even with relatively old hardware). So essentially all of the links you posted aren't relevant at all anymore (and many of them wouldn't apply here anyway, under most circumstances).

And, if it is turned off, it is turned off. Macs do shut down the radios when you turn off Wifi, so as long as it is actually off, it isn't possibly the culprit.

For the record, I don't think Andy and Brian's problems are related at all. Throughout this thread, they have not exhibited the same kind of behavior. Possibly one is exacerbating the other, but I think those two issues in particular are discreet.

Andy, have you tested with local files?

Brian, what, if anything, have you learned from the past day (see above)?

glynor · « **Reply #229 on:** July 22, 2015, 09:54:22 pm »

Quote from: AndyU on July 22, 2015, 03:13:34 am

I have just:

disabled app napp for MC
verified that software buffering was unchanged at 250ms (as it has been for my previous posts)
verified that hardware buffering was unchanged at Maximum
verified that Media Network was OFF
turned "Play files from memory" OFF, (it had been ON)
turned Integer Mode OFF (it had been on).
Went through my app firing sequence
Got 9 dropouts
Quit the same apps
Got another 7 dropouts - including one extremely long one.

Not to be a jerk, but this is terrible testing procedure, and makes it hard to diagnose anything.

Please test one change at a time. Start from defaults. Reset MC's settings if needed (make a Library Backup first, and you can always restore it later if nothing helps).

blgentry · « **Reply #230 on:** July 22, 2015, 10:20:38 pm »

Quote from: glynor on July 22, 2015, 09:46:51 pm

Brian, what, if anything, have you learned from the past day (see above)?

I have an additional 3 hours (give or take an hour) of listening time in with this configuration. No dropouts that I can remember in this time. Though I did get a single dropout near the beginning of this testing cycle while saving album art to an album's worth of files.

I want to have a large amount of listening time with no dropouts at all so I can have a baseline that I'm sure about. I've had several false "solutions" to this in the past few months, so I want to be much more sure that I have a real working configuration this time before I change anything.

I'll probably report back here in another day or two; after I've got something like 8 to 10 hours of no-drop listening time in.

Brian.

glynor · « **Reply #231 on:** July 22, 2015, 10:28:40 pm »

Thanks for the report.

AndyU · « **Reply #232 on:** July 23, 2015, 01:22:35 am »

Quote from: glynor on July 22, 2015, 09:54:22 pm

Not to be a jerk, but this is terrible testing procedure, and makes it hard to diagnose anything.

Please test one change at a time. Start from defaults. Reset MC's settings if needed (make a Library Backup first, and you can always restore it later if nothing helps).

I am sorry you think my testing procedure is terrible. It's beautiful weather outside and there are many more pleasurable things I could be doing than sitting in front of a screen listening for dropouts in what would otherwise be nice music. People have hypothesised on this thread that app nap is involved, that integer mode is involved, that memory playback is involved and that wifi is involved. My "terrible" tests at least show that I get dropouts whether or not these things are on or off. There are way too many combinations to test though. Nonetheless I will download an absolutely fresh copy of MC and make another test with it at its. default settings. (or is there some other way of setting it back to defaults?)

And you still lose your bet.

glynor · « **Reply #233 on:** July 23, 2015, 06:16:27 am »

My bet wasn't with you, though I like beer, so if you show up here, I'm still happy to buy you one.

Re-downloading MC won't reset anything.

1. Make a Library Backup.
2. Make sure MC is completely closed.
3. Delete (or move) ~/Library/Application Support/J River/Media Center 20/Settings/User Settings.ini

xtraktz · « **Reply #234 on:** July 23, 2015, 06:52:19 am »

That about this bug in MC21?

AndyU · « **Reply #235 on:** July 23, 2015, 11:56:18 am »

Quote from: glynor on July 23, 2015, 06:16:27 am

My bet wasn't with you, though I like beer, so if you show up here, I'm still happy to buy you one.

Re-downloading MC won't reset anything.

1. Make a Library Backup.
2. Make sure MC is completely closed.
3. Delete (or move) ~/Library/Application Support/J River/Media Center 20/Settings/User Settings.ini

OK, just done that. And rebooted my machine from scratch, to be sure to be sure.

Started MC, it had found my four test cds.
Started playing my test track.
Fired up my apps (see previous post)
Got 8 drop outs.
Went into MC to look at settings. (Playback Options > Device Settings
Noticed that buffering was set to 100ms, integer mode off.
As the settings windows were opening and closing I got another 13 dropouts, some rather louder and in a real burst - they seemed to intensify when I was in MC, though that could just be superstitious as some apps were still coming to life.
Shut down the same apps
Got 2 more drop outs.
But I am sitting here typing this with no drop outs.

So, looks like the 250 ms buffering I had been using for previous tests was better than the default settings.

And my wi-fi is off.

I'll take the beer now.

JimH · « **Reply #236 on:** July 23, 2015, 12:00:30 pm »

Are you playing from a CD drive?

AndyU · « **Reply #237 on:** July 23, 2015, 12:40:13 pm »

Quote from: JimH on July 23, 2015, 12:00:30 pm

Are you playing from a CD drive?

No. I've already told you what I am playing from. A library of 4 cds worth of FLAC rips on the hard drive. My Mac mini has no cd drive.

Since the previous post I've done three more runs.

1. Someone earlier was speculating about networking/ethernet having something to do with it. My wifi is turned off in any case. I disconnected my ethernet cable and ran the same test. I only got one drop-out.

2. So I reconnected my ethernet cable, checked that I could get online, and ran the same test again. Still only one drop-out.

3. I shut down my mini and restarted and ran the same test. Got 11 drop-outs.

4. But am typing this and listening and it's ok. Haven't got time to sit and listen anymore tonight.

I'm not sure what you can conclude from my tests. It certainly seems that starting apps from absolute scratch (i.e. logging in) is the worst case. I share this Mac mini with my wife and most of my previous tests will have been done straight after I log in. I think there was one time when I repeated my test and got fewer dropouts the second run. And I think I've said in earlier posts that doing something for the first time - a spotlight search for example - seemed to provoke a drop-out or two so maybe there's a clue for you there.

If you have any specific suggestions for me to try please let me know. I'll possibly have another bash tomorrow after my wife has been using her account so that I repeat a similar situation that existed for previous posts of mine.

JimH · « **Reply #238 on:** July 23, 2015, 12:43:31 pm »

OK. This is why I said that:

Quote from: AndyU on July 23, 2015, 11:56:18 am

Started MC, it had found my four test cds.

glynor · « **Reply #239 on:** July 23, 2015, 02:14:54 pm »

Quote from: AndyU on July 23, 2015, 11:56:18 am

So, looks like the 250 ms buffering I had been using for previous tests was better than the default settings.

Yes. I'd expect it to be. The idea was to get you back to the defaults because you'd tried so many things that who knew where the "starting point" was. So, assuming you didn't mess with too much, please set these two things, and ONLY these two things:

1. Increase software Sound Device buffering to 250 ms under Tools > Options > Audio > Device Settings > Buffering > Software.

2. Disable App Nap on MC 20 as described by John here:

Quote from: JohnT on July 20, 2015, 10:25:50 am

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

defaults write com.jriver.MediaCenter20 NSAppSleepDisabled -bool YES

Then test it for a bit with JUST those things changed, and everything else under Tools > Options > Audio at the defaults.

Also, I'm sure you said it before somewhere in this epic thread, but can you re-iterate:
* Where your files are stored (exact path).
* What file type are they?
* What kind of audio output are you using.

Thanks. Oh, and...

Quote from: AndyU on July 23, 2015, 11:56:18 am

I'll take the beer now.

Hah. As I mentioned before, you were never a party to the bet (which was directed at Brian for his problem). But, despite that, I'll pay up. Same terms, though. You have to come to me. I'm on an island in coastal Maine. It's nice here, so if you come visit, I'll happily buy you a beer (or four).

AndyU · « **Reply #240 on:** July 23, 2015, 11:40:38 pm »

Quote from: glynor on July 23, 2015, 02:14:54 pm

So, assuming you didn't mess with too much, please set these two things, and ONLY these two things:

1. Increase software Sound Device buffering to 250 ms under Tools > Options > Audio > Device Settings > Buffering > Software.

2. Disable App Nap on MC 20 as described by John here:
Then test it for a bit with JUST those things changed, and everything else under Tools > Options > Audio at the defaults.

OK, just done that.
Fired off my apps one after the other.
Got 4 drop outs
Shut the machine down and restarted (as this seems to provoke the problem).
Did the disable app nap thing again (because I don't know whether it persists)
Run MC, Fired off my apps one after the other.
Got 8 drop outs.
As usual, it then quietens down.

Quote

Also, I'm sure you said it before somewhere in this epic thread, but can you re-iterate:
* Where your files are stored (exact path).
* What file type are they?
* What kind of audio output are you using.

Hah. As I mentioned before, you were never a party to the bet (which was directed at Brian for his problem).

My files are stored in Macintosh HD/Users/(my name)/Music/My Music
There are four sub folders.
The track I am playing is in a folder called "Mozart"
The track is called "01 - Piano Concerto No. 25 in C major, K. 503; Allegro maestoso.flac"
Across the four folders there are about 30 tracks which are all FLACs.

I am listening to headphones through the headphone socket. I have had similar results using a decent DAC via USB.

I am not sure that Brian's problem is different from mine. He typically uses a different way of provoking dropouts, but when he fired off his apps like I do he got a similar result.

If anyone is working my problem, it may be worth them trying to provoke it from a shutdown/restart or logout/login - definitely get more dropouts that way.

No dropouts while typing this.

ps, adamt - nearly a week ago I sent you a log, as you asked. Have you looked at it? Some feedback would make my effort feel worthwhile.

JimH · « **Reply #241 on:** July 24, 2015, 07:06:00 am »

If you can induce stuttering or breaks in playback just by opening an application, that just has to be a problem at the OS or driver level. An OS is normally really good at running a lot of processes without problems.

We'll continue to work on it though.

adamt · « **Reply #242 on:** July 24, 2015, 08:23:26 am »

Quote from: AndyU on July 23, 2015, 11:40:38 pm

ps, adamt - nearly a week ago I sent you a log, as you asked. Have you looked at it? Some feedback would make my effort feel worthwhile.

Thanks for your log. We added a statement that says "Core audio is asking for more data than we have available?" in order to hopefully track the dropouts. For some reason it doesn't show up at all in your log, while it did in blgentry's and couchjr's. This further suggests yours might be a slightly different problem.

JimH · « **Reply #243 on:** July 24, 2015, 08:25:49 am »

Or an older version?

adamt · « **Reply #244 on:** July 24, 2015, 08:28:26 am »

Quote from: JimH on July 24, 2015, 08:25:49 am

Or an older version?

Thought so too, but the log says the correct version (126).

glynor · « **Reply #245 on:** July 24, 2015, 11:27:14 am »

Older OS version, I think he meant.

To me, it has the stink of a hardware issue, or perhaps an OS bug on particular hardware platform, not well tested.

AndyU · « **Reply #246 on:** July 24, 2015, 11:53:11 am »

Quote from: glynor on July 24, 2015, 11:27:14 am

Older OS version, I think he meant.

To me, it has the stink of a hardware issue, or perhaps an OS bug on particular hardware platform, not well tested.

My OS is, as far as I know, up to date. It is OS X Yosemite 10.10.4. I just clicked the software update button and it says "No updates available". The macmini is a few months old - Late 2014 it says when I do an about. It is the relatively new low-powered model.

Apple US have a decent returns policy, why not get the same base level machine I have, see if you can replicate the problem and take it from there. It'll only cost you the return postage. Surely this would be a more useful way to proceed than conjecturing about stinks - you can do that forever and get nowhere.

btw, it is not exclusively opening a lot of apps at once that provokes dropouts on my machine, it's just that doing that particularly when I have just logged in, is a very good way of provoking 8 or 10 or so of them within a few minutes.

glynor · « **Reply #247 on:** July 24, 2015, 01:32:00 pm »

Quote from: AndyU on July 24, 2015, 11:53:11 am

Apple US have a decent returns policy, why not get the same base level machine I have, see if you can replicate the problem and take it from there. It'll only cost you the return postage. Surely this would be a more useful way to proceed than conjecturing about stinks - you can do that forever and get nowhere.

Perhaps JRiver can do that, but I'm not going to. I have a very nice quad-core Ivy Bridge Mini which works very, very well.

I'm just trying to help.

blgentry · « **Reply #248 on:** July 25, 2015, 09:33:27 am »

Ok, I have a mixed report. I have roughly 10 hours of listening time clocked with my new configuration. The first 4 hours I didn't log anything (my manual log keeping, not a JRiver log). But in those 4 hours (maybe as much as 6) I got one dropout I can remember, and that was during saving Album Art to an album (6 or 10 files worth).

Then I started formally keeping a formal log. In the ~6.5 hours of keeping that log, I had mixed results. The first 3.5 hours I got one dropout. Again, while saving album art to an entire album. Then, shortly after, I got:

Code: [Select]

6/24  09:14  Pressed Play
6/24  09:19  Dropout with a bunch of tabs open in firefox.  Memory:  no free RAM, 400 MB cache
6/24  09:45  Paused

So, in about 4 hours of logged time, I got one dropout from saving Album Art, and one random dropout.

Then I got another set of dropouts while saving album art. This was a big album with like 40 tracks:

Code: [Select]

6/24  20:29  Play
6/24  20:30  Dropout.  Repeated.  About 45 seconds after saving album art to a big album

Next I decided to see what would happen if I opened a lot of apps at once. I had done this test before and gotten no dropouts. I wanted to test it again. Repeatability is the foundation of good experiments.

Code: [Select]

6/24  20:42  Dropout.  2. 3. 4. Just started several apps at once as a test.
6/24  21:01  Pause

Next, I remembered that one member here does a lot of logging out and logging back in. I run my Mac logged in all the time and only log out or reboot when I get updates or for some other reason that forces me to. I've done this for many years as my standard practice, so it's a "normal" way of using a Mac. So I decided to log out and back in to simulate what happens with our other member.

Code: [Select]

---logged out and logged back in---
Minimal applications started.  Just going to start MC and then fire up 6 apps or so to test for dropouts.

6/24  21:53  Play
6/24  21:53  firing up a bunch of apps
6/24  21:54  Dropout.
6/24  21:55  Killed those apps.  Firing up other apps
6/24  21:57  All apps up.  Opened some new documents in Open Office.  Navigated in lightroom. No dropouts.
6/24  21:59  Opened firefox with a bunch of tabs.  No dropouts.
6/24  22:09  Firing up 6 more apps to test
6/24  22:11  All apps launched super super quick.  Must have been cached.  Killed all apps.  No dropouts
6/24  22:13  Fired off 7 or 8 apps that I have not used this login session.  Random stuff from the Applications folder.  No dropouts.  Quit them all.
6/24  22:16  Pause

Ok, that's mostly good news. What about my memory chewer? How will the system react?

Code: [Select]

6/24  22:22  Play
6/24  22:24  Running memory chewer
6/24  22:38  Dropout.  System obviously bogged down as it took 5 seconds before this editor window would let me type.  Free memory=0 cache=400MB.  I was getting beach balls in Firefox and closing a firefox window induced this dropout.
6/24  22:41  Killing memory chewer.  Repeated dropouts as memory chewer is exiting and freeing up RAM
6/24  22:45  Pause

During a lot of this test, the system was obviously slow. This is a condition that would normally cause me to say "WTF is going on?" and fix it. This is not a good simulation of "normal use". So I give this test a pass, even though I got dropouts. The system was too heavily loaded.

Finally, I did a little midnight listening and....

Code: [Select]

6/25  00:12  Play
6/25  00:17  Dropout.  free memory=2GB.  Weird.
6/25  00:20  Pause

I wasn't doing anything other than easy web browsing and listening at the time.

My conclusions:

Some combination of the 3 settings I have changed have made MC much more resistant to dropouts. MC does much better with several torture tests (memory chewer and app launching) than before. During more casual use, the biggest trigger seems to be saving album art. Otherwise it is, again, much more resistant, but not immune. Dropouts from completely normal use (not saving album art) have gone down from 1 per hour to 1 per 3 hours. (I logged about 6.5 hours and got 2 dropouts that were not "forced" or from album art operations).

This is progress. I'll continue listening, though I'm not sure I'll log anything as it's a LOT of work to do so. I'm willing to do it selectively when there's something new to test.

Thanks guys.

Brian.

glynor · « **Reply #249 on:** July 25, 2015, 10:13:14 am »

That's great info, Brian. Now that you have a good baseline, I'd like to see results of two additional tests:

1. If you leave everything else as it is, and turn Media Network back on, does it go back in the crapper again, or does it stay pretty much consistent?

If that comes out essentially identical (I suspect it will, but I'd like to see), then keep it enabled. Otherwise, turn it back off again and try:

2. Set Software Buffering to 500ms.

You could do these in the opposite order, if you want. But, I'd like independent tests of both.

I'm thinking they might want to make the following changes:

* Disable App Nap entirely for MC20 as they can with their plist file.
* Increase the default Software Buffer setting for MC on Mac to 250ms.
* Perhaps provide a few more buffering settings (up to 750ms, perhaps, and maybe one between 250 and 500).

It also sounds like they could maybe do more to ensure that tagging writes to the files are done on a low-priority background thread. Unfortunately, you might just be hitting limits of OSX's filesystem support on your disks here, though. This is, of course, one of the biggest differences between MC and other applications. It hits the filesystem even when it is playing, to do things like write tags, update the Library, and other things. Unfortunately, the Mac filesystem architecture has serious concurrency issues:

From Siracusa's Lion Review:

Quote

File system metadata structures in HFS+ have global locks. Only one process can update the file system at a time. This is an embarrassment in an age of preemptive multitasking and 16-core CPUs. Modern file systems like ZFS allow multiple simultaneous updates, even to files that are in the same directory.

To be clear, you're unlikely to be able to get rid of them in the most extreme of circumstances, without making hardware changes. Loading all of those apps, for example, is going to thrash the disk. If they're all on the same disk, and it is a slower spinning disk, you're going to hit Random Access limits of the physical drives. This, plus the ancient HFS+ concurrency limits, means it might just not be possible to buffer enough to handle those situations and keep the buffers full. That doesn't mean it shouldn't work under normal circumstances, though. It sounds like it is pretty close with these settings to "working" under normal circumstances. Perhaps, except needing tweaks to the cover art saving behavior (though this could depend on your particular disk setup, and the cover art you're saving).

But, we really need to see and rule in/out Media Network as a potential cause here. It shouldn't have an impact, if you aren't hitting some bizarre OSX-network-stack-broken circumstances (which might depend on your particular network environment), especially if you aren't actually connecting to and using MC's Media Network features.

INTERACT FORUM

Author Topic: Audio Dropouts / Mac Performance (Read 85910 times)