I need to be able to capture sound from an application and send it over to another application. It looks like Apple keeps tweaking the sound libraries and finally under 10.9 both Soundflower and Jack stopped working. I started looking for sample code and it feels like Apple is deprecating making kext-based audio drivers — the corresponding sample code is gone from the site.

However! There is a new code sample AudioDriverExample that worked for me. Check out the SimpleAudio part of the project. It provides a driver that reads data into one buffer and writes data out from another buffer. Replace the input buffer pointer with the output buffer pointer and you get yourself a decent virtual audio driver similar to Soundflower.

You may have to fix a bug in SA_Device.cpp in SA_Device::Stream_SetPropertyData:

ThrowIf(theNewFormat->mFormatFlags != (kAudioFormatFlagIsFloat | kAudioFormatFlagsNativeEndian | kAudioFormatFlagIsPacked), CAException(kAudioDeviceUnsupportedFormatError), "SA_Device::Stream_SetPropertyData: unsupported format flags for kAudioStreamPropertyPhysicalFormat");

replace kAudioFormatFlagIsFloat with kAudioFormatFlagIsSignedInteger.


Reading ZEVO forums at I ran into a nifty way to solve most of ZFS-over-AFP-sharing problems. To recap: I have a few zfs systems defined on my server pool. When I enable file sharing, only some of those systems show up as volumes on the network.  There seems to be no clear indicator of why some systems do show up as volumes so users can connect to them and others do not. Form reading comments around the web it looks like Apple is now hardcoding some HFS file system properties into the software, which delegates alternative files systems to the role of second-class citizens and breaks functionality (including AFP sharing) for them. Bad Apple.

The solution is to trick the AFP server into believing that every file system it sees is HFS: a small library I installed on the server and now all volumes show up in AFP network browser on the client machine.

I spent a weekend trying to get a client machine to automount a volume from the server via samba. I need three users on the client to be able to access (read/write) files on the server. I want to preserve the information about the file creator, so each user has his/her own login credentials for the server, — I don’t want to have just one user login for everyone. I need the volume to be mounted three times, each time for a different user with different login credentials. I need the mount point to well-defined — your traditional “connect to server” in Finder does not work to well, it uses /Volumes as the mount location and then names each new volume mount sequentially, e.g., Media, Media1, Media2, etc.

One solution that looked promising is to automount the volume into each of the users home directory under the user’s server login credentials. That volume would look like another folder with all files owned by the user. I looked over the autofs guide and created a direct map file that looked like this:

/Users/user1/Media -fstype=smbfs,soft ://user1:pwd1@server.local/Media
/Users/user2/Media -fstype=smbfs,soft ://user2:pwd2@server.local/Media
/Users/user3/Media -fstype=smbfs,soft ://user3:pwd3@server.local/Media

It looked like it was supposed to work. And it worked. For two users. For the third one, the mounted directory assumed root ownership and was unaccessible. I relaunched automount a few times and suddenly all three users can access their respective Media folders. I rebooted the client machine, now users 2 and 3 can see, mount, and use the folders, but user1 could not. I spent most of the day trying to figure out why the mounting was so unstable. Finally, I gave up on this approach.

My current solution, the one that seems to work reliably, is to create an indirect map for every user into a hidden folder somewhere on the startup disk

sudo mkdir /UsersVolumes
sudo chflags hidden /UsersVolumes

add this to /etc/auto_master

/UsersVolumes my_indirect_map -nosuid

and then /etc/my_indirect_map looks like

user1 \
     /Media -fstype=smbfs,soft ://user1:pwd1@server.local/Media

user2 \
     /Media -fstype=smbfs,soft ://user2:pwd2@server.local/Media

user3 \
     /Media -fstype=smbfs,soft ://user3:pwd3@server.local/Media

I also put a soft link in every user’s home folder to the appropriate Media folder.

cd /Users/user1
ln -s /UserVolumes/user1/Media
chmod -h 0700 Media

The last line should ensure that only user1 will be able to access the link and trigger the mount.

It is useful to have a mail server running on the server machine. For example, the S.M.A.R.T. monitoring daemon can let me know when a problem occurs with one of the disks. Here is very detailed guide on how to setup the postfix.

Setting up the server so files created on a share are always readable (and writeable) by a group proved to be a bit tricky. Lion clients tend to create files that are only accessible by the user who created them. It works well for private folders, but creates problems for common shares like media archives. If one user saves a photo on the common share another user cannot access it even if they are bot in the same group. So here are the steps to share the share:

  1. assign a common group to the share: sudo chgrp -R media /Volumes/Media
  2. set group suit bit on the directory, so files created in the directory have the required group ownership: sudo chmod g+s /Volumes/Media
  3. set ACL for the media group to allow reading and writing on the share and set the inheritance to files, folders, and descendants. You can it from a command line, I used Sandbox a free tool by Michael Watson.
  4. propagate the ACL permission down the share subtree. Use Sandbox.
  5. enable ACL for samba shares: sudo defaults write /Library/Preferences/SystemConfiguration/ AclsEnabled -bool YES

The new samba file sharing in Lion (and in Mountain Lion) breaks things sometime. I have a zfs drive that I’m sharing using samba from Lion and a strange thing is happening: I cannot see the share from the command line on another machine:

> mount -t smbfs '//user:pwd@server.local/Media' /Users/user/Media
mount_smbfs: server rejected the connection: Authentication error

However, if I go to the server, disable and enable file sharing, everything works as expected. I traced the problem to a race condition during the server OS startup. Apparently, file sharing starts up before some security configuration is finalized, so when I try to mount the share, the server fails to correctly authenticate the request (I see errors in kdc.log: NTLM domain not configured). If I restart the file sharing, all the prerequisites are in place and authentication succeeds. I added a small startup script to /Library/LaunchDaemons that restarts smbd after the system is done loading:

cat >
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
        <string>sleep 60;touch "/Library/Preferences/SystemConfiguration/"</string>

Update: Do not forget to change the owner of the file to root and change the permissions:

sudo chown root:wheel
sudo chmod 0644

It will ask you for an administrator password.