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 protected]> 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… > > Michael > 07595247282 > > On 31 Dec 2015, at 17:32, Kyle Sluder <[email protected] > <mailto:[email protected]>> wrote: > >> 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 the >> high-priority audio rendering thread is being starved by a >> lower-priority thread that is failing to fill up a ring buffer with >> samples. (For example, a decoder running on a background thread.) >> >> 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? >> >> --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 protected] >>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[email protected]>> wrote: >>> >>> On 26 Dec 2015, at 16:48, Cyril Blanc <[email protected] >>> <mailto:[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] >>> <mailto:[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]
