The audio just glitched & dropped to silence a couple of days after the app
was launched 'by hand' rather than via launchd, so I guess that rules out
the thread priorities… *sigh* ;p

(The app runs the music in a bar/nightclub, hence why the Mac was running
for a couple of days)

*Michael*
07595247282

On 26 Dec 2015, at 23:10, Michael McNeela <[email protected]> wrote:

OK, what about the audio realtime thread (during playback). It should be
running at pri 97 -- is this true while the glitches are happening?


It’s indeed at 97 for both type of launch, but …the glitches tend to take a
few hours/days of running to present themselves (!), so I’ll just try
ditching launchd for a few days & see if the random glitching disappears
(that’s how that attached ’things I’ve tried' matrix came to be :p)

(Thanks for the push in the potentially-right direction by the way!)

*Michael*
+447595247282

On 26 Dec 2015, at 22:52, Doug Wyatt <[email protected]> wrote:

OK, what about the audio realtime thread (during playback). It should be
running at pri 97 -- is this true while the glitches are happening?

Doug

# sent from my iPhone

On Dec 26, 2015, at 14:40, Michael McNeela <[email protected]> wrote:

Hey Doug

Your matrix makes me wonder: are you trying to play from a launchd daemon?


Yep; a launchd LaunchAgents daemon (i.e. not running as root)

Try taking an Instruments trace that captures thread scheduling activity.
It sounds like the daemon is in a throttled state, which would show in a
kernel or Instruments trace as having its threads running at a very low
priority.


A short ~5 second trace seems to show the *main thread* via launchd
consistently at priority 31, vs the main thread via ‘double-click to open’
at priority 46-47. (All other threads seem to have the same priorities
regardless of how the app’s launched though)

*Michael*
+447595247282

On 26 Dec 2015, at 18:34, Doug Wyatt <[email protected]> wrote:

Hi Michael,

Your matrix makes me wonder: are you trying to play from a launchd daemon?

Try taking an Instruments trace that captures thread scheduling activity.
It sounds like the daemon is in a throttled state, which would show in a
kernel or Instruments trace as having its threads running at a very low
priority.

Doug



On Dec 26, 2015, at 10:11 , Michael McNeela <[email protected]> wrote:

Should you be curious, here’s what I’ve tried narrowing down so far;

<Screen Shot 2015-12-26 at 18.06.39 copy.jpeg>

*Michael*
07595247282

On 26 Dec 2015, at 16:55, Michael McNeela <[email protected]> wrote:

On 26 Dec 2015, at 16:48, Cyril Blanc <[email protected]> wrote:

Where are your video files ?


On the internal SSD

What Mac do you use ?


A late 2014 Mac mini (Macmini7,1), factory-configured to 2.6 GHz i5, 8GB
RAM, 256GB SSD. The issue presents itself on three Macs of the same
hardware configuration (bought & configured at roughly the same time),
across 10.10.3, 10.10.5 and 10.11. I’m puzzled.

*Michael*
07595247282

On 26 Dec 2015, at 16:50, Michael McNeela <[email protected]> wrote:

Thanks for the input everybody. I should clarify that I’m simply playing
regular ol’ video files using Cocoa’s AVPlayer; nothing spectacular, and
the video playback continues unaffected as the audio stutters and drops.
It’s incredibly odd.

Oh, and audio is being outputted through the Mac’s headphone port; not
external audio interface via USB/FireWire, etc.

I’ve stopped SSH attempts bumping the CPU, just in case they were related,
but the issue persists, so now I’m at a loss.

*Michael*
07595247282
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to