That points away from thread scheduling issues.
Hmm okay
What is the audio output hardware?
Just the Mac mini's built-in audio hardware (analog audio comes out via the headphone port to the venue's amplifiers)
After your app fails, can audio play from other apps?
Yep; I managed to dart to the Mac & launch VLC one time after my app's sound dropped & it played audio fine, while my app's video continued in silence behind VLC
What do you have to do to be able to play again? Restart your app? Restart the system?
Either wait for the next video to start (i.e. giving AVPlayer a new AVPlayerItem, once the glitched-to-silence video finishes), or restart the app That points away from thread scheduling issues.
Dropping to silence could indicate a NaN made it into some signal processing code somewhere ... What is the audio output hardware? After your app fails, can audio play from other apps? What do you have to do to be able to play again? Restart your app? Restart the system?
Regards, Doug On Dec 31, 2015, at 10:22 , Michael McNeela < email@hidden> wrote:
Hey Kyle
How are you actually playing data? Are you generating sample data
yourself (even if it's something as simple as mixing)? What does your
threading model look like?
I'm just giving Cocoa's high-level AVPlayerItems to AVPlayer to play (H264+AAC MP4 videos); no low-level audio code… On Wed, Dec 30, 2015, at 10:33 AM, Michael McNeela wrote: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
Well, you could still be in a priority inversion situation, where thehigh-priority audio rendering thread is being starved by alower-priority thread that is failing to fill up a ring buffer withsamples. (For example, a decoder running on a background thread.)How are you actually playing data? Are you generating sample datayourself (even if it's something as simple as mixing)? What does yourthreading model look like?--Kyle Sluder
(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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden> wrote:
On 26 Dec 2015, at 16:48, Cyril Blanc <email@hidden>
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@hidden> 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
|