Print

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

[glynor]

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.

[blgentry]

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.

[glynor]

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.

[danfl75]

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?

[danfl75]

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?

[danfl75]

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.

[glynor]

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.

[adamt]

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]

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.

[blgentry]

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:

Code: [Select]

---------------------

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.

[adamt]

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.

[blgentry]

^ 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.

[danfl75]

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...

[wouterk]

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?

[blgentry]

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:

Code: [Select]

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:

Code: [Select]

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.

[wouterk]

Additional testing:
Playback using iTunes results in similar dropouts - both when using output to USB/ DAC or HDMI to TV.
Further thoughts?

[muzzer]

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.

[blgentry]

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.

[glynor]

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.

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.

[AndyU]

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?

[blgentry]

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.

[AndyU]

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.

[AndyU]

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.