Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Avatar74

macrumors 68000
Original poster
Feb 5, 2007
1,631
426
I'm sure others have noticed the many differences between Airport Express and AppleTV... not merely the obvious addition of video bridging. The concept is somewhat the same... media bridge. But there does seem to be some marked differences in terms of resources usage and operation.

Basically, the resources usage on the host computer is next to nothing with at least music. I haven't yet observed the resources usage with video. I've also noticed that wireless bandwidth usage is more efficient.

One problem with Airport Express was that most of my operation consisted of using the laptop in the living room as a user interface, even to access the library on my G4 in the office right behind the living room via music sharing... but you can see the problem here. I've got some wireless bandwidth eaten up talking to the computer in the office, some wireless bandwidth eaten up by the computer in the office talking back to the laptop, and then more wireless bandwidth AND CPU and drive resources on BOTH machines being eaten up transmitting music sharing-accessed material to the Airport Express... and doing so with iTunes actively "playing" the shared file through the front end of the laptop.

But in this case with AppleTV... It appears to be talking only to the backend database of iTunes, using the front end active application only as a gateway to connect to that backend. Network traffic from this laptop remains fairly constant between 14-18 kilobytes/sec (112-144 Kbps) when streaming music. Barely any overhead traffic, if at all.

When streaming from a host computer, Activity Monitor shows iTunes using 0.30% of my RAM (512MB on this laptop). Playing the file in iTunes, as you would through to Airport Express, increases memory usage on the host computer to nearly 20%.

Additionally, the drive usage is somewhat different. In one instance, playing the file in the iTunes interface on the computer the entire file seemed to be read into memory from the drive in one large burst. While streaming to iTunes, reads from the hard drive occur in regular intervals at about 120-200 kilobytes per second ratewise... but hardly a fraction of a second in each instance. I assume it's bursting a segment to the AppleTV buffer and then bursting the next segment as the AppleTV memory buffer runs down. Airport Express seems to lock up occasionally, as if there are buffer underrun problems. Again, could also be a much poorer antenna reception on the Airport Express vs. the AppleTV (which gets full signal in an area of my living room where AppleTV would not stay connected for long). Let me add I live in an apartment high-rise where the walls are framed with steel and floors are separated with concrete, but there are also a number of nearby wireless base stations that would frequently interfere with the Airport Express signal as well as my Powerbook G4/1GHz laptop which has the aluminum-encased antenna (the Macbook fixed this with a plastic/rubber edge that didn't inhibit the signal nearly as much).

Another thing... I could be wrong but I seem to recall something about AirTunes resampling every format to 320Kbps *before* streaming to Airport Express... but here it looks like 128Kbps AAC is streamed at 128Kbps based on the average of the aforementioned range. My guess from the specs, though I haven't tested this yet... is that higher bitrates are downsampled to the max cap of 320Kbps AAC for transmission to AppleTV.

There could be various factors involved here... but I'd like to hear other people's observations regarding those factors. It appears, for one thing, that the front end of iTunes isn't active at all on the host streaming computer... it lies dormant like a gateway, to allow AppleTV to talk to its backend database, taxing at most the hard drive of the host computer.
 
Picture 1.png


AirTunes does no resampling/converting.
 
...
There could be various factors involved here... but I'd like to hear other people's observations regarding those factors. It appears, for one thing, that the front end of iTunes isn't active at all on the host streaming computer...

The (graphical interface to) iTune that you likely think of as being (the "front end" of) iTunes isn't active, but iTunes is "active" (or this won't work.) But yeah -- GUI's suck (resources) on servers. Anyone that runs servers knows that if you don't need a GUI, you don't run them (unless you have resources to burn!) :p

...it lies dormant like a gateway, to allow AppleTV to talk to its backend database, taxing at most the hard drive of the host computer.

Any server daemon is "dormant", e.g., it will wait for incoming connection requests, and then performs tasks in response to those requests.

Streaming really doesn't require a lot of resources on the server end, but for this to work obviously more is required than just using spinning up the hard drive. In other words -- it shouldn't be considered as being simply a "gateway." (What's really happening goes beyond simple "file sharing.")

Simple streaming is easy to do -- typically, you'd run HTTPD on the server end, the client and server would exchange request/response and the (requested) content is streamed from the server to the client. For example, you can stream from Apache using a few lines of PHP code (no real "streaming server" software required.) And we know that in OS X, Apache/HTTPD is "in there"... add some lines of code in Perl (also "in there") and you've got yourself a simple streaming server.

But what Apple TV is doing isn't exactly simple. Documentation on Apple TV's streaming methods is non-existent at this point in time, but lets assume it's using DAAP in some form. An example of a DAAP session follow, taken from here.

Code:
Diagram of the flow of requests/responses in a DAAP
session:

client server Description
         ---/server-info---->          Request for server info
       <-------msrv-------             server info response
         ---/content-codes-->          request for content-codes
       <-------mccr-------             content-codes response
         ---/login---------->          login
       <-------mlog-------             login response (with sessionid)
         ---/update--------->          update request 
       <-------mupd-------             update response (with server
                                       rev)
         ---/databases------>          database request
       <-------avdb-------             data base response (with dbid)
         ---/db/id/items---->          request songs 
       <-------adbs-------             list of songs in database
         -/db/id/containers->          request playlists
       <-------aply-------             list of playlists in database
         -/db/id/c/id/items->          request playlist
       <-------apso-------             list of songs in playlist
         -/db/id/c/id/items->
       <-------apso-------
         -/db/id/c/id/items->
       <-------apso-------
         -/db/id/c/id/items->
       <-------apso-------
         -/db/id/items/x.mp3->         request mp3
       <--stream-mp3-file-             stream'd mp3

Bonjour (zero-configuration networking) is what makes all the "discovery" part of the process painless (making much of this seem simple). According to Apple's docs on Apple TV, the device uses TCP port 3689 is used to communicate with iTunes (servers) on the local network, and UDP port 5353 tor automatically find computers with iTunes on your network using Bonjour. In other words, it only takes two ports to "handle it."

Edited to add the following: There are several open source server implementations of DAAP which iTunes (clients) can communicate with, however there are currently no open source DAAP clients that can communicate with iTunes v.7 (servers) which require incoming DAAP client requests to be "signed."
 
Thanks for the detail, localoid. I understand the first three layers of the OSI model pretty well but when it comes down to actual programming that's not my area of expertise.

It seems actually quite simple conceptually how it's being done.
 
View attachment 71810


AirTunes does no resampling/converting.

Well, I'm not sure about the 320Kbps conversion for transmission to AirPort Express but it certainly does convert or upsample back to 16-bit stereo LPCM before going out the optical port to your receiver. A receiver's optical port generally can't process AAC and when the signal is active, my receiver indicates that it is receiving 44.1kHz 16-bit stereo LPCM.
 
Thanks for the detail, localoid. I understand the first three layers of the OSI model pretty well but when it comes down to actual programming that's not my area of expertise.

It seems actually quite simple conceptually how it's being done.

Yes. Simple, but effective. Aka, "it just works".

Looks like iTunes has basically become a "platform"... It should be rather interesting to see how it all progresses from here. ;)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.