Playback stability of r901

[sbooth]

In r901 the way Play handles audio internally completely changed to allow for Audio Unit effects. One poster here has reported skipping when the disk comes under heavy load. Can those using r901 post their experience of the playback stability in the latest unstable version so I can get a feeling if this is an isolated incident or a large problem?

[egotrippen]

Using r901, I experienced some skipping while running an install of Windows XP in Parallels, however other programs (Safari, etc.) were lagging as well so it's probably nothing to worry about.

However, I am getting a more worrying skip when extracting .rar files with MacPAR Deluxe and running a video conversion with QTAmateur. It's not exactly a light load, but none of my other programs seem affected.

My music library, the movie file (source and destination) and the .rar file (source and destination) are all on the same firewire external harddrive.

[andys]

Hi, I posted the initial comment about Play skipping under load. As not many seem to be having the same issue it occurred to me that it may be the way that I'm using the application - that is, I have it pushing the sound through Airfoil to an Airport Express. This is actually the only way I use Play. Having just tested Play running standalone through my laptop speakers while putting the system under the sort of load that previously produced skipping (Adobe Lightroom was always a good one) I'm unable to reproduce the problem. The sound is unaffected.

It appears that it must be something happening outside of Play. That said the same thing doesn't happen to iTunes or Cog - they push sound out to Airfoil while the system is under heavy load without any skipping..

[denis]

I experience a lot of skipping. The files I play are located on a network share (a NAS) that I have tried mounting via both SMB/CIFS and SSH via MacFUSE. Both variants of mapping result in a lot of skipping. I can play back the same files on a WinXP box attached to the LAN in exactly the same way without skipping at all. I tried playing back both FLAC and mp3s to make sure it was not the increased bitrate of the FLACs that caused the skips.

Actually, would it be possible to expose some buffer settings somewhere in Play? If I could set the playback buffer to be quite big I could work around most issues regarding the poor network share performance of OSX.

My machine is a Santa Rosa MBP 2,4GHz, and the load when I experience skipping is not very high.

[sbooth]

A question for those having problems with r901 skipping: did the previous stable release (0.1.2) exhibit the same problems?

[denis]

Yes, I did install the stable at first, and it had the same (or worse) problems.

[sbooth]

Yes, I did install the stable at first, and it had the same (or worse) problems.

Well, that actually makes me happy, because it means I didn't introduce any new bugs with the new audio engine.

Does this thread have any relevance to your issue? You said that SMB gave sporadic skips as well as AFP? What kind of machine are the files hosted on?

Finally, one more question. In the console log do you see any log entries from Play prefixed with AudioScheduler error? If any audio scheduled by Play doesn't start rendering when it is supposed to, a message is logged.

[denis]

I have now been able to check this out at home again (where the troublesome NAS is). When running Play from iTerm I do not get any errors dumped that relate to the dropouts.. Here is all the output I get from starting up, and playing through a song. I got multiple short dropouts here, and one that lasted several seconds.

Code: Select all

macbookpro:~ denis$ /Applications/Play.app/Contents/MacOS/Play 
2007-08-07 21:51:39.857 Play[19772] Bad _contents: nan
2007-08-07 21:51:39.857 Play[19772] Bad _contents: nan

Can I enable more debugging output somehow? Is there any way to increase the buffers for network playback?

If by AFP you mean "Appletalk" (it's what my NAS software call it) yes; I've had the same problems while using that, SMB and SSHFS (via MacFUSE). I'll add in that this does not only happen in Play, it does happen with iTunes as well.

The "machine" / NAS is a Thecus N2100 NAS, a linux based RAID1 device that has been measured to handle around 13Mbit/sec by independent testers (so it is a slow box, but it should work well for music streaming).

[andys]

That's all I've seen in the console log too. Also, it wasn't generated by Play skipping as the date stamps were from quite a bit earlier.

[sbooth]

Can I enable more debugging output somehow? Is there any way to increase the buffers for network playback?

The best way to get more debug output would be to use a Debug build (all builds posted on the Play site are Release builds). Do you have Xcode so you could compile it yourself, or do you need me to post a Debug build? There really isn't a way to enable debugging output except at compile time.

As far as buffers go, by default Play uses 10 slices each consisting of 2048 frames, where a frame is one sample across all channels. So for typical 44.1 kHz audio, that equates to approximately 0.464 seconds of buffered audio. Granted, that buffer is broken in 10 sections of 0.04 seconds. Currently both parameters are set at compile time- so if you had the ability to build Play and tweak them yourself that would be ideal. Making them user-configurable is also an option, but I'm not sure if this is necessary.

[denis]

Hi, I got and installed Xcode, but I seem to need subversion to check out the current revision. It would be quicker for me I guess if you could either post a tarball of the source, point me towards an easy way to install svn on osx, or alternatively post a debug build (but that would not give me the opportunity to alter the buffer settings of course).

[denis]

I found some svn packages and I'll go ahead to try and build the source myself. If that fails somehow I'll report back.

[denis]

Xcode is churning away on trunk as I write this, however if you could explain how/where to alter the buffer settings, that would be great. I'll try and find out myself of course.

[sbooth]

In the file AudioScheduler.m in the Audio Player group, go to line 36:

Code: Select all

// ========================================
// Buffer parameters
// ========================================
#define NUMBER_OF_SLICES_IN_BUFFER		10
#define FRAMES_PER_SLICE				2048

Hopefully the #defines are self-explanatory.

[denis]

Here are the relevant errors from the debug build, each line corresponds to a detectable dropout while playing:

Code: Select all

2007-08-09 23:05:00.624 Play[10806] -audioSchedulerStartedRenderingRegion: 01. Blue Planet Corporation - Apex.flac (4096, 24576)
2007-08-09 23:05:10.028 Play[10806] AudioScheduler error: kScheduledAudioSliceFlag_BeganToRenderLate (starting sample 417792)
2007-08-09 23:05:21.220 Play[10806] AudioScheduler error: kScheduledAudioSliceFlag_BeganToRenderLate (starting sample 911360)
2007-08-09 23:05:32.179 Play[10806] AudioScheduler error: kScheduledAudioSliceFlag_BeganToRenderLate (starting sample 1394688)
2007-08-09 23:05:44.532 Play[10806] AudioScheduler error: kScheduledAudioSliceFlag_BeganToRenderLate (starting sample 1939456)

I'll try and muck about with the slice settings and see what happens.