Why are these void* not id?  And why are they in a private array, while the other ivars have names?

Do you need to free _dev? 

Is this meant to be a singleton?  If so, you should implement a +sharedInstance method and (optionally) override +alloc to make sure that only one is ever created.

Test for failure.  See the Étoilé SUPERINIT macro.

-playBytes:length: would be a more explanatory name for this method.

Remove extraneous space between function name and open bracket.

Creating this as a variable, rather than using NSMakeRange() directly makes the code less readable here (it looks like you will be using the range somewhere else).

Can you put this in a loadable bundle?  Since we have equivalent but more general functionality in Étoilé's MediaKit, we'll probably want to just use that, so we get support for pretty much everything via libavformat.

Test for failure.  This is non-idiomatic, breaking the designated initialiser pattern.  If -initWithData: is the designated initialiser then -init should call it and it should call [super init], not [self init].  

You probably want to be using NSCondition here.  It should be committed soon, when Gregory finally finishes reviewing my code...

Don't explicitly give a size when initialising arrays unless you have good reason to.  Your sizes look quite random.

Uh, why are you copying the arrays here, and if there's a good reason for it why are you copying them like this rather than with -copy?

This repeated locking and unlocking is far from ideal.  Consider copying the lockless ring buffer from MediaKit.  Or wait; there's an improved version waiting to be committed until Gregory commits my NSCondition patch...

If you really want to use ivars like this (which is ugly and provides no benefit), consider adding macros like this:

#define readLock ((NSConditionLock*)_private[2])

This test is redundant.  Messages sent to nil are silently ignored.  This test is duplicated in objc_msg_lookup().

Do you need to test whether the delegate responds to that selector?

This RELEASE() looks unbalanced.  Where is the corresponding -retain that it balances?  If it is in the other thread (I think it is?) where is the locking to ensure that these happen in the right order?

This will crash in multithreaded code where you set the name of one sound while freeing another.  You need a lock around nameDict.

If this line is ever reached, you have a double-release bug.  self is retained when it is added to nameDict.  If it is dealloc'd while an object has retained it, then there is a serious problem.

Missing call to [super init];

Cast to void* is never needed.  Any object can be implicitly cast to void*.  See your copy of the C standard.

Send the message to isa instead of NSSound; it's faster and it plays nicer with subclasses.

Pasteboard types are horrible.  There are lots of different names with the same meaning.  You probably need to test for a few of them.

I'm fairly sure that's not how you are meant to use NSConditionLock...

I'm fairly sure -tryLock is not what you mean here either. 

You need to retain then autorelease this sound.  Otherwise it can become invalid if you change its name (in another thread, or in this one).

Lock nameDict.

Not needed.  self must always be retained by the caller.  If this is causing self to be released in other bits of your code, then you have bugs elsewhere.  Please fix them, rather than adding hacks that leak memory to prevent crashes.

Really pedantic; 'plays with the device' rather than 'plays to the device'