INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Mac => Topic started by: blgentry on May 13, 2015, 03:26:31 pm
-
I've noticed for quite some time now that I get somewhat frequent sound drop outs with MC for OS X. It's usually just a blip, but occasionally it lasts for a second or two. This gets pretty annoying as I'm not used to media players doing this, especially on good hardware. My Macbook Pro has a quad core i7 at 2.0 GHz, so it's fairly modern.
I can just about 100% trace these dropouts to activity of other programs on my Mac. Firefox in particular, as it uses a LOT of memory the way I browse the internet. Pretty much any time I'm having playback interruptions, I'll look at Activity Monitor and see that RAM is almost completely used up and that Firefox is using a ton of it. Restarting Firefox fixes this for a time... though it's rather ironic that when I restart Firefox, I *can* get dropouts then too as it opens all the windows I had open previously!
If I had more RAM (I've got 8 GB) I probably wouldn't have this as often, unless I upped my web browsing (or other program activity) accordingly.
My question is, can I minimize this behavior with MC at all? I've tried memory playback and it doesn't make a bit of difference in terms of the drop outs. I've also tinkered with the software and hardware buffering, but (so far) I haven't noticed any difference there either. I'm open to suggestion if there's more I should do there. I'm wondering if I can set some sort of processor or memory affinity for MC? Or perhaps some option I have yet to locate in MC? This really does seem to be memory (RAM) related based on what I've experienced.
Of course I could just stop and start Firefox once (or twice or three times) a day. Or use a browser more like a sane person. But where's the fun in that??? :)
Thanks for any suggestions.
Brian.
-
Hi blg
I am a complete noob to macs so forgive me if this is a well know optimisation. Only had one for two weeks
I was getting 1sec dropouts constantly after the mini had been playing for a couple of hours or so, couldn't work out why. Anyway i found a setting referred to in the Audirvana user manual, page 38, basically it mentioned that the USB should be on its own hub.
I followed the instructions the other day, very simple, and so far i have not had one drop out. Hope I've not just jinxed myself.
-
I've noticed for quite some time now that I get somewhat frequent sound drop outs with MC for OS X. It's usually just a blip, but occasionally it lasts for a second or two. This gets pretty annoying as I'm not used to media players doing this, especially on good hardware. My Macbook Pro has a quad core i7 at 2.0 GHz, so it's fairly modern.
I can just about 100% trace these dropouts to activity of other programs on my Mac. Firefox in particular, as it uses a LOT of memory the way I browse the internet. Pretty much any time I'm having playback interruptions, I'll look at Activity Monitor and see that RAM is almost completely used up and that Firefox is using a ton of it. Restarting Firefox fixes this for a time... though it's rather ironic that when I restart Firefox, I *can* get dropouts then too as it opens all the windows I had open previously!
If I had more RAM (I've got 8 GB) I probably wouldn't have this as often, unless I upped my web browsing (or other program activity) accordingly.
My question is, can I minimize this behavior with MC at all? I've tried memory playback and it doesn't make a bit of difference in terms of the drop outs. I've also tinkered with the software and hardware buffering, but (so far) I haven't noticed any difference there either. I'm open to suggestion if there's more I should do there. I'm wondering if I can set some sort of processor or memory affinity for MC? Or perhaps some option I have yet to locate in MC? This really does seem to be memory (RAM) related based on what I've experienced.
Of course I could just stop and start Firefox once (or twice or three times) a day. Or use a browser more like a sane person. But where's the fun in that??? :)
Thanks for any suggestions.
Brian.
When you run out of RAM the computer begins using swap/virtual memory, which is orders of magnitude slower than RAM. If it happens to run out of swap, it will start killing processes. No program will be well behaved in a RAM-starved environment, it's only a question of how badly behaved it will be. Having to use swap memory will slow everything down (even programs still in RAM) because trying to access the hard-drive as though it were RAM is processor intensive. Have a look at your CPU load next time you see the problem, and I'm willing to bet you'll see periodic spikes there too.
Try increasing your buffer sizes to the maximum under audio options to see if you can "wait it out," but the real solution is not to over-commit your memory (i.e. close some tabs).
-
Thanks for the replies guys.
Foxman: I've done a lot of experiments with my USB configuration and I've got that nailed down. This used to happen with the internal sound card too, so I'm pretty certain it's not a USB issue.
mwilliems: Thanks for the consideration. However, I'm pretty sure I'm no where near swapping. I'm pretty experienced with this kind of thing and normally when swapping occurs the entire system slows noticeably. That's one thing that's odd about this: The computer really doesn't slow down at ALL. It's all full speed, I just get dropouts. In terms of CPU, I'd expect high CPU to be an issue, but it really doesn't seem to be. For example:
Right now I'm typing this in Firefox with several windows and tabs open. I'm also listening to some music with Media Center (True Faith by New Order right this moment). The crazy thing is, I'm also ripping a DVD as I'm doing all this, which has all 8 CPU cores showing between 99% and 100%. Activity Monitor shows about 96% overall CPU utilization. Yet the system is responsive and I've got no audio dropouts at all. This is kind of what I'm used to with a Mac. Except I haven't experienced a media player dropping audio before. Hell, I can even play back a movie with VLC and get no sign of strain (just tried it).
I really do appreciate any help I can get on this. I'm just saying what I've observed and tried.
Thanks,
Brian.
-
I've done a bunch of experiments today. I found by looking at Activity Monitor that almost every time I had a dropout, there was disk activity, specifically, disk *writes*. I theorized that these were Firefox writing to it's cache every time I loaded a new web page.
So I moved firefox's cache to an external drive and ran with that for a while. After an hour or so, I got a dropout or two. So that's obviously not the entire problem.
Next I moved Firefox's cache back to the internal drive and moved my current playlist of 228 songs to the external drive. This induced a LOT of I/O as it moved the files and I got a bunch of dropouts during the move. After the move, it settled down and played well for a while. Again, maybe an hour, or a little less. Then I got some dropouts. <sigh>
So I moved the files back to the internal drive. This time I didn't get any dropouts during the move, which was kind of amazing actually. I examined Firefox's cache and found it had a lot of entries, so I cleared it. TONS of dropouts during the cache clear. Seconds at a time in fact. This must have hit the disk really hard.
For maybe 2 hours or so, maybe slightly longer, everything was smooth. Then I got some dropouts again. Note that during these tests I've always had at least a little bit of free RAM, sometimes a LOT of free RAM. During some of the audio dropouts, I had more than a gigabyte of free RAM, so I'm now pretty sure this is not a RAM issue.
It also doesn't seem to be related to the transfer of files from disk since I got dropouts with the files on an external disk.
I've also characterized the reads and writes by process and found that most of the time, the big writes are in fact Firefox. But other times it's system processes like launchd and mdworker. I don't know what those processes do; I was just looking for clues to the pattern of reads and writes I saw in activity monitor.
I'm not really sure where to go from here. I'm open to suggestions.
Brian.
-
What happens if you increase the buffering in Options > Audio > Device settings?
-
I've moved three buffer related settings at different times:
Hardware buffering: Changed from default to maximum power of 2.
Software: Changed from 100 mS to 500 mS
Prebuffering: changed from 6 S to 20 S.
None seem to have made a difference. I'm not sure if there's a systematic way to try them. I've tried prebuffer=20 with independent combinations of Hardware and Software settings. If you've got a suggestion for how to combine these in various tests, I'm willing to try.
Brian.
-
Hardware buffering: Changed from default to maximum power of 2.
Software: Changed from 100 mS to 500 mS
Prebuffering: changed from 6 S to 20 S.
None seem to have made a difference.
been there done that...
I've been getting the same occasional drop out since the 1st incarnation of mc20. It happens at least once a day and up to 1 sec. And that's with running nothing but MC on 8gb ram on macbook pro 7,1.
(unrelated: MC is also still crashing occasionally when doing a search in the top right search field. at least once a day.)
-
Yes i have been getting this on Mac latest version, only version I've tried so can't compare. Have tried all the buffer settings to no avail. Mac mini has clean install and is 2012 i7 16gb and SSD so resources are not an issue. I use MC as a UPNP client with minimserver running on a NAS.
-
Well, I was hoping I was on to something and tried the following one at a time:
Disabled Firefox's disk cache completely.
Turned off video adapter switching in Energy Saver.
Moved my DAC to a dedicated USB2 port directly on the Macbook Pro.
Rebooted to "start from scratch".
I've been *living* in Activity Monitor for the past few days waiting for dropouts to happen. I keep getting them more or less once an hour. Just got two in a row in fact with over 1 GB of RAM free, CPU under 10%, and only some moderate blips on the disk activity meter.
If I had an SSD drive I would be tempted right now to move my OS and Applications over to it. But I don't. :( I'm not willing to spend more than $200 as an experiment either unfortunately.
I had the totally insane idea earlier today to completely reinstall OSX from scratch. I'm *almost* willing, but it's a BIG project and would probably take 3 to 6 hours including restoring several hundred GB of data. I'm not sure I feel that crazy just yet.
Brian.
-
Mine was fine then started dropping out, must have been 30 times over two minutes. Never been this bad. Nothing in activity monitor, but what i did notice is the small signal analyser window in MC was playing constantly even though the sound would drop out for a second each time. Not sure how i can prove what the fault is
-
Is a network involved? Are the files local?
What happens once an hour?
-
On my system JRiver MC is installed on a MBP with all of the media on the internal drive. So, no network involved in playback. Of course the computer itself is on a wifi network for internet access. I have Media Network enabled, but only so I can use Gizmo from my Android from time to time (not very often at all).
I say "once an hour", but that's just an average. It really is pretty random. I could start keeping a log I suppose and see if I can pinpoint anything.
I'm open to any ideas for isolating this, short of "stop using everything else on your computer". I love music, but I listen while I do other stuff, so having JRiver running alone isn't very useful for me personally. But seriously, I'm open to testing and I want to find the problem. :)
Brian.
-
I'll see if I can reproduce this - I've not experienced this issue. What I'll try is loading a ton of tabs in Firefox while playing music to see what happens, if anything.
-
I've also never experienced this.
Simple step-by-step to reproduce (with numbered steps) would be useful. There's a lot of stuff in this thread.
-
Step by step for me is:
1. Use Mac normally. This includes running Firefox pretty much 24/7 with several windows and tabs.
2. Play music in JRiver MC.
3. Wait for dropouts. They will happen.
JRMark on my system is 2345. I'm not sure where that rates, but this computer seems medium powerful.
Brian.
-
Odd, I use it a good bit and I don't notice this at all but then again, I use Chrome way more than Firefox so for the sake of testing I'll use Firefox for the time being.
My JRMark is nearly double yours at 4341, but I'm not using an actual Mac but a Hackintosh. :P
EDIT: I forgot to ask, is OS X installed on a SSD or HDD?
-
OSX, JRiver, and my media files are all on the internal Macbook Pro (500 GB 2.5") hard drive. Not an SSD unfortunately.
I could switch to Chrome for a day or two if I thought that would fix the problem. Forever in fact, even though I'm a super long time Firefox user.
Brian.
-
I use Firefox and basically never close it.
How many windows and tabs?
-
I use Firefox and basically never close it.
How many windows and tabs?
I'm normally completely insane with something like 8 to 10 windows with 1 to 10 tabs each. Recently I've dialed it way back. What I have open now is typical for the past several weeks: 5 windows, one of which has 3 tabs; the others have one tab each.
Brian.
-
Are you secretly John Siracusa?
No, wait. He'd have had 30 windows open or some kind of nonsense like that. Yeah, I use Firefox roughly like that, and don't see anything similar. Of course, none of my Macs have less than 16GB of RAM, and I have SSDs all around.
The SSD shouldn't make that much of a difference if you aren't swapping. If you are swapping, well... That's terrible.
-
JRMark on my system is 2345. I'm not sure where that rates, but this computer seems medium powerful.
That's fair to say. Not bad, not great, but OK.
-
Did you try testing with Safari?
-
@Glynor: I shouldn't be swapping, as I don't notice massive slow downs that normally accompany swapping. Also, watching Activity Monitor recently (and obsessively), I've noticed that with my reduced browser use, OSX is allocating a LOT of RAM to cache, which means the programs don't need it, so I can't be swapping in that particular condition. (of having lots of RAM cache)
@JimH: I haven't testing using any browser than Firefox since noticing this problem. I'm only focusing on firefox because it's my most heavily used application. Plus I've seen a lot of disk writes from it (using iotop, an OSX profiling tool). And of course firefox is consistently the largest user of RAM on my system. If I were to use Chrome or Safari in the same way, I'd expect similar RAM usage. But that's more than you asked.
Brian.
-
I'd try Safari in this case as the alternate in this test - Chrome could potentially use more resources and make it worse.
A thought, which browser extensions do you use in Firefox?
-
We've seen browser problems before:
http://yabb.jriver.com/interact/index.php?topic=91720.msg631293#msg631293
The extensions suggestion is a good one.
-
A few more questions, Brian...
(1) Do you have MC set to run full-time? Does it seem to happen only when MC has been running a long while, and/or can you solve it immediately by quitting/relaunching MC?
(2) If the answer to #1 is yes, then when the issue is happening, go to Activity Monitor and pull up the info on Media Center 20.app. Switch to the Open Files and Ports "tab" of the info dialog. Look through the list. Do you see any media files listed in there that Media Center isn't actively using (playing or paused) which seem to be "stuck" there? In particular, do you see the same file (or files) over and over and over?
(3) If the answer to #1 is yes, also report the stuff off of the Memory tab. In particular, the Real Memory size. Mine, for reference, has been running at least 24 hours. The play state is currently stopped. I'm seeing:
Real Memory: 112.6MB
Virtual Memory: 3.85GB
Shared Memory: 41.9MB
Private Memory: 53.3MB
If yours is way out of whack with those kinds of numbers, we might be looking at a leak somewhere. The #2 info could be illuminating.
-
Regarding browser extensions in Firefox: I really only use Text Link and Image Zoom. I had 2 others installed that I never really use (NetVideo Hunter and BugMeNot), but I just uninstalled them and restarted Firefox as an additional testing point. I've started keeping a lot of dropouts, so we'll see soon if this makes any difference or not.
Brian.
-
Testing with Safari would tell you a lot.
-
(1) Do you have MC set to run full-time? Does it seem to happen only when MC has been running a long while, and/or can you solve it immediately by quitting/relaunching MC?
I'm not using MC's startup options. I start it and stop it when I want. But that mostly means that it runs nearly 24/7, as I have little reason to quit the program. That being said, I have now had TWO instances where MC was skipping/stuttering every 10 to 20 seconds; stopping and restarting the program in that case fixed the problem. That's twice out of hundreds of listening sessions.
(2) If the answer to #1 is yes, then when the issue is happening, go to Activity Monitor and pull up the info on Media Center 20.app. Switch to the Open Files and Ports "tab" of the info dialog. Look through the list. Do you see any media files listed in there that Media Center isn't actively using (playing or paused) which seem to be "stuck" there? In particular, do you see the same file (or files) over and over and over?
I'll look next time it happens.
(3) If the answer to #1 is yes, also report the stuff off of the Memory tab. In particular, the Real Memory size. Mine, for reference, has been running at least 24 hours. The play state is currently stopped. I'm seeing:
Real Memory: 112.6MB
Virtual Memory: 3.85GB
Shared Memory: 41.9MB
Private Memory: 53.3MB
If yours is way out of whack with those kinds of numbers, we might be looking at a leak somewhere. The #2 info could be illuminating.
Currently, with MC Paused, but running for around 18 hours or so I have:
Real Memory: 219.0MB
Virtual Memory: 8.0GB (Note this is the entire system Virtual Memory. I don't have a column that's selectable for Virtual Memory per program)
Shared Memory: 30.3MB
Private Memory: 130.7MB
I'll post more results later.
Brian.
-
Virtual Memory: 8.0GB (Note this is the entire system Virtual Memory. I don't have a column that's selectable for Virtual Memory per program)
Not columns in Activity Monitor. Double click on the application itself to bring up the info on just that app.
-
You can check the Open Files thing even when it isn't happening, as long as it has been running a while.
-
Just had another dropout. Here's the memory stat:
real: 270.9 MB
Virtual: 3.89 GB
Shared: 28 MB
Private: 137.2 MB
I looked at the list of open files and only saw one media file, which was the one playing. Lots of cache files, but I assume that's normal (maybe 12 or so?).
I've switched to Safari for the next round of testing.
Brian.
-
We're going to try putting a build out that modifies the thread priority. Let us know if it helps once the build goes live.
-
Just had another dropout. Here's the memory stat:
real: 270.9 MB
Virtual: 3.89 GB
Shared: 28 MB
Private: 137.2 MB
I looked at the list of open files and only saw one media file, which was the one playing. Lots of cache files, but I assume that's normal (maybe 12 or so?).
That all seems to be in the realm of normal.
-
We're going to try putting a build out that modifies the thread priority. Let us know if it helps once the build goes live.
Bring it! I'm ready. :)
I've been keeping a log of dropouts, so I've got some pretty good data now.
Brian.
-
blgentry
When you get a drop out have you noticed if the music is still playing in the graphic equaliser window or does this stall also.
Just wondered if i have the same issue or it just appears the same.
-
^ I don't really use the Analyzer window (inside of DSP Studio). Maybe you mean the "dancing bars" display at the top of the window on either side of the song information? I see that for sure.
But my dropouts are *very* brief. The most they ever last is about 2 seconds and that's super long. Usually it's just a small fraction of a second, which you can very easily hear, but unless you are staring at the display, you're not going to see a visual indication.
So, I guess my short answer is "I don't know because I've never been looking at it."
Brian.
-
I now have about 24 hours of logs I've been keeping of dropouts. Here's a sample:
----log-----
5/27 16:28 Pressed Play to resume
5/27 16:40 Dropout. Was saving album art to several albums. Dropout happened 10 seconds into that process.
5/27 17:09 Pressed Pause
5/27 17:21 Pressed Play to resume
5/27 17:46 Pressed Pause
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.
---end log----
These last few were with Safari running instead of Firefox. I can paste the whole log if anyone is really interested.
I'm switching to back Firefox now.
Brian.
-
I now have about 24 hours of logs I've been keeping of dropouts. Here's a sample:
That sure makes it seem like it is disk limited, not RAM or anything else. Where are the files stored?
-
^ OS, JRiver MC, and all media files (with one exception) are on the internal 2.5" 500GB HDD. Not SSD. (Answered this once before, but I understand it's a big thread).
Brian.
-
(Answered this once before, but I understand it's a big thread).
Sorry. Yeah. I knew all the rest, but didn't know where the media files were stored.
Hmmmm... But increasing the Software buffer at Tools > Options > Audio > Audio Device > Device Settings didn't help? Did you go all the way to 500ms?
EDIT: It seems you did.
-
Step by step for me is:
1. Use Mac normally. This includes running Firefox pretty much 24/7 with several windows and tabs.
2. Play music in JRiver MC.
3. Wait for dropouts. They will happen.
JRMark on my system is 2345. I'm not sure where that rates, but this computer seems medium powerful.
Brian.
Dear guys,
I have exactly the same problems. This comes up with the upgrade to Yosemite 10.9.x (I believe x = 5)
Best regards
Joachim
-
Just installed 20.0.112 to test for audio dropouts. Took me a few minutes to get my Custom Resources and Skins linked up, but that's now working properly.
Started playback and less than 1 minute later I got an audio dropout. Darn.
I'm going to continue listening and keeping a log to see if it persists.
Brian.
-
Have you done a thorough search on things like OS problems?
-
I've spent a good number of hours troubleshooting this problem. I've tried giving more resources to the Media Center process using the Unix /OSX renice facility. I've gone through guides from manufacturers of audio hardware and software to optimize for performance. It's mostly pretty easy stuff like turning off Energy Saving settings and things like that.
My searches haven't turned up much that seems applicable to me so far.
I should mention that I frequently watch movies on this same computer and have never experienced an audio dropout that I can remember. Video stuttering from time to time (like a dropped frame), but no audio loss.
Maybe I should do some more research. However, you can see that two other people in this thread are reporting the same (or at least extremely similar) issue, so it wouldn't seem to be something super unique to my setup.
The other Mac users reporting this: What hardware are you using? Mine is:
2011 Macbook Pro 8,2
8 GB RAM
2.0 GHz Quad Core i7
500 GB internal hard drive
Thanks for the help so far from JRiver and others.
Brina.
-
Maybe I should do some more research. However, you can see that two other people in this thread are reporting the same (or at least extremely similar) issue, so it wouldn't seem to be something super unique to my setup.
Yeah. Where there's smoke, there's probably fire.
I think the best hope is this:
We're going to try putting a build out that modifies the thread priority. Let us know if it helps once the build goes live.
Hopefully it comes soon.
-
Yeah. Where there's smoke, there's probably fire.
The fire could be the OS. The problem is odd.
-
I've spent a good number of hours troubleshooting this problem. I've tried giving more resources to the Media Center process using the Unix /OSX renice facility.
If you're making changes at the OS level, please reverse them.
-
If you're making changes at the OS level, please reverse them.
I agree on this. Altering the system nice value is usually useless with complex applications, and sometimes causes trouble. It won't help, for sure, with Media Center, because it spawns a bunch of sub-processes that do almost all of the work, and your alteration will only apply to the "parent" process. This is true with most applications more complex than posix command line utilities.
There are exceptions here and there, but it won't be helpful here, and it can definitely cause other issues (perhaps even exacerbating this, because you're stealing resources for those sub-processes for the mostly-idle parent one).
-
I'm using OS X 10.9.5 "Mavericks", which is the latest version of this branch.
I don't think I've done anything you'd categorize as OS modifications. I've changed an option in energy saving. The renice stuff didn't work, so I abandoned it.
The only even slightly non-standard thing I've done (that I can think of) is to create symbolic links inside of the Media Center app to outside directories and files. One link to a Custom Resources directory so I can use Resource.xml to do key mapping. Then a half dozen symbolic links from the Skins/Standard View directory (inside of the app) to some skins outside.
All of this stuff is still on the same drive. All of it, included the linked files, the OS, the app, and the media on the internal drive. So I don't think these links make any difference.
I'll post more status after I've got several hours of play time accumulated with this .112 build.
Thanks,
Brian.
-
I'm pretty sure this build has made the problem worse. I've had 7 dropouts in about 2 hours. Compared to yesterday I got 3 in 2.5 hours. Here's today's log from when I installed .112 until now.
---log----
5/28 18:20 Installed Media Center 20.0.112
5/28 18:25 Started Playback
5/28 18:26 Dropout.
5/28 18:30 Dropout. 30 MB RAM free. Over 2 GB cache
5/28 18:37 Pressed Pause
5/28 19:03 Pressed Play to resume
5/28 19:03 Within 5 seconds of pressing play, got a dropout. This hasn't happened before that I remember.
5/28 19:38 Pressed Pause
5/28 19:40 Pressed play to resume
5/28 19:53 Pressed Pause. Ran Benchmark.
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 4.916 seconds
Single-threaded floating point math... 3.448 seconds
Multi-threaded integer math... 1.407 seconds
Multi-threaded mixed math... 1.000 seconds
Score: 1764
Running 'Image' benchmark...
Image creation / destruction... 1.305 seconds
Flood filling... 0.578 seconds
Direct copying... 1.203 seconds
Small renders... 1.654 seconds
Bilinear rendering... 1.363 seconds
Bicubic rendering... 0.823 seconds
Score: 3176
Running 'Database' benchmark...
Create database... 0.532 seconds
Populate database... 2.559 seconds
Save database... 0.686 seconds
Reload database... 0.400 seconds
Search database... 1.503 seconds
Sort database... 1.642 seconds
Group database... 1.209 seconds
Score: 2521
JRMark (version 20.0.112): 2487
5/28 20:58 Pressed Play to resume
5/28 21:11 Dropout. 70 MB RAM free. almost 2GB cache. Small read and write spike at the same time.
5/28 21:24 Dropout. Time Machine is doing a backup, so it's touching the disk.
5/28 21:28 Dropout. Media Center was reading while Firefox was writing
5/28 21:55 Pressed Pause
5/28 22:00 Pressed Play to resume
5/28 22:08 Built missing thumbnails on 94 that weren't built yet.
5/28 22:24 Dropout. Longer than usual. Write from launchd and firefox. Read from Media Center
---end log---
Thanks,
Brian.
-
I'll post more status after I've got several hours of play time accumulated with this .112 build.
I hadn't noticed it was out. Sweet. That build has quite a few changes from the old one anyway, a lot of them nice.
If that doesn't seem to help, do the regular troubleshooting things:
Remove everything weird. That means, for science, remove your links, run standard skins, no plugins, no nothing but MC and your Library. Then, if that works, add things one at a time until it breaks.
By the way, hard links will generally perform better than symbolic links. If you happen to find this to be the cause (which is unlikely, but who knows), then hard links will probably be better behaved.
Symbolic links are essentially a redirect. It first opens the Symbolic link, which is a pointer to the "real file".
Hard links are not a redirect. Both filesystem "items" point to the same data on disk. They are both "the file" and are both equally valid, they just happen to point to the same bucket of bits on the hard disk.
Unfortunately, it is tough to hard link to a directory. More:
http://flummox-engineering.blogspot.com/2014/05/creating-directory-hardlinks-on-osx.html
In any case, don't do any of this until you find something that works. For testing, run regular (now, and anytime you're having a weird issue with any application).
-
^ Based on my prior experience I'm pretty confident that my skins and symlinks have nothing to do with this issue. But I'm remaining cooperative. I just re-copied 20.0.112 into the Applications folder, overwriting the earlier one. So my key mappings are gone and only the stock skins are there. I'll run with this for about 2 hours of logged "play time" and see what I get.
Thanks,
Brian.
-
I agree, but you know... The general rule remains. And I've been surprised before.
-
You've said above that it seemed to be related to browser usage. It would be good to prove this one way or the other.
-
You've said above that it seemed to be related to browser usage. It would be good to prove this one way or the other.
He's basically proven that it is related to disk access, not just Firefox, if you read up the thread carefully.
The problem, at the core, is probably just that HFS+ is a steaming pile of fail (http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/), and he's pretty disk limited. Modern versions of OSX are really built for Solid State storage (at least for the OS). This is mainly to hide the concurrency problems inherent in HFS+ which is (now that they've abandoned the wacky discoveryd adventure, it seems) is the main Achilles heel of OSX today.
That would be fine if Apple didn't still sell machines with only spinning disks. But they do.
-
He's basically proven that it is related to disk access, not just Firefox, if you read up the thread carefully.
Antivirus?
-
Regarding the browser: I did try Safari also and found I had the same dropouts occurring. I never just sit at this computer and listen to music only. I'm always doing something else. Unfortunately, I'm not likely to use this computer for just music listening, pretty much ever. So even if i proved it worked well as long as I didn't touch any other programs, that wouldn't be all that useful for *me*, for the way I use my computer. I hope that sounds logical and reasonable.
Regarding disk access and this problem: My whole log tells a little more of the story, but it *mostly* seems disk related. It's hard to type everything I see into the log, but I've definitely had dropouts happen when the disk graph showed pretty much nothing. Also remember that I'm now running firefox with NO DISK CACHE at all. So, in theory Firefox should almost never be touching the hard drive. Other than writing browser history (tiny), cookies (tiny), and new bookmarks (tiny), I'm not sure why it would hit the disk.
Regarding SSD: That might fix my issue; not sure. This machine is an early 2011 and I'm not sure ANY of them came with SSD. Just a data point.
This whole thing is just odd though. My gut feeling is that we are missing something. Because, even though this machine is on the older side, it's not being used in a high performance way. It's not like I'm rendering video, or doing photo editing all the time. Nothing disk intensive. The CPU *sleeps*, and even when I bang on it (ripping DVDs), the machine performs SUPER well. On everything except audio dropouts in JRiver.
Thanks for the continued consideration and help. :)
Brian.
-
The problem, at the core, is probably just that HFS+ is a steaming pile of fail (http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/), and he's pretty disk limited. Modern versions of OSX are really built for Solid State storage (at least for the OS). This is mainly to hide the concurrency problems inherent in HFS+ which is (now that they've abandoned the wacky discoveryd adventure, it seems) is the main Achilles heel of OSX today.
This might be the reason I can't reproduce it as I have OS X installed on an SSD and my music library on an internal HDD formatted to NTFS.
-
Oh and I forgot: Anti-virus. I don't run that on a mac. In *my* opinion no one should. But that's another discussion!
Brian.
-
Playing music is just such a light load on any drive. MC should have no trouble delivering multiple streams.
-
For anyone having this problem, does it change at all if you use memory playback (Options > Audio > Play files from memory instead of disk)?
That cuts the disk I/O out of the loop completely after the first few seconds.
-
blgentry, how are you generating those log files. I'm sitting back waiting to see how you get on with solving this but i'd like to see whats in this file at my end.
If you can say in very easy terms as i'm very new to mac. Many thanks
-
If only I was automatically generating the logs...
I type every character you see there, by hand, as it happens. It's getting a little tiresome, but I really want to fix this, so I'm trying to document it in a way that others can read.
So break out a text editor and start typing if you're crazy like me. :)
Brina.
-
Moved my DAC to a dedicated USB2 port directly on the Macbook Pro.
What is the DAC? Did you test playback to anything else?
-
When the dropout happens does it appear to still be playing (e.g. no sound) or does playback stop completely?
-
Re: DAC. It's a Schiit Audio Modi 2. I've used this with VLC to watch movies quite a bit and gotten no dropouts. Further, I used to not have this DAC and I used the built in sound of the MacBook Pro. I had dropouts with the built in sound too.
Re: Does it keep playing? I'm not sure if the counter is increasing as I hear the momentary dropout, but playback certainly continues after I hear the sound stop briefly. These dropouts are usually much less than 1 second. Occasionally they are 1 to 2 seconds, but 95% of the time it's so fast that you hear it, but you wouldn't be able to see if the counter stopped, even if you were looking at it.
Brian.
-
Hmmmm... I didn't know you were using a third-party DAC. Can you do some additional testing with the built-in audio, just for good measure? And by testing with the built-in audio, I mean DISCONNECT the external USB DAC. If the DAC is misbehaving, it could be causing system interrupts that apply even when it is idle.
Also, do me a solid and fsck (http://wiki.jriver.com/index.php/Troubleshooting_Disks#Filesystem_Corruption).
By the way, not blaming, just trying to narrow down the cause. Before any of that, though, do what Matt asked.
-
Playing music is just such a light load on any drive. MC should have no trouble delivering multiple streams.
I agree. Something is wacky.
To do this, it should not require a SSD. MC can certainly play back audio reliably from slow disks on OSX. Mine are network drives and I've used it with one of those laptop-USB-no-power portable jobs, just a couple weeks ago, for hours and hours without so much as a single hiccup.
And I was mixing in videos at the time. The machine is a 2011 15" Macbook Pro (Sandy Bridge). I did upgrade it to an SSD, but the music was all on a cruddy external USB disk.
-
Re FSCK: I just booted into an external installer disk and ran Disk Utility Repair Disk on Macintosh HD and got two minor repair messages. I'm now booted normally again, listening to MC. I'll log any dropouts.
Re Disconnecting the DAC: I've had dropouts without this DAC in the past. I've only had the DAC for maybe 3 weeks now and I had dropouts before that. If you really have a good reason, I can use the built in sound, but I don't see a logical reason right now.
Re memory playback: I've tried this in the past and it seemed to make the problem worse. It seemed to read the disk an average of twice per song and dropouts *seemed* to happen during those reads. HOWEVER, I'm willing to try again. In fact I will definitely make this my NEXT testing step. I want to run with no other changes than having run Disk Utility Repair and see if I get dropouts. If I *do*, then I'll move to memory playback as the next isolated change. Dutifully logging everything on the way. <whistling like a dwarf, but wishing I was Gandolf instead> (I know, mixed metaphors, but it amuses me in this otherwise not amusing situation!) :)
Thanks,
Brian.
-
Also build 113 was released with another change, I'm interested if it still happens there too. :) I'm hoping it doesn't!
-
Ok, I'm on the latest build (.113) and have experienced 2 dropouts in 17 minutes. To review, here's where I am, with my current configuration:
Firefox running with no disk cache
Time Machine disabled
Running latest build 20.0.113
Enabled Play Files From Memory instead of disk
Recently Repaired main disk from cold/external boot
I guess I'm going to turn play from memory off and keep testing. Either that or move my WHOLE library to an external drive. <shrug> I'm starting to get sort of frustrated.
But I continue to appreciate the attempts to help.
Oh and here's my log since my last report:
---log---
5/28 22:36 Pressed Pause
5/28 22:39 Pressed Play to resume
5/28 22:39 Within 5 or 10 seconds, got a dropout.
5/28 22:50 Pressed Pause
5/28 23:11 Reinstalled 20.0.112 to remove symlinks I added earlier. Will run with included skin.
5/28 23:25 Restarted MC and started playback
5/28 23:44 Dropout.
5/29 00:05 Pressed Pause
5/29 09:19 Disabled Time Machine as a test
5/29 09:24 Pressed Play to resume
5/29 10:02 Dropout. Small read and write spike at the same time
5/29 10:04 Pressed Pause
5/29 17:35 Booted into installer disk and ran Disk Utility Repair Disk on Macintosh HD
5/29 17:43 Started Playback on MC
5/29 18:08 Dropout. Read and write at the same time.
5/29 18:09 Stopped Playback. Set Options > Audio > Play files from memory
5/29 18:10 Started Playback
5/29 18:25 Dropout. This happened when I started the download of the latest Media Center! I'm not counting this one.
5/29 18:37 Pressed Pause
5/29 18:47 Pressed Play to resume
5/29 18:54 Dropout. Playing hi-res (24/96) file. iotop shows read from Media Center and writes from launchd and firefox
5/29 19:01 Stopped playback. Quit MC.
5/29 19:01 Installed 20.0.113
5/29 19:04 Launched MC. Started Playback
5/29 19:07 Dropout. Seconds after song change (16/44.1 FLAC)
5/29 19:21 Dropout.
---end log---
Brian.
-
An idea I forgot to ask about:
Should I enable logging from MC? Then try to correlate the times I get dropouts with the MC log entries? I don't know what's logged or if it would be helpful. Which is why I'm asking. :)
Brian.
-
Re Disconnecting the DAC: I've had dropouts without this DAC in the past. I've only had the DAC for maybe 3 weeks now and I had dropouts before that. If you really have a good reason, I can use the built in sound, but I don't see a logical reason right now.
It would confirm that your memory is correct and eliminate the DAC or its driver as a factor.
-
Ok, trying to be civil...
There is no driver, this is a Mac.
I can take this additional step if you insist.... and I guess I will since now two of you are insisting that I must not be remembering correctly.
Brian.
-
There is always a driver. Software applications talk to software drivers, which talk to hardware.
Nobody is insisting anything. We're just asking you to test things that might rule out possible causes.
-
If you want to be pedantic about it, yes there's a driver. Like there's a driver for the keyboard that's built in to the laptop. What I'm saying is, OS X recognizes this hardware without any driver installation. There are no third party drivers or configuration. It's "driverless" (what Schiit calls it) in OSX. This is because it uses the USB 2.0 audio standard, which is built in to OS X (after some version I can't remember).
I understand you guys are trying to help and I thank you. I've been on your side of the desk too, so I have to remind myself that you don't know me, my capabilities, my technical prowess, my education, or anything. I'm just some dude with a Mac that's got audio issues.
So I followed your and Glynor's directions and switched back to the built-in sound on the Mac and ran for a while. I was starting to wonder at about the 20 minute mark.... and then I got a dropout. I let it roll for about an hour and got 3 dropouts.
I did some poking around on my machine and was reminded that the previous owner of this machine used to have a Digi Designs sound interface (DAC, soundcard, whatever) and it still appears in Audio MIDI Setup. I did a bunch of online research and was able to manually remove every component I could find *including* a kernel extension I didn't know was there. I've since rebooted twice and I can't find any trace of it any more, in the kernel, or in Audio MIDI Setup.
I'm now playing from MC again, through the Schiit Modi 2. It hasn't been very long, but I'm continuing to keep a log. I've got my fingers crossed that the dropouts are over. I'll report back in a while with results.
Brian.
-
I did some poking around on my machine and was reminded that the previous owner of this machine used to have a Digi Designs sound interface (DAC, soundcard, whatever) and it still appears in Audio MIDI Setup. I did a bunch of online research and was able to manually remove every component I could find *including* a kernel extension I didn't know was there. I've since rebooted twice and I can't find any trace of it any more, in the kernel, or in Audio MIDI Setup.
Please post a link or two in case someone else has a similar problem.
-
Here is a page from Avid (the new owner of Digi Designs I think) on how to manually remove their drivers. This isn't even an article; it's just a list of files. It doesn't say so, but what they mean is, "take this list of files, find them on your system, and delete them".
http://avid.force.com/pkb/articles/en_US/how_to/Manually-Uninstall-Avid-Audio-Interface-Driver-Components-Mac-OS-X
It's a PITA; I even tried their uninstaller package for the device that I know was installed here. It didn't do anything; in fact it stopped with an error message.
...and now for the bad news. I continue to get dropouts. <sigh>
I've got a few ideas about what to do next, but I don't like any of them. What do you guys think?
Brian.
-
If you were on Windows, I'd say it's Nuke and Pave time.
If you have a Windows machine, you might substitute it, just to test. You might learn something.
-
"Nuke and Pave". Hahahahaha.
At least something to make me smile in all this. :) :)
I could do the same in OSX: Clean OS install, and then do a Time Machine migration of all my user files. I think there's a bit more to it like re-installing all my apps from scratch. It's a long process either way; like a half day project.
I may end up doing it. I think I'm going to do more testing first. I've got a few more ideas.
Brian.
-
I was going to ask a bit about this too, just as a test...
Do you have a second drive you could boot to and install a clean copy of OSX? If so, I'd do this:
1. Carbon Copy Cloner (or Super Duper) your existing install over to the secondary/external drive. Rename it slightly so you can tell them apart easily.
2. Test it and make sure it boots (hold Option at startup and the Mac will let you choose which drive to boot to).
3. Wipe the regular drive and install a clean copy on the machine without that external/secondary drive connected.
4. Try it out.
5. If it fails, then we can be absolutely, positively sure that something doesn't perform right with your hardware in MC. That rules out everything but the hardware itself.
6. If it succeeds, then we know it is a conflict with something on your install (either something broken, or maybe a software conflict).
7. If it fails, boot to that cloned drive, and test there too. If it works with the cloned drive, then I'd guess you have a bad/dying hard drive.
I'm sorry... I've tried, and I just can't reproduce anything like this on my two Macs, and all of my ideas (and I think Matt and John's ideas) have come up empty. It is baffling.
-
Assuming I wanted to do this test that's going to require many hours of effort...
Wouldn't it skip a lot of steps to just boot straight into a secondary drive with a clean install of OSX, then add MC, and some of my media files? Wouldn't that rule out several things at once?
How about this: What if another player on my hardware can play the exact same files from my media library for some period of time (say 2 hours) without a dropout? That is probably going to be my next test unless someone says the logic is flawed there for some reason.
Brian.
-
Wouldn't it skip a lot of steps to just boot straight into a secondary drive with a clean install of OSX
I suggested the other way around for two reasons:
1. If you do it the way I suggested, and it "fixes" the issue, it tells us two things at once:
* There is nothing wrong with your disk hardware.
* There is something "wrong" (or conflicting) on your existing installation, software wise.
If you do it the other way, it can only tell us the second thing, and not rule in or out the first (and if it still fails, you'd still have to rule out disk trouble).
2. You're not really saving time that way, because if it works, you're going to want to migrate anyway. My way, you're already there. The other way, you have to (unless you have a third disk) do what I suggested anyway, so you can start fresh (because you're going to need somewhere to "stash" your existing install while you build the new one).
How about this: What if another player on my hardware can play the exact same files from my media library for some period of time (say 2 hours) without a dropout? That is probably going to be my next test unless someone says the logic is flawed there for some reason.
I guess I'd assumed you'd already done this, but that doesn't really tell us much, because MC uses the hardware very differently than most other players.
I'd like to emphasize, that I'm not convinced this will help. Like I said above, where there's smoke, there's usually fire. But, we're stumped right now. Plus, this gave me a lot of pause:
and was reminded that the previous owner of this machine used to have a Digi Designs sound interface (DAC, soundcard, whatever) and it still appears in Audio MIDI Setup.
The machine had a previous owner and you're still using their installation?!?
That is... Well, you have no control over (or knowledge of) what chaos might have happened on the machine before it got into your hands. Maybe it went through three "bad" upgrades? For example, how long has that partition been around? OSX has trouble with in-place upgrades sometimes. It is known. Or, what if they'd installed (and partially removed) wacky, troublesome system services or mods in the past?
If I ever buy used hardware, step one is a nuke and pave. Period. No exceptions. Even if the owner is my buddy from IT and I know they probably have something okay. Still not worth it. Start fresh.
So, those two things combined made me suggest it the way I did.
-
Also, the Logs generated by MC might be useful. I didn't answer that because I'm not sure with this issue. I think it is a hardware or data delivery stall, which probably won't be shown in the logs. But, they can't hurt.
It would be especially helpful if you can correlate when the stalls happen to something happening in the Logs in MC. The built-in logs do a lot of latency tracking (basically every entry has a timestamp, and major operations show the total latency of the step).
-
I suggested the other way around for two reasons:
I'd also say, your estimate of time is probably not quite right. Not in "real work" anyway. The clone will take a while, but you can walk away for that part. OSX does clean installs pretty quickly, once you wipe the drive, so getting the new one up and running should be fairly quick.
Then you just have to migrate some media content over, and install MC itself.
Remember, you're not setting up the whole system on the internal drive just the way you "like it". It is a test. If it works, then you can decide to do the rest of that work, but if it doesn't, you clone your old install back over and you're no worse off for the wear.
-
Re another player that works: So you're saying even if another player with the exact same files has zero problems that doesn't tell you anything? I'm not sure I can agree with that. But moving on...
Re reinstallation, cloning, etc: The problem on my 2011 MBP is USB2. I have no firewire drives, so all of this would have to be done across USB2. It has no USB3 ports. It's something like 5.5 hours to clone my drive from internal to external. I'm guessing similar from external to internal should I decide to do that.
Now, to be completely forthcoming, I *do* have a nifty Thunderbolt to USB3 adapter from Kanex. It makes a HUGE difference in transfer speeds. But you can't boot a drive from it! So I can't clone from an external drive on USB3.
...and yes I have a fairly large amount of data on my internal drive (around 430 GB), so it takes a while to move it all.
Oh and regarding why I still have the "original installation". This was the first Mac I got that didn't ship with installation media. It took me a while to learn all the concepts of the recovery partition and all of it's complication. Plus, the whole idea just kinda sucks doesn't it? Download an image of the OS across the freaking Internet when you need to recover?!?? Luckily I have now done the work to build several stand-alone bootable disks, so I at least don't have to deal with downloading the OS image, which would have cost me even more time in this adventure you are suggesting for me!
I'm now at an impasse. Maybe I'll just bite the bullet; but it's a big bullet to bite.
Brian.
-
Brian,
This is becoming argumentative. glynor and others have tried to help. It might be time for you to work on this without their help. Or take a break from it.
My guess is that this will turn out to be something that goes on the Weird Problems thread eventually. That thread might also give you some ideas. There is a link in my signature.
I'm not ruling out an MC problem. It just seems unlikely at this point. If it were a widespread problem, we'd see a lot of complaints.
-
Now, to be completely forthcoming, I *do* have a nifty Thunderbolt to USB3 adapter from Kanex. It makes a HUGE difference in transfer speeds. But you can't boot a drive from it! So I can't clone from an external drive on USB3.
You can use that to clone and just boot it using USB2 if needed. USB3 is backwards compatible with USB2. It'll just run at the slower speed when connected that way.
Either way, it was the suggestion I was mulling around for a while.
By the way, it is easy to make a USB installation drive for OSX on a thumb drive. That's the best way, in almost all cases, to do a clean install. Here's instructions for Mavericks (I think they're identical for Yosemite too):
http://arstechnica.com/apple/2013/10/how-to-make-your-own-bootable-os-x-10-9-mavericks-usb-install-drive/
I'm not ruling out an MC problem. It just seems unlikely at this point. If it were a widespread problem, we'd see a lot of complaints.
There have been a few reports, though. I'm not convinced either way. I just don't have any other good ideas.
We need to find some way to reproduce it, and then solve it.
Re another player that works: So you're saying even if another player with the exact same files has zero problems that doesn't tell you anything? I'm not sure I can agree with that. But moving on...
It certainly doesn't tell us nothing. Trying to replicate it with another player is certainly a valid step, but it is more of a "proves the hardware isn't broken completely" thing. It doesn't necessarily tell us if something in MC itself is broken, because the other application might do things wildly differently.
The problem might not have much to do with the actual music playing part of it. It could be something else (MC updating the Library, and the Library itself is in a "bad" sector of the hard drive) or who knows what else.
The problem on my 2011 MBP is USB2.
That's useful to know. My main laptop is a 2011 15" Macbook Pro as well, and that's the one I've been referring to. It does have 16GB of RAM, and a 1TB SSD, but that's the machine I have, so we're comparing very similar systems if nothing else.
It might be time for you to work on this without their help. Or take a break from it.
I just don't have many other ideas. I'll keep thinking, but if it was me, I'd go with the test I described above. That's the simplest way to rule everything on the old install in or out.
Keep in mind, hard drives do go bad. Especially laptop drives (which take a beating). It is not a case of if, it is a case of when. If that drive is original, then it is due. And, like I said, the problem areas on the drive might be places that MC itself is using, but other applications might not (or the data access patterns, particularly the way MC uses its Library, might not match).
-
Update: I'm pretty sure this is solved.
As requested I did a clean install of my system to the internal disk. Then restored a very minimal configuration of my user account with settings, but no media, and no applications. Then manually installed JRiver MC and restored my music directory. Then added and restored a few must have apps (Firefox, Alfred, iterm).
I've got about 2.5 hours of listening in now and I've had just a couple of glitches and they were super short. In fact, at least 2 I'm not sure where glitches; they were that short. The other two were induced by what I did. One happened when I opened the Browse function in Rename, Move and Copy. This caused some kind of disk load because it made the beach ball appear, indicating a non-responsive application. Little glitch from that and it didn't happen again when I tried it again.
Then I went totally crazy with the browser. I opened dozens of tabs, youtube with a 720p video, and intentionally tried to memory starve the system. I got it to no free memory (which is fairly normally really) and it started driving the disk cache lower and lower. Around 450 MB of cache and no free memory there was one little glitch. I even tried closing Firefox and re-opening it with 8 or 9 windows for it to open, all with a few tabs. In the past, opening Firefox with a bunch of windows for it to load has glitched MC most of the time. This time... nothing.
I have a guess as to what might have been wrong. Menu Meters (http://www.ragingmenace.com/software/menumeters/). I've used Menu Meters since the day I got my first Mac in 2006. They show things like disk activity, network activity, cpu utilization, etc up in the menu bar where you can see it easily. It didn't even occur to me to say anything about them, because they're just always there; they're so familiar to me that it's almost like part of the OS. But I noticed when they were gone!
Because they use low level hooks into the OS and an "undocumented API" (their words), I'm suspicious. Honestly I'm too paranoid right now to try to install them again and prove or disprove them as the cause.
I've got a bunch more data to restore and a good handful of programs to install and/or restore, but I'm going to wait a half day to a day just to be extra sure.
Thanks for sticking with me. If I wasn't quite as quick to jump on every suggestion as you might have liked, especially ones that required hours of effort, I won't apologize. I'll just say thank you. It appears you were right!
I'm happy you were.
Thanks again for all the effort. :)
Brian.
-
I've seen MenuMeters cause other weird issues. Just saying.
If you want something like that, you might want to check out iStat Menus (http://bjango.com/mac/istatmenus/) instead. I know Casey Liss swears by it. In fact, Marco Arment used to use MenuMeters, but has mentioned a few times that he switched to iStat Menus due to issues and bugs in the former. Personally, I'm with John Siracusa (https://overcast.fm/+CdQMq5BI/57:09). It is the Disk Light Observer Effect, and I'm okay without blinking lights and pretty things. I run Activity Monitor in CPU Graph mode in the dock, but that's it. ;)
Of course, it sounds like you're a little with John on the multiple windows (https://overcast.fm/+CdRRhGxw/1:30:17)*. I am too, but nowhere near to the same degree.
* Seriously. Listen to that one if you haven't before. Utterly hysterical and informative. Both of the sections of the show I linked to in this post are fantastic, and I'm sure you'd enjoy them.
-
I really hope the issue is finally resolved for you, Brian. :)
Personally, I use the SysInfo app from the App Store along with the Activity Monitor. But I've also heard good thing about Monity too.
-
Of course, it sounds like you're a little with John on the multiple windows (https://overcast.fm/+CdRRhGxw/1:30:17)*. I am too, but nowhere near to the same degree.
* Seriously. Listen to that one if you haven't before. Utterly hysterical and informative. Both of the sections of the show I linked to in this post are fantastic, and I'm sure you'd enjoy them.
Yeah, I'm a mainly windows guy. I don't know who John is, but I listened to a bunch of that podcast and it was great! He's actually very well considered in his argument and mirrors some of my experiences. He *does* take it to another level though... 30 browser windows with 6 tabs each! Wow. I'll probably listen to a few more episodes; they seem interesting.
Brian.
-
John Siracusa is a PERL programmer who also happens to be the guy who wrote all of the epic Ars Technica OSX reviews up until now (http://hypercritical.co/2015/04/15/os-x-reviewed). He's on that podcast now, but used to host one called Hypercritical (http://5by5.tv/hypercritical), which was also fantastic (and aptly named). I'm a huge fan, and have been since I read my first of his OSX reviews (the public Beta one, I think).
The other two guys on the show are:
* Marco Arment: former CTO (and lead programmer) of tumblr, creator of Instapaper, creator of Overcast.fm, and writes a blog (http://www.marco.org/).
* Casey Liss: Who the hell is Casey (https://soundcloud.com/la-king/accidentially-podcasted)? He works for a SharePoint consultant firm and codes in, yes, C# (and dabbles in Objective-C and node.js), in addition to doing a few podcasts and other stuff (http://www.caseyliss.com/about).
-
Another update: I'm continuing to get dropouts. Not as often as before, but they are definitely there. I've also had MC completely freeze several times now. Let's focus on one at a time.
1. Dropouts. Around once an hour of listening time I get a very short audio interruption. Significantly less than 1 second. Probably 100 to 200 mS. I rewind every time to make sure it's not a bad file. I've had this happen on many files that play fine through the same spot the second time.
2. Freezes. When this happens, All audio ceases. Trying to switch to MC yields no display at all. It just looks like I'm still using the program that was in the foreground (like my web browser or example). In all cases I can remember this has cleared itself within perhaps 5 to 7 seconds. Then the display shows up and audio starts up again at the same spot it left off. Freezes have only happened a few times. Maybe 3 or 4 that I can remember across probably 30 or 40 hours of listening.
Things you don't know about my system yet:
Recently I had a hardware problem with my MBP (which is a 2011 as stated earlier in the thread). Apple fixed it by replacing the logic board, which I gather is essentially the main board of the laptop containing the CPU. The system seems to be running perfectly fine since Apple serviced it.
I've noticed several other people reporting these glitches or dropouts; some in this thread.
Any ideas?
Thanks,
Brian.
-
Bummer.
-
I've noticed that dropouts happen when I'm saving album art to files. I've also noticed that mild disc activity from other apps can induce this behavior. I'm attaching a log file created by JRiver during a drop out that happened during an update to a small application (iterm). This caused some disk writes, but nothing all that dramatic, as the app is small. The update only took like 10 seconds.
I'm going to keep logging enabled and I'll post if I can capture when MC totally freezes like I've reported before.
Maybe I should turn on play files from memory again? To see if I can rule out disk activity as a source of the problem? I think I'll do that now unless someone thinks that's the wrong path.
Brian.
-
Well that was fast. Using memory playback I just got a dropout. It seemed to happen right as I pressed the hot key to switch to Playing Now (I have that mapped because I use it so much). Log attached.
Brian.
-
Been using MC happily for years on a pc, bought a base level mac mini a while back for other stuff, thought I'd try MC, downloaded it last night, made a library of two albums (FLAC 16/44.1) and have bad dropouts and stuttering. Just playing back to headphone socket. Doesn't take much to provoke a burst of drop outs - open a page or two in Safari, browse mail, usual stuff - in no way hammering the machine. Opening an app invariably provokes some clicks. 100ms buffering is bad, 250ms somewhat better but still poor, 50ms no good either. JRMark is 2281. Seems to settle after a while. (Like it's only happened once while I am typing this) but as soon as I switch apps (including to MC itself) I get a click or dropout or several. There's nothing fancy or unusual about my set up. My tiny library is on the macs hard drive, I have a mac bluetooth keyboard, mouse and touchpad and a screen. Only things I've set are integer mode and exclusive access.
Anyone help?
-
Andy, I merged your new thread into this existing one about similar issues.
Your post made me wonder... Brian, are you also using Integer mode? I do not on my Mini at home (because it always worked fine without it and why poke the dragon, you know)...
-
Andy, I merged your new thread into this existing one about similar issues.
Your post made me wonder... Brian, are you also using Integer mode? I do not on my Mini at home (because it always worked fine without it and why poke the dragon, you know)...
(.. now that I've found what happened to my post)
fair enough glynor, but I have to say it's bad enough having drop-outs with a very simple setup but having now to wade through a mammoth thread like this and disentangle questions and answers to me from questions and answers to other people has made things harder for me ..
Buy mac mini. Download MC. Put two albums in library. Play music while doing very little else. Dropouts and clicks. This just should not happen under any circumstances.
-
.. turned off integer mode (which I had set to use with a DAC) .. still got dropouts, though fewer, at 250ms buffering.
-
I tried integer mode a while back and I can't remember exactly what happened, but it didn't work for me. I just tried it again for a test and got silence. I only tested for about 20 seconds, but that was enough for me.
For another data point I *have* now enabled exclusive access. I find exclusive to be sort of inconvenient, but if it helps my situation I'm happy with that. I'll report what I find and/or post JRiver logs.
Brian.
-
Andy,
My audio problems are that the audio disappears for less than one second. Just a momentary silence. I don't get any clicks or loud noises. I mean, it's *sorta* like a click when audio stops and then starts less than a second later... but it's not anything that's loud, obnoxious, or painful. It's really obvious though; as I'm sure you've now experienced.
Brian.
-
Some DACs are troublesome with clicks in certain circumstances:
* When first starting up (or ending) a new audio stream
* When switching formats (between 44.1kHZ and 48kHz, for example)
The setting under Tools > Options > Audio > Settings > Play silence at startup for hardware synchronization is designed to combat these issues. It almost always fixes issues with the former, though the latter is as-often-as-not due to physical relays in the DAC being switched, and is something only the DAC manufacturer can help with (if anyone).
The latter issue is relatively rare, and really only applies to a handful of high-end DACs. The former happens even on my craptastic RealTek onboard audio DAC on one of my systems, but the play silence setting makes short work of it.
Neither of these issues (with clicking) have anything to do with missing audio, though, which I've still never seen. I know the JRiver folks have looked at this a bunch too, and they aren't seeing it there either.
As I said earlier in this thread, though... There's some smoke here, so there's probably some fire. We just have to figure out why it happens to you, but not the rest of us.
-
I tried integer mode a while back and I can't remember exactly what happened, but it didn't work for me. I just tried it again for a test and got silence.
It doesn't work with all hardware. If you're getting silence, you're not supported. It doesn't help anything substantial, so not worth worrying about.
-
I spent a bunch of time researching audio dropouts generally on OSX.
Wow. There's a litany of complaints about it, in all sorts of applications, ranging as far back as 10.3.1! It does look like there are a few things worth checking, though...
1. SMC Reset: Anyone who has this issue, it is worth trying the "catch all" miracle OSX cure: SMC Reset (https://support.apple.com/en-us/HT201295). I found lots of examples of people having similar issues in all manner of applications (VLC, iTunes, web streaming, pro-audio apps, etc) where resetting SMC fixed it like magic.
That makes some kind of sense. SMC controls stuff like power management, idle performance, and stuff like that. It also persists even through clean installs, so if your SMC is borked, it won't be fixed by reinstalling the OS. It only takes a minute, and has very few side-effects.
2. NVRAM Reset: This is a tiny bit more "destructive" (but really not much). Macs store some other system settings in non-volatile PRAM. This actually has specifics about audio hardware (and video performance settings), and I read a number of reports of it helping people with similar issues over the years (and plenty where it didn't). Instructions:
https://support.apple.com/en-us/HT204063
This does reset some things (mostly the system volume settings, and customized Startup Disk settings) so read through the Apple guide, but as long as you don't have a weird dual-boot setup, or very difficult to tweak monitor resolution settings, it should be basically harmless, and could help.
3. Thunderbolt Display: I've seen this myself at work, and I don't know why I didn't think to mention it before. If anyone has a Thunderbolt Display attached to their system... If you can, try it without the Thunderbolt display attached (hopefully it is a laptop) and see if the issue goes away. There have been all sorts of weird issues with Thunderbolt displays, but especially audio issues.
If you're using USB passthrough to connect a DAC to a USB port on the Thunderbolt display, it might help to use a USB port right on the Mac, but this isn't the only issue. There have been firmware updates to the Thunderbolt displays that fix many of these issue, but not all of them (and I think there are just bad ones out there).
We've RMA'd those Thunderbolt displays at work like it is our job. Actually, it is, but... In any case, if you can at all test it without the Thunderbolt Display attached, try it.
4. Outstanding Firmware Updates? There have been firmware updates for a number of Macs, including 2011 Macbook Pros (which I believe is the model Brian is using in this thread), specifically related to audio drop outs and other quality issues.
Make sure you've applied any outstanding Firmware updates. You can check yours here:
https://support.apple.com/en-us/HT201518
It is possible (I've seen it myself) that the updates could no longer show in Software Update under certain conditions. But, if they weren't ever successfully applied, you can manually download them using that article.
5. Pull up the Console monitor: And watch the log messages as they go by. Do you see anything while it happens? In particular, any kernel messages about IOAudioStream?
That could lead to clues, and it seemed that a bunch of people with issues in older OS revisions were seeing this behavior with VLC and iTunes.
6. Repair Disk Permissions: This is a bit of a long-shot, but is worth throwing out there. I mentioned before fsck, but I didn't specifically mention repairing disk permissions. This is usually voodoo, but it basically never hurts, and will almost always find some kind of issue to fix (in my experience). I did, while searching tonight, find a few people who reported similar issues were fixed (again, in other applications) by running permissions repair.
Don't know why that'd be the case, but you never know.
7. AVID Plugin of Evil: This is a super-longshot, but there is an AVID plugin that gets installed with certain codecs and applications that is known to cause audio stuttering and drop-outs under Yosemite. If you have this on your system:
/Library/Audio/Plug-Ins/HAL/Avid CoreAudio.plugin
Copy it elsewhere, reboot, and see if the issue is solved.
Probably only applies to people using pro-audio applications (ProTools and Media Composer), but worth mentioning.
-
Glynor, thanks for doing so much research. I did quite a bit myself and found some other stuff, but some of this was new to me. I'll answer point by point.
1. My motherboard (logic board) was just replaced. I'm assuming this resets everything.
2. See #1
3. I don't use a Thunderbolt display, but I do have a Thunderbolt to USB3 adapter I use. My DAC was on that adapter, but it's directly on the MBP now and has been for several days.
4. Checked the firmware in the link and mine is equal or higher for bootROM and SMC.
5. I did a search for that string in Console and found a few entries that I don't think are related. They all look kinda like this:
6/15/15 6:03:35.000 PM kernel[0]: Sandbox: QuickTime Player(3199) deny iokit-set-properties IOAudioControlValue
6. I repaired disk permissions a while back as part of the T/S process and it didn't make a difference. I did this both with the system live booted and later from a boot installer disk so I could catch the system disk "cold". I could do it again if you say so. The question would be Live booted or cold.
7. I do not have this file.
Thank you again!
Brian.
Brian.
-
A few minutes ago I paused MC, walked away for 5 minutes, and came back. When I pressed my hot key for play I got a spinning beach ball. Activity Monitor said MC was "not responding". I waited about a minute, tried to quit it, then had to force quit it. I'm attaching the log hoping it has a clue.
Brian.
-
It's actually ESPECIALLY worth doing the SMC and NVRAM resets on that, Brian. They should have done so when installing the new motherboard, but... Accidents do happen.
SMC probably would have reset anyway (if power was off long enough), but it doesn't hurt to do it.
NVRAM is non-volatile (hence the name) and will never clear unless done manually. If they didn't remember this step when replacing the logic board? It's in the repair guide, but you know... ::)
Both are likely to not help in your case, but your's is the one I'm most surprised by... I have basically the exact same machine. I played music on it tonight, for 5-6 hours, with nary the tiniest glitch.
-
I'm attaching the log hoping it has a clue.
Nothing in that that stands out. It paused. Logging continued for a while. Then just stopped (when it was force-quit).
Mind if I ask why they replaced the logic board?
The logic board is Apple's euphemism for the motherboard. On a laptop, it often (but not always) includes the CPU, but wouldn't include the RAM, power supply, and other components. Some of the 2011 MBPs were... Notorious for needing new logic boards over and over and over. I think it was mostly due to two problems:
* When you get a "new" logic board, it usually isn't actually new, but one that was factory re-certified.
* The problem lied elsewhere in the first place, and when they don't know what else to do, they replace the logic board.
On yours in particular, since I know some of those machines were... Touchy. You might want to grab this:
https://gfx.io/
It's a simple app. Drop it in your Applications folder and run it. It adds a little icon to your tray (up by the clock) that indicates whether the GPU is in integrated mode, discreet mode, or dynamic mode. Mine works fine in Dynamic mode, but... Since you had the logic board thing, it is worth testing out. Do problems go away if you lock it to one mode or the other (discreet or integrated)?
-
I should add... None of this is to suggest, at all, that there is or isn't a problem with MC. I don't know, and can't really help with that. But, I'm trying to eliminate all other possibilities that I can help with.
Searching for "OSX audio stutter" on Google (and a few other similar keyword searches) and browsing through a few pages of results makes you realize how... This kind of thing can happen for a huge variety of hardware reasons. Of course, Apple Discussion threads and their ilk are often full of half-understood voodoo and red herrings. But, still... There's a LOT of stuff out there.
-
It's actually ESPECIALLY worth doing the SMC and NVRAM resets on that, Brian. They should have done so when installing the new motherboard, but... Accidents do happen.
I'm relatively certain SMC and NVRAM got reset as I had to change back a bunch of minor stuff. But I went ahead and reset both anyway since you suggested it. While I was at it, I booted from an installer disk and ran Disk Utility on my system drive to repair permissions. It found a good handful of stuff, but it seemed like the usual suspects to me (the same stuff I see every time).
I booted up, ran MC, started playing, then ran firefox. Three seconds into starting firefox I got a dropout. <sigh> None since, but that's only been one song so far...
Brian.
-
Mind if I ask why they replaced the logic board?
Sure. About a week ago I got a weird graphics interruption and then my machine rebooted. Subsequently I got a grey screen on every boot. But I could see the spinner and Apple logo during the first part of boot. I booted from external boot media and got to a cool vertical blue bars screen instead!
I thought this was the graphics issue that Apple is covering for these (and similar) machines for free, even though they are out of warranty. But Apple said it wasn't that and replaced the logic board instead. All is well now as far as I can tell. Plus my fans don't run like crazy any more.
On yours in particular, since I know some of those machines were... Touchy. You might want to grab this:
https://gfx.io/
It's a simple app. Drop it in your Applications folder and run it. It adds a little icon to your tray (up by the clock) that indicates whether the GPU is in integrated mode, discreet mode, or dynamic mode. Mine works fine in Dynamic mode, but... Since you had the logic board thing, it is worth testing out. Do problems go away if you lock it to one mode or the other (discreet or integrated)?
I'm not sure what the purpose of that app is. I guess so I could switch to just integrated if I wanted? Since I can turn switching off in the Energy saver. But I've got the app running now just to see it. I'm currently set to Dynamic Switching. I had disabled dynamic about 2 weeks ago during my testing, but before the motherboard replacement. It didn't seem to change anything unfortunately. Disabling switching was one of many tips I read for audio dropouts. I guess I could turn that off again.
Want to trade machines? :P
Brian.
-
I'm not sure what the purpose of that app is. I guess so I could switch to just integrated if I wanted?
Back in the day you couldn't turn off the dynamic switching in System Prefs. But, even now, that app lets you force it to use the Integrated or Discreet one, which is handy.
It will also tell you, if you see it is set to Discreet and you don't know why, which app is preventing it from switching to Integrated. For example, if Lync is running, it is always locked to discreet (because Lync is so awesome).
Which sometimes offers clues (oh yeah, and if you have Lync and wonder why your battery life sucks...)
-
I booted up, ran MC, started playing, then ran firefox. Three seconds into starting firefox I got a dropout. <sigh> None since, but that's only been one song so far...
I'll second the sigh.
Figured it was fruitless, but you never know...
Want to trade machines? :P
HAH. Ummm... No. :P ;D
-
No trade??? Awwww. Oh well. Heh. :)
On a serious note, I just got another full on freeze; not a dropout. I had cleared the log about 10 seconds before the freeze. MC kept playing, then while I was in Firefox reading, the music stopped. I tried to switch to MC and got a beach ball and no MC display. Maybe 7 or 8 seconds later it unfroze, I got the MC screen and audio continued. Attached is the log from the freeze.
Brian.
-
That could be a good one to check, since you got it to unstick!
I'll try to look at it tomorrow. I'm done now and going to bed.
-
To Andy, if you come back to this thread after all this noise. Check out this post:
http://yabb.jriver.com/interact/index.php?topic=97571.msg679143#msg679143
There are a few suggestions. They might help you, even though they didn't for Brian. Same goes for everyone else if you're having this trouble still.
And to Brian, try to keep the Console viewer running. I'm very curious to see what kind of logs there might be in the system when the freezes happen. Unfortunately, it is nigh-impossible to wade through them all after the fact. But, if you can see something happen in the logs that correlates to a freeze or drop out, it could end up being a smoking gun.
-
Through rigorous scientific testing (opening a bunch of tabs in Firefox and shaking the window around the screen) we have been able to consistently reproduce the dropouts on a low-end Mac Mini. We're hoping it's the same dropouts described here. So far, it seems to be a thread priority issue, as using a tool to increase MC's priority reduced the dropouts significantly. In build 112, this was introduced:
4. Changed: Increased audio feeder thread to real-time priority to hopefully address audio skipping issues some users are experiencing. Please report results.
We'll see if there is anymore work to do there. Thanks for all the info!
-
Adam, I can't speak for the others in this thread, but I know Brian has been testing builds since 112 and is still having frequent issues.
So, unless you had a typo there and made more adjustments on an as-yet unreleased build, I think there's more work to be done...
-
OK, well heres what Ive found ...
I did the turn off, unplug, count to 15 stuff. Possibly (and I'm being generous) it improved things a bit, but not much. Can I make some points that, unlike others on this thread,
I am not using a DAC, just the headphone socket. (Though I would like to use a DAC).
My mac mini is the base model, bought a few months ago, no mods, additions or trickery.
Easiest way to make it happen is play something in MC, then fire off apps. As they come to life there will be clicks, dropouts, pauses, scratches. Starting Google earth and Photos seems particularly good at provoking them. But they will happen anyway - did just now when I was scrolling down this page.
It is MC. I used MC to convert my 2 cds big library to ALAC (during which I got two drop-outs), put that into iTunes, played, fired off every app I own and there were no audible issues at all.
Integer mode or not makes not much different. Buffering does. 250ms is best, but still unusable. (Though to be fair, my threshold of unusable would be one click).
Over to you guys. If you have the ability to log into my machine remotely, or have some tests I can do that will help, or whatever you are welcome.
Edited to add: I just edited a typo in this and got another click!
PS: and another when I closed an Excel window (with nothing in it)
-
Adam, I can't speak for the others in this thread, but I know Brian has been testing builds since 112 and is still having frequent issues.
So, unless you had a typo there and made more adjustments on an as-yet unreleased build, I think there's more work to be done...
Correct. Since people using that build are still experiencing problems, and it seems to be a thread priority issue, we're thinking we'll have to make changes to how that was implemented. The feedback is helping us narrow in on the problem. It would be interesting if someone wanted to try increasing the priority of MC (use a number like -10) (http://superuser.com/a/296915) and report any changes.
-
^ I tried re-nicing MC quite some time ago before I tried everything else in this thread. But that's been a long time ago, so I just tried it again. I've now got it set to -10, confirmed by the PS listing.
It's too soon to be sure, but so far it seems good. I've even done some mildly abusive stuff with MC running and gotten no dropouts. Like writing a 10GB file to the tmp folder. In the past those types of things induced dropouts. Here's hoping. :)
BTW, what did you mean about "shaking windows on the screen"? Literally grabbing the title bar and moving the window left, right, up, down fast? If so that's pretty crazy. ...and it doesn't do anything on my system. <shrug>
Brian.
-
If it's working at -10, perhaps you should try increasing (or in this case decreasing) the number until if/when you find one where the dropouts begin to occur at - it might help find a threshold.
-
BTW, what did you mean about "shaking windows on the screen"? Literally grabbing the title bar and moving the window left, right, up, down fast? If so that's pretty crazy. ...and it doesn't do anything on my system.
The only machine we can reliably reproduce it on is very low powered one, so it doesn't take much. On the i7, it happens so infrequently that it's hard to test. Hopefully by eliminating it on this one, it won't be a problem on other machines.
Thanks for testing!
-
I hate to say anything after this amount of testing but...
I think I have 3 to 4 hours of play time on this configuration now. I got one teeny dropout (that I'm not even certain about) very early on in testing this. For the last 30 or 40 minutes I've been doing increasingly unreasonable things with my browser. Loading a good number of pages with multiple flash instances on them. Opening 15 tabs in some windows. Then youtube. Then CNN.
At some point I started opening other apps to see how hard I could push it. At the point that I had a ton of browser windows, two video apps (not playing), Apple maps, and then opened ibooks, I finally got *one* dropout I'm sure of. But this was a COMPLETELY unreasonable load for the machine. The browser was slowed down. Even switching from application to application was slower than usual. I hammered the machine.
I really don't want to say it again but... I think this is solved.
Now I need to do a little more testing with a normal load and *then* figure out if it's just the re-nice of -10 that did it, or if the 4 other audio parameters I set have had any impact. For the record: Play from memory, exclusive access, decreased prebuffering, and increased hardware buffering.
Thanks Adam! I had abandoned the re-niceing because it didn't seem to work the first time. So glad you suggested it!!
Brian.
-
I haven't got a clue what reniceing is or means or how to do it. Or what the other suggested settings are. If someone can tell me how to try this simply, I'll happily see whether it fixes this issue on my mac.
-
I haven't got a clue what reniceing is or means or how to do it. Or what the other suggested settings are. If someone can tell me how to try this simply, I'll happily see whether it fixes this issue on my mac.
+1. No apparent issues for me yet, but I would like to understand what all of this means. I am new to MC & trying to learn as much as possible about how things work.
-
+1. No apparent issues for me yet, but I would like to understand what all of this means. I am new to MC & trying to learn as much as possible about how things work.
I believe this is an Apple question, rather than a JRiver question. You might try an Internet search.
-
Briefly about OSX "nice level". In Unix and OSX you can tell a process "be nice to other processes". This means for that process (program or app) to take less resources (CPU) so the others can run effectively. You can also tell a process to be "not nice", which means to take MORE resources. Setting the nice level is called "re-nicing".
I've built a little one liner script that you can run to set the nice level of Media Center to negative 10 (-10), which makes Media Center the highest priority, or the "least nice". You'll need to cut and paste this command *exactly* into Terminal and then press enter. It will ask for your admin password because setting priority in this way is a privileged task that requires administrator access. If you don't trust my command, please don't run it. Here's the command:
sudo renice -10 `ps -laxw |grep -i "Media Center" |grep -v grep |awk '{print $2}'`
Brian.
-
You shouldn't need to be that extreme (-10). The OS should normally be able to handle priorities well. MC doesn't need to be "real time".
-
Always nice to see Unix commands in threads ;D
Blgentry, I don't have a mac to test (so this might not be good advice), but with many ps implementations (including GNU ps), if you pipe "ps -e" (instead of "-laxw"), the grep itself doesn't show up in the results, so you could omit your second grep (although you might need to adjust your awk).
Alternatively, you can typically grep "[M]edia Center" instead of "Media Center", and it will still find the real process, but trick grep into not finding itself.
-
I believe this is an Apple question, rather than a JRiver question. You might try an Internet search.
Sorry, I am confused. Are you saying that to fix this issue I have to fiddle around with my Mac in some way because it is Apples fault? Or will there be a new release of MC that is not susceptible to the problem?
-
Briefly about OSX "nice level". In Unix and OSX you can tell a process "be nice to other processes". This means for that process (program or app) to take less resources (CPU) so the others can run effectively. You can also tell a process to be "not nice", which means to take MORE resources. Setting the nice level is called "re-nicing".
I've built a little one liner script that you can run to set the nice level of Media Center to negative 10 (-10), which makes Media Center the highest priority, or the "least nice". You'll need to cut and paste this command *exactly* into Terminal and then press enter. It will ask for your admin password because setting priority in this way is a privileged task that requires administrator access. If you don't trust my command, please don't run it. Here's the command:
sudo renice -10 `ps -laxw |grep -i "Media Center" |grep -v grep |awk '{print $2}'`
Brian.
I'm sorry, I can't understand any of this. What's Terminal for a start? Why do you choose 10 when immediately following your post someone from JRiver disagrees with you? Why should MC need to be set to the highest priority? Are you saying that I am wrong to expect a base level Mac Mini to work with MC? Why doesn't iTunes need gobbledegook like this to play a bit of music out of the headphone socket?
-
We don't completely understand what is going on, but there is a very good chance that is the OS that is causing the problem. Try an Internet search for Terminal and OSX.
-
We don't completely understand what is going on, but there is a very good chance that is the OS that is causing the problem. Try an Internet search for Terminal and OSX.
OK, I have just googled "Terminal OS X"
This is what came up:
As a terminal emulator, the application provides text-based access to the operating system, in contrast to the mostly graphical nature of the user experience of OS X, by providing a command line interface to the operating system when used in conjunction with a Unix shell, such as bash.
Terminal (OS X) - Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Terminal_(OS_X)
Feedback
Terminal (OS X) - Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Terminal_(OS_X)
As a terminal emulator, the application provides text-based access to the operating system, in contrast to the mostly graphical nature of the user experience of OS X, by providing a command line interface to the operating system when used in conjunction with a Unix shell, such as bash.
Introduction to the Mac OS X Command Line - Treehouse Blog
blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line
Sep 27, 2012 - This is a command line tutorial primarily conducted in in the OS X command line. Learning to code means being comfortable in Terminal for OS ...
iTerm2 - Mac OS Terminal Replacement
https://www.iterm2.com/
iTerm2 is a replacement for Terminal and the successor to iTerm.
Downloads - Features - Documentation - ITerm2 2.0 released
Eight Terminal Utilities Every OS X Command Line User ...
lifehacker.com/eight-terminal-utilities-every-os-x-command-line-user-s-...
Jun 23, 2014 - The OS X Terminal opens up a world of powerful UNIX utilities and scripts. If you're migrating from Linux, you'll find many familiar commands work the way you expect.As a terminal emulator, the application provides text-based access to the operating system, in contrast to the mostly graphical nature of the user experience of OS X, by providing a command line interface to the operating system when used in conjunction with a Unix shell, such as bash.
Terminal (OS X) - Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Terminal_(OS_X)
Feedback
Terminal (OS X) - Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Terminal_(OS_X)
As a terminal emulator, the application provides text-based access to the operating system, in contrast to the mostly graphical nature of the user experience of OS X, by providing a command line interface to the operating system when used in conjunction with a Unix shell, such as bash.
Introduction to the Mac OS X Command Line - Treehouse Blog
blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line
Sep 27, 2012 - This is a command line tutorial primarily conducted in in the OS X command line. Learning to code means being comfortable in Terminal for OS ...
iTerm2 - Mac OS Terminal Replacement
https://www.iterm2.com/
iTerm2 is a replacement for Terminal and the successor to iTerm.
Downloads - Features - Documentation - ITerm2 2.0 released
Eight Terminal Utilities Every OS X Command Line User ...
lifehacker.com/eight-terminal-utilities-every-os-x-command-line-user-s-...
Jun 23, 2014 - The OS X Terminal opens up a world of powerful UNIX utilities and scripts. If you're migrating from Linux, you'll find many familiar commands work the way you expect.
I am sorry, but I just can't understand stuff like that. I am sorry I am not as clever as you in your field of expertise.
If you can help me directly, ideally by fixing MC, I would appreciate it.
-
It is probably not an MC fix. Start terminal and poke around a little. It gives you a shell, like DOS.
At a $ prompt, type ls
cd .. goes up
cd [directory name] goes down into that directory.
pwd means print working directory.
Unix uses forward slashes rather than back slashes. cd / goes to the root directory.
The command you were given above can be entered at a $ prompt.
I agree it's silly that you might have to do this, but I don't think this is a problem with MC.
-
Hi Andy
Im a total noob in Mac but i will try to help in easy terms. But please others correct me if im wrong
If you open finder which is an icon on that bottom bar on the home screen. If you then open applications which is in the left column, then on the right there is a folder called utilities. In here you will find an application called Terminal. If you double click it it will open a windows pretty much like a CMD DOS box in windows if you are familiar with that.
I think if you type cd / into the terminal window this takes you too the top of the root directory. You can then type in or copy and past the script posted by blgentry.
Have a look and see how you get on. It really not that difficult just a bit daunting
-
No apparent issues for me yet...
I guess I spoke too soon as I just encountered my first playback issue with MC20. I have been using MC20 for about two weeks, still in trial period. Playback just stopped for several seconds before starting again. Not sure if the indicator was still moving or not as by the time I got to the computer, the music started again. I am using a Mac mini (late 2012), 16 GB RAM, OS X 10.9.5, no other applications were running except Activity Monitor, computer is dedicated to music playback and files are on an external HD connected via Firewire 800. Using USB output to an Ayre QB-9DSD, integer mode and exclusive control set.
-
Foxman50 - thanks for your help .. I'm just way out of my comfort zone and understanding, so thanks but I don't want to go any further with stuff like this. I've spent a fair bit of time trying to help and give the guys a JRiver some clues about the problem, it's over to them really. If they can get it sorted within my trial period I'll happily give a new release a go. If it's Apple's problem though there's nothing much I can do.
-
I agree it's silly that you might have to do this, but I don't think this is a problem with MC.
I'm sorry, Jim, but I have to disagree. I understand that it might be challenging to find the right balance, and it could be due to bugginess in CoreAudio. But, the central point is:
You sell a Mac application that plays audio. On some currently shipping Macs, it (apparently) cannot reliably play audio.
The users who have this issue, have other OSX applications that play audio, and none of them seem to have this issue. I, myself, don't happen to suffer from the issue, but I have a TON of high-end Mac applications that play audio and don't have this issue. Even many, many, many simultaneous streams, while doing way harder processing at the same time.
It is something about how MC is interacting with the OS. So, it may very well be that you're hitting a bug in CoreAudio, but your choices are to find another way, or to stop supporting affected Macs (which seems to include currently shipping configurations). We're not just talking about ultra-low-end machines, I don't think. Asking users to implement manual process priority changes is entirely unreasonable (especially since they won't persist), and obviously the "real answer" is to not use MC if you're impacted.
That all said, I think Adam has some ideas about how to proceed. He wanted users to test changing the nice value. It was not intended to be a solution.
Brian, I think it might be useful for Adam to see how low with the nice value you can go before you start to get stutters regularly. Don't load the system up crazy style (I can make iTunes stutter too if I try to encode video and peg the CPU simultaneously), but do a useful real-world test. See if -7 works. If so, -6. And so on and so forth.
Then they might be able to set it closer to a useful default.
-
Foxman50 - thanks for your help .. I'm just way out of my comfort zone and understanding, so thanks but I don't want to go any further with stuff like this.
I think that's reasonable. If you aren't comfortable on the command line, you aren't really equipped to help here. There are some GUI applications that you can use to set process priority, but none of the decent ones are super simple applications.
If anyone is really dedicated to help, atMonitor is a nice process manager for OSX that can do this on running applications:
http://www.atpurpose.com/atMonitor/
Crap. I still have an old version. It is discontinued. You could try this, which is also discontinued, but still available for download:
http://www.eosgarden.com/en/freeware/process-renicer/overview/
Also, I'd like to add that I suspect that using renice to "fix" the issue is a bit of a "hammer" approach. The core issue is that there is some interaction between the way MC uses CoreAudio that is causing performance issues in some cases. Perhaps the buffering scheme or something isn't exactly completely Mac friendly?
Not sure, obviously, but I suspect that setting the process priority isn't "fixing" the issue, but hiding it. But, why also is it not impacting everyone? Under what circumstances does it crop up (other than very low-powered machines)?
I think if we could answer that, it would be a big clue. A current-gen Mac Mini, even the low end model, is still a fairy powerful machine. So if it impacts that, why doesn't it impact my 4-year-old Macbook Pro?
-
Brian, I think it might be useful for Adam to see how low with the nice value you can go before you start to get stutters regularly. Don't load the system up crazy style (I can make iTunes stutter too if I try to encode video and peg the CPU simultaneously), but do a useful real-world test. See if -7 works. If so, -6. And so on and so forth.
Today I was trying to isolate the other settings (audio device buffering, etc) from the renice setting. I think I have enough time testing to be sure that the renice setting is the only thing affecting performance for me.
With that in mind, I'm going to do a binary search algorithm to find the threshold of the renice setting. I've just gone from -10 to -5. I'll try to do several hours of play time at this setting, then move to another setting depending on results. I'll report back as I get more data. ...and yes, I'll try to be normal, rather than trying to break it on purpose. :)
Brian.
-
Just to add my own 2¢…
I call these types of events 'hiccups'.
Just small seemingly innocuous perturbations in the flow of the music.
The momentary 'pause' in the playback stream started a ways back for me and I noticed and posted to that effect at the time. And no I don't remember when this was, but I noted it in the bug reporting thread at the time.
Another 'hiccup' is the change in SQ after the amount of ram continues to climb and it seems like when it becomes 1.5 times (or greater) than the initial ram load.
This Ram 'creep' is not a matter of running out out of ram, nor of resource limitation (I too use Menu Master).
After a re-start or cold boot (I use a power controller so I remove power to the Mac), in effect I've been doing a SMC reset and have in the past 'Zapped my PRAM' on more than one occasion.
Anyway, I was thinking it was something in the USB chain I use but that others are also noticing these behaviors tends to tell me it's not an external hardware induced problem.
JJ
-
glynor,
I moved your post for Adam.
Jim
-
Just downloaded Audirvana + and installed it with the same 2 CD library I have for MC. Worked absolutely perfectly out of the box. Fired off every app I have and tried to use them all. No drop-outs, clicks, funny noises whatsover. All settings left at defaults.
-
It's difficult to be very sure about the data because it requires so much listening for each test. But here's where I am:
Nice -10, I've gotten no dropouts under normal conditions, even pushing pretty hard.
Nice -5, normal and a little pushing, no dropouts. About 2.5 hours listening time.
Nice -2, one dropout after just over 2 hours of listening.
I'm currently testing nice level -3 to see what I get. The question is, did I test long enough at each stage? Not sure. But I'm continuing on; trying to help. If this testing isn't helping, please let me know. I'm willing to do it for sure, but it's not exactly fun. :)
Brian.
-
I've tested at nice level -3 for roughly 2.5 to 2.6 hours with no dropouts and part of that time I pushed the system a bit. On this system I'd say a nice level of -3 to -5 is probably going to be rock solid until you start really resource starving the machine.
If Adam, Glynor, or anyone else wants further testing let me know. Otherwise I'm done testing nice levels.
Thanks,
Brian.
-
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...
-
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.
-
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
-
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.
-
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.
-
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?
-
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.
-
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.
-
Brian: Have you tried disabling App Nap for MC (http://www.maclife.com/article/howtos/easy_mac_hacks_disable_app_nap)?
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.
-
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.
-
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 (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... :)
-
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.
-
Brian, the AppNap stuff I mentioned above might be relevant. Easily tested.
-
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.
-
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.
-
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.
-
Why is there no "Prevent App Nap" check box in the Get Info window?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (http://wiki.jriver.com/index.php/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).
-
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?
-
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.
-
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.
-
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.
-
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.
-
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!
-
^ 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.
-
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!
-
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.
-
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.
-
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.
-
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.
-
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.
-
Thanks, Adam. Hope to turn this on tonight after I uninstall SoundFlower.
-
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.
-
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!
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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!
-
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??
-
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
-
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.
-
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.
-
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:
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.
-
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:
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.
-
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
-
Has anyone experiencing this problem tried disabling Media Network? If not, please try disabling it and reporting back. Thanks.
-
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.
-
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.
-
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.
-
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?
-
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.
-
.. 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.
-
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.
-
I do not have this problem, using 112 version, only 124 and 126.
I think that it is not OS or hardware problem.
-
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.
-
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.
-
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
-
It is. Thanks.
-
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.
-
I'd happily bet you a beer that it is this:
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:
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. ;D
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.
-
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.
-
Haven't got a Mac here (Well, I've got a PowerMac G3, but that's not much help :P ), 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-
-
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.
-
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-
-
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.
-
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?....
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.
-
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-
-
Thanks, Leezer.
-
...
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.
-
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-
-
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)?
-
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).
-
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.
-
Thanks for the report.
-
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.
-
My bet wasn't with you, though I like beer, so if you show up here, I'm still happy to buy you one. ;D
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
-
That about this bug in MC21? :)
-
My bet wasn't with you, though I like beer, so if you show up here, I'm still happy to buy you one. ;D
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. :)
-
Are you playing from a CD drive?
-
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.
-
OK. This is why I said that:
Started MC, it had found my four test cds.
-
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:
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...
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). ;D
-
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.
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.
-
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.
-
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.
-
Or an older version?
-
Or an older version?
Thought so too, but the log says the correct version (126).
-
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.
-
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.
-
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. ;D
I'm just trying to help.
-
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:
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:
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.
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.
---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?
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....
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.
-
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 (http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/):
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.
-
Actually, the concurrency limitations bring up an interesting point.
Adam, is it possible that MC's various threads are trying to hit the disks on OSX more concurrently than is necessary for writes? For example, when saving tag changes, do you try to do this to multiple files simultaneously (with multiple threads)?
Do multiple threads try to write to disks at the same time for other purposes (maybe saving Library changes in one thread, and updating the file tags in another thread, simultaneously)? If so, is it possible these threads come from different processes and are queuing "on top of one another"? Reads shouldn't really matter, but writes lock the whole filesystem on OSX, so I can see them fighting with one another if you're trying to do them concurrently.
This might explain why Brian is still seeing those drops when saving cover art. If all of his stuff is on a single volume (Library and media files) and it is a relatively slow, spinning-disk-based volume, he's already "close to the edge" with random write performance... Concurrency of HFS+ sucks and so you get badness if you're trying to optimize writes assuming the filesystem isn't so dumb (as NTFS is not). Keep in mind, those locks are global. Meaning, even across multiple volumes, no two processes can write to the filesystem on a Mac at the same moment, ever, anywhere.
OSX uses a big, honking global lock object that has to be enabled and disabled before and after every write. Horrifying, but that's the way HFS+ works.
That would also explain why using my copies of MC on my Macs are unaffected. I have a pure-SSD drive in my Macbook (which is otherwise pretty much identical to Brian's), and a Fusion drive on my Mini. His are all spinning disks, I believe.
-
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?
I've just started testing this now. I'll want to have several hours of "normal" testing, plus a torture test or two. Then I'll report back.
As for the rest of the message: I have one normal 2.5" internal drive (spinning disk) in my MBP. MC's library and all media files are on that disk. The album art that I save periodically is being written internally to FLAC files. So one write per song file. If it's a big album that might mean 30 or more writes. I normally stick to art that's around 500x500, so usually less than 200kb; pretty small.
Brian.
-
I've just started testing this now. I'll want to have several hours of "normal" testing, plus a torture test or two. Then I'll report back.
Cool.
I normally stick to art that's around 500x500, so usually less than 200kb; pretty small.
Ok, so nothing extreme there. Just figured it was worth checking.
So one write per song file. If it's a big album that might mean 30 or more writes.
It is actually two writes per file, one to the file and the other to the Library. That's what I'm wondering if is what is happening. If MC does the Library writes in a different thread from the file writes, while simultaneously playing from a third location, it might be thrashing your disk a bit. This, alone, shouldn't really be enough to cause issues, but with other system stuff going on too in the background, and the two MC threads contending with themselves over the write?
I don't know. I'm totally guessing. It is entirely possible that MC does those writes serially (update files, then update Library). But if not, with the global lock limit of HFS+, combined with a slow 2.5" laptop drive, and maybe MC's writing patterns aren't really optimized for the way HFS+ has to write...? Could explain that last case, perhaps.
-
I'm grateful for everyone's work on this issue, and I sincerely hope it can be further improved or fixed before MC20 is put to bed. My symptoms seem very similar to Andy's. When the Mac is busy, dropouts are more likely. I've also found that rapidly moving the volume slider (I use internal volume) exacerbates the problem ie helps cause them. I can also cause them at will by opening many apps at once. My normal use is MC plus a few apps, notably firefox with 20-50 tabs.
My system is different, but similar in that it's i5. 2012 mac mini i5 with 10G RAM, apps on 500G internal HD, and music on 3TB My Book connected via USB and running OS 10.9.5 latest. Doesn't that make it less likely to be an OS problem? I also think earlier version of MC had fewer dropouts. My file types are aiff and flac, but I can also get dropouts from radioparadise at 192k. It does seems that higher bitrates are slightly more prone to dropouts, but I can't tell for sure. Is it possible that raw horsepower helps others avoid this and i5 mavs are more prone to it? Should we start a new thread calling all i5 and i7 users to report on their systems, use, and dropouts while under heavy load? This would give a better idea of how widespread the problem may or may not be. Does JRiver have an i5 to test with?
I ran some of the tests that glynor suggested and got interesting results. Made all these changes one at a time with no effect until noted. Disabled media network share, set SW buffer 250ms, disabled app nap, turned off integer mode, and rebooted here and there for good measure. Then set HW buffer to max and bingo! It greatly reduced the dropouts. When opening 12 apps, that process was much much faster. Before it was maybe a minute to open 6, and now with HW at Max, all 12 were open before I could test MC.
Then I backtracked, one at a time. Somewhere (I think after enabling app nap) I got some periodic clicking sound that almost sounded like a scratch in a record. At some point it went away and I'm having trouble reproducing it. I then reenabled integer and got about 5% music 95% dropouts. Further testing seems to indicate that integer mode is incompatible with HW Max on my system, and it's 100% reproducible. Can anyone replicate the difference in app start times HW buffer Max or the incompatibility between integer mode and HW buffer Max?? I assume my next steps would be to get you a log file and then rename the ini file to go back to default, right? Anything else I should try, maybe earlier versions of MC?
-
New development. I went back to verify this behavior and somehow got the "partial sound" problem, where only 5% or maybe 10 or 20% of sound comes thru, in repeated bursts, but this time, it was at full volume!
I'm using internal volume (with max volume of 88) so my Bel canto DAC/preamp is set to max volume. I hope my speakers are ok, it was quite shocking at 300W. I think the setting was going from hw Max to HW recommended. In the course of further testing (with the DAC volume at 50 to be safe), this symptom kept happening until I disabled integer mode.
More testing and it seems that integer mode now causes the partial sound problem regardless of other settings. I guess I really do need to to try the ini default test. BTW, all the previous testing was done with DSP on (parametric EQ 2 filters set) and volume leveling. Turning those off didn't cure the full volume partial sound, when it was still happening. Is it possible that all tweaking you've done has made internal volume and/or volume protection intermittent?
-
I did have logging turned on, and found lots of "Core audio is asking for more data than we have available?" messages. Hope this helps. Unfortunately, it does not include the episode where I got partial sound (more dropouts than music) at full volume. The later parts of the log do include the partial sound problem with normal volume when integer mode is enabled. I plan to revert to defaults tomorrow and do more testing unless I receive other advice. I'm also wondering about the suitability of Mac to high performance audio in light of this and the general trend in Mac OS towards less and less control by the user.
-
When you captured the log, did you have Integer mode enabled?
Integer mode is only compatible with certain DACs, and is the kind of thing that either works, or it doesn't. It doesn't improve quality in any way, so if it doesn't work, don't worry about it and keep it disabled.
-
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.
Blgentry, could you talk just a bit more about your procedure for saving album art? I've reread the thread and noticed it's been one of the only ways this problem is readily reproducible. We've set up a system on a spinning disk and are hoping to reproduce it. Does it cause dropouts every time? I've tried grabbing cover art from the internet and updating tags from library, but haven't heard any dropouts yet.
Thanks again for your excellent testing.
-
Blgentry, could you talk just a bit more about your procedure for saving album art?
Sure. I think I'm doing it in a very similar way to your description below:
1. Select a whole album from Albums view.
2. Right click. Cover Art > Get From Internet....
3. Find the art I want. Sometimes takes me a minute or so to decide.
4. Save Cover art.
Every now and then I can't find the art I want and I add it from an external file instead (Cover Art > Add From File ...), which I generally put in the same directory as the files.
Usually, if it's going to drop out because of this, it happens within 30 seconds. It's usually pretty quick. Occasionally I see the "saving tag information" in the status area at the bottom for as much as a minute or so.
I've reread the thread and noticed it's been one of the only ways this problem is readily reproducible. We've set up a system on a spinning disk and are hoping to reproduce it. Does it cause dropouts every time? I've tried grabbing cover art from the internet and updating tags from library, but haven't heard any dropouts yet.
It doesn't happen every time. Maybe every 2nd or 3rd time? Maybe? I haven't kept track, though I have tried to note it in my log when it does happen. I just checked my log and I have 3 instances of dropouts when saving album art and one instance of a dropout after editing tags on a full album.
As for reproducibility, my memory chewer was VERY consistent in producing dropouts until I set the App Nap disable toggle. I would get dropouts every 30 seconds to 5 minutes using the chewer.
Thanks again for your excellent testing.
Thank you to all of you guys also. Adam in particular your "fresh set of eyes" has been helpful. I don't know how much testing is going on behind the scenes or from how many people, but I really do appreciate it. :)
Brian.
-
Ok, per Glynor's request, I've been testing with Media Network enabled, but my other two changes enabled:
1. Software Buffering set to 250 mS
2. App Nap disabled specifically for MC with the command line
I have about 7:15 of play time on this configuration. I've gotten 2 unforced dropouts. That is, dropouts during normal every day use of my computer while playing music.
I got seemingly *more* dropouts while torture testing it. Here's my log of the torture testing:
---------------------
6/25 17:10 Re-enabled Media Network to see if it influences dropout behavior. Restarted MC.
6/25 17:11 Play
6/25 17:19 Running memory chewer
6/25 17:28 Complete Freeze of MC for about 8 seconds. No sound. Interface not visible. After freeze sound returned and interface visible again.
6/25 17:38 Dropout. 2 quick ones in a row.
6/25 17:40 Killing memory chewer. Dropout. I had gotten a beachball or two in firefox during this test. System seemed slowed, but not as bad as the previous test.
6/25 17:42 Starting a bunch of apps.
6/25 17:43 4 dropouts in a row. Another.
6/25 17:45 All apps up. Quit all test apps.
6/25 17:47 Launching 6 or 7 different apps.
6/25 17:47 Dropout.
6/25 17:48 All apps up. Quitting all test apps.
6/25 18:08 Pause
It's hard to say if that's correlated to the Media Network being enabled or not. What I say for sure is that under normal use conditions it seems very similar. 2 dropouts in a little over 7 hours is a bit better than my last test, which was 3 dropouts in around 6 hours. Very similar numbers.
I think Glynor now wanted me to increase Software Buffering to 500 mS. I'm going to try that now and report back after another 5 to 7 hours of listening time.
Brian.
-
Quick check, do you have "Put hard drives to sleep when possible" enabled in Energy Saver? I assume you don't, but I wanted to make sure.
-
^ I run with the MBP plugged into the charger more than 99% of the time. Energy Saver for plugged in does NOT have put disks to sleep enabled. Energy Saver for on Battery, has it checked, but again, I'm almost never on Battery.
BTW, my testing with Buffering=500mS is going very well so far. :)
Brian.
-
Integer mode started working after I did a POR. I was able to reproduce the partial sound problem when HW buf max and integer mode were on together, regardless of which was turned on first. I could've sworn I'd tried restarting MC and a soft restart of the mac mini when I first encountered this problem, and none of that worked. But now, I see that restarting either MC or the Mac will clear the issue, and let me run integer mode as long as hw buf is not set to max. I guess I need to choose between them, but I'd prefer to use both. Is this expected behavior? glynor and I will have to agree to disagree on whether things like integer mode can affect the sound. ;) I'm also considering getting an SSD, but I may just wait to see if a new mac mini is released this fall. I'm thinking more horsepower is good thing after this issue.
The dropouts are more likely right after start up while the system is settling down. I'll try starting MC from defaults another night. Thanks for your efforts...
-
I have the same 'dropout' problems.
They occur randomly.
System:
MacMini late 2012 i7
16gb RAM
latest jriver
OS X 10.10.4
1TB hard disk
External USB 3 drive Seagate 2TB
Playback from RAM
different iterations of jriver have not made any difference - started using jriver from February.
DAC iFI micro
Dropouts happen when just playing back music files - so very light CPU load.
Thoughts/ suggestions?
-
Latest results:
I've been testing with build 20.0.126 with the following "changes" to the default configuration:
1. Audio Buffering Hardware: Hardware Default
2. Audio Buffering Software: 500 mS
3. Disabled App Nap with command line provided earlier in this thread.
4. Media Network enabled.
I have right at 7 hours of play time on this configuration. I'll cut right to the chase: In normal playback I have had NO DROPOUTS with this configuration. Now that's with "normal" use. Read on for my torture testing results.
First I tried the "let's fire up lots of big programs" torture test. Here's my log:
7/29 10:45 Play
7/29 10:46 Starting up a bunch of apps
7/29 10:47 All apps up. No drops.
7/29 10:48 Killing all test apps
7/29 10:49 Starting several other larger apps not started yet this session
7/29 10:51 All apps up. No drops.
7/29 10:53 Keeping big apps open. Opening heavy web sites in Firefox
7/29 11:03 free RAM=0 cache=560MB No drops so far. This is where it should get starved and cause problems. Going to open some tabs in Safari while keeping everything else open.
7/29 11:06 System very unresponsive. Long pauses switching apps. No drops. Cache=394MB
7/29 11:14 System became responsive again a minute or two later. Continuing to work with Safari and Firefox. free RAM=0 cache=400MB
7/29 11:26 Not a single drop. Killing all test apps now
7/29 11:28 All test apps dead.
7/29 11:29 Pause
Great! No dropouts. Ok, let's really hurt the system with the memory chewer. Log:
7/29 16:26 Play
7/29 16:29 Running memory chewer.
7/29 16:31 free RAM=0 cache=375MB . If problems are going to happen this is past the trigger threshold.
7/29 16:42 Dropout. Had opened several new windows in Firefox trying to starve memory. System slowed noticeably.
7/29 16:50 Killing memory chewer. System slowed a bit as it died but no dropouts
7/29 16:54 Pause
That's approximately what happened with the last configuration: One dropout after more than 10 minutes of running the chewer. You may recall that before making these changes the chewer induced dropouts every 30 seconds to 5 minutes. So this is a big improvement.
Overall, I'm calling this "zero unforced dropouts" in 7 hours. Awesome.
I'm going to continue testing; not sure if I'll continue logging because it's a PITA. But I'm paranoid about this, so maybe....
Thanks,
Brian.
-
Additional testing:
Playback using iTunes results in similar dropouts - both when using output to USB/ DAC or HDMI to TV.
Further thoughts?
-
When you captured the log, did you have Integer mode enabled?
Integer mode is only compatible with certain DACs, and is the kind of thing that either works, or it doesn't. It doesn't improve quality in any way, so if it doesn't work, don't worry about it and keep it disabled.
Just curious what is the point of having integer mode then?
Other players I have tried in the past have shown an improvement in SQ when it is enabled, I thought it bypassed any core audio OSX processes.
-
I've now done between 10 and 12 hours of play time testing with the current configuration. A short time ago I had my first dropout during normal listening. I wasn't doing anything unusual; just listening and web browsing. There was a little bit of free RAM and about 1.1 GB of cache; so not memory constrained.
This is SO much better than before, but it would be nice to eliminate it. It's psychologically rather jarring for the music to drop, which is kind of the opposite of the reason I play music. I listen to music to feel good, not stressed. :)
Thanks everyone.
Brian.
-
Just curious what is the point of having integer mode then?
Other players I have tried in the past have shown an improvement in SQ when it is enabled, I thought it bypassed any core audio OSX processes.
Matt explains what Integer mode does here:
http://yabb.jriver.com/interact/index.php?topic=84657.0
The important bits are:
Technical Considerations
Both playback methods are bit-perfect, and bit-perfect methods sound the same (http://wiki.jriver.com/index.php/Bit-perfect_Audio).
Integer mode is slightly more efficient since it removes an additional conversion and pushes less memory through the core audio subsystem.
How other players behave isn't relevant, because many of them will not have their own fully-implemented 64-bit internal audio processing engine like MC does, and actually use the DSPs built into Core Audio. MC does not, it only uses Core Audio to talk to the audio device (like a dumb pipe), and does volume control and DSP internally using its own high-quality engine.
The difference is that "standard" playback (non-Integer mode) requires Core Audio to perform a mathematical conversion before the audio is sent to the DAC (in some, but not all cases, this depends on the DAC in question). This mathematical conversion is not lossy (it can be "perfectly reversed") but it isn't efficient to do needless conversions (that's why it requires more memory).
It is, at best, an esoteric distinction.
-
Just thought I'd check back here. Tried the latest version of MC on my newish base-level mac mini. Still get a dozen or so drop outs in a matter of minutes when playing music and firing off apps (and then closing them again as the clicks start).
Is there anything new to try? Can someone help?
-
Hi Andy,
This thread has gotten really long, and it's difficult to try to reconstruct what each of us has tried and has changed on our systems. Sorry if I ask questions you've already answered.
We've had a number of people recently have clicks and pops that aren't actually dropouts. Most of these seem to have been caused by the Hardware Buffering setting:
Tools > Options > Audio > Audio Device > Device Settings > Buffering > Hardware
If yours is set to "Maximum (recommended)", try setting it to "Hardware Default" instead.
If that doesn't work, I can only tell you what has worked for me to minimize the issue. I'm still getting dropouts, but they are very infrequent now. I get one every 10 to 12 hours of listening time. So one every couple of days depending on how long I listen each day. I would like to eliminate them altogether, but this is much MUCH better than before.
Brian.
-
Thanks bigentry - tried that, alas barely different. Possibly a couple fewer drop-outs, but then the second time through my test run I often get fewer anyway. As it stands, I couldn't entrust my music replay to a base level mac mini running MC. One drop out when I was listening seriously would be too many. Not to worry, my mac mini was bought for other duties. Pity though.
-
I have just tried streaming 16/44.1 from Qobuz, firing off the usual apps, and got 1 dropout as opposed to the dozen or so I consistently get with MC. So, Audirvana+ works fine, iTunes works fine, streaming cd quality from Qobuz nearly works fine but MC doesn't.
Edited to add: Just repeated the test with Qobuz and got no dropouts.