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 *Michael* +447595247282 On 31 Dec 2015, at 20:52, Doug Wyatt <[email protected]> wrote: 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]> 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]> 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]
