[CM] MOTU srate problem; .aifc file type; pops and clicks using sndplay in OS X

[Jake Rundall]

Hi,

Three questions/problems today:

1. srate problem when playing files in clm-3 through MOTU

When I try to play files (in OS X) using dac/sndplay in clm-3 and do it through 
my MOTU (mk I), the MOTU only plays back stuff at 96 kHz as the srate.  I've got 
the latest driver for the MOTU.  Also, the MOTU cooperates with QuickTime and 
iTunes and all of that stuff, so it seems that it's not a problem with the MOTU.  
But, no matter what srate I write the file at, when I play it back in clm, the MOTU 
switches it's displayed srate to 48 kHz and then plays it back as if it were 
playing at twice that (96 kHz).  It's strange, because the MOTU mk I is not even 
supposed to play things at 96 kHz, just at 48 and 44.1, so I don't know what's 
happening.  I think Rick Taube is having a similar problem with his M-Audio 
boxes, so I don't think it's an issue only with MOTUs, but with firewire audio 
interfaces in general.  So, I'm curious what the problem is and why clm doesn't 
seem to cooperate with my firewire interface.  Luckily, I've found a solution, but 
this leads to another question.  I'll describe this all next.

2. paplay, and .aifc header-type

I've often used Apple's QuickTime Player to play back files written in clm, but I 
couldn't get it to handle 4-channel .aiff files (even though QuickTime is 
supposed to play back up to 24 channels -- I just don't know what types of files 
it is actually capable of handling...).  So, I looked for a while and found a 
command-line audio file player called paplay that is in a set of programs called 
the Multi-Channel ToolKit (mctools), created by Richard Dobson in the UK.  It's 
available at http://www.bath.ac.uk/~masrwd/mctools.html.  paplay cooperates 
well with my MOTU (no sampling rate miscommunication) and opens multi-
channel .aiff files and even plays them correctly.  The catch is, when I run with-
sound to write the files, I have to specify "header-type: mus-aiff".  It seems that 
the default file header for clm is .aifc (compressed).  I was wondering why this is 
-- does clm actually write compressed files as a default?  Would it be better to 
use an .aiff header as the default?  Luckily, as long as I tell clm to write a .aiff 
header, the paplay program is happy.

3. pops and clicks when using sndplay

This whole exploration reminded me of another general issue I've had with 
sndplay.  Ever since I've been using clm (a little over a year only), I've found that 
I get pops and clicks when I use dac/sndplay to play back my files.  Because of 
this, I almost always ended up playing back my files using QuickTime and there 
were no problems with pops and clicks.  Now that I've set paplay (mentioned 
above in #2) as *clm-player*, I can play back my files in clm using dac and I 
don't have the problem either, so it would seem that the problem is specifically 
with sndplay (and probably with the way it works in OS X).  Anyway, I'm very 
glad to have found a solution, but I'd like to be able to use sndplay to play back 
my files at some point.  Also, I may not be the only person out there 
experiencing pops and clicks while using sndplay in OS X, so I wonder if 
something could be improved on (maybe by looking at how paplay plays files or 
something).

I'd love to hear what other folks have to say and if there are any explanations for 
what I've been experiencing.

Thanks,

Jake Rundall