Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Streaming OS X audio over network
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Streaming OS X audio over network

On Thursday, January 22, 2004, at 08:08 AM, Tim Hollingsworth wrote:

If I read you well, you want to grab the audio at the output of you Mac and broadcast it to some receivers in the network.

You could write a "user space" AudioDriver based on the AudioHardwarePlugin API. The Mac OSX Jack team has developed such a driver, based on a prototype from Stefan Werner. Matt Ingalls has announced on this list a virtual AudioDriver (Soundflower) whose sources - not yet available - should be a good starting point too. The plugin shows himself as a "normal" driver and can be selected as the default output device. Inside your user driver, you need a time base to regularly call the registered IOProcs. The simplest (and likely the most accurate) way to get this time base is to register an internal IOProc to the built in controller. When the built in controller calls out your IOProc, you should then call IOProcs registered to your driver, mix the audio buffers you get, and send the result on the network. What I could suggest is that you use a multicast protocol based on UDP, either UDP/IP or RTP. RTP stands for Real Time Protocol. It is standardized and described in the document RFC 1889 (now replaced by RFC3550). Just google and you'll find these. I've never used RTP myself and I don't know if it is available as a standard on Mac OSX. You may have a look to the QuickTime streaming server sources, there are here a lot of code related to this protocol. Don't use TCP/IP because this is a point to point "connected" protocol and therefore not efficient for your configuration (one producer, n consumers). You may also try IPOverFirewire if your network is FireWire based. If you choose to use "out of the box" UDP/IP, just take care, if you can, that the consumers (network receivers) are able to pop their data faster than they are pushed by the producer. From my experience I've seen that most of the time (if not always) data are lost on the receiver side. Anyway, if the receivers cannot pop the audio using UDP, they won't be able to do it either using TCP because this protocol uses more network and CPU resources.

Search on the archive subjects related to AudioHardware plugins (many posts coming from Stefan Werner), they are very informative.

I don't have clear ideas about the solution at the receiver side. Basically, I'd guess that a similar approach could do it (if receivers are running MacOSX). When you receive a packet (a datagram), copy it to a ring buffer and from here emulates a "real" input device driver in your "user space" driver. There are people on this list who know better than me what could be done here.

A note about real time when dealing with IP communication. As far as I have understood, the IP code is executed in the BSD layer of the kernel which is not completely reentrant (at least this was true for the first versions of Mac OSX). Apple has modified the BSD code to enable partial reentrancy (something they call "funnel"), IP codes all execute into a given funnel which means that concurrent network accesses from the applications may have an impact on the response time. Questions on the Darwin list would surely give much more accurate informations on this particular point. Anyway, a good practice should be to avoid small buffers. I think that going under 512 frames at 44.1 (IO cycle of about 11 ms) is not safe, especially in a heavy loaded environment.

A last word. A "user" driver is instantiated each time a CoreAudio app selects (????) this driver. A "kernel" driver is instantiated only one time. So it uses less resources at the end.


I am trying to stream audio from my mac to a network receiver. Although I don't know where to start, I am prepared to get my hands dirty.

Here are my goals:

i) Divert _all_ sound from my mac to the network receiver(s)

ii) Control the output just like the local sound device (ie OS X volume control, etc works)

iii) Easy switching between local and remote output from the desktop.

iv) Cross platform compatibility for remote client

Firstly, is there any software around that will do this?

If I have to write my own, what layer of the OS X audio stack should I be working with?

Does anyone have any suggestions as to what streaming technology to use?

coreaudio-api mailing list | email@hidden
Do not post admin requests to the list. They will be ignored.

Philippe Wicker
coreaudio-api mailing list | email@hidden
Do not post admin requests to the list. They will be ignored.

 >Streaming OS X audio over network (From: Tim Hollingsworth <email@hidden>)

Visit the Apple Store online or at retail locations.

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.