My original intent was to have the two base stations form a "dual-band network." The Extreme-n would handle all the traffic in the 5.0 GHz band — the one used by 802.11n transmissions, which are faster than 802.11g. The Extreme-g would handle just the 802.11g traffic, which is located in the interference-prone 2.4 GHz band.
The Apple TV is capable of using speedy 802.11n transmissions in the interference-free 5.0 GHz band, if an 802.11n-capable computer running iTunes is available to it ... otherwise, it contents itself with 802.11g. My (erroneous, as it turned out) assumption was that my MacBook Pro could use 802.11n as well, provided I ran Apple's 802.11n Enabler on it. But, no. My version of the MacBook Pro has but a lowly Intel Core Duo processor in it. Of the MacBooks, only those with the Intel Core 2 Duo can be 802.11n-enabled. Oops.
That letdown meant that (since I have only one n-enabled device, the Apple TV) I would be stuck in the 2.4 GHz band that 802.11g uses for its relatively slow traffic. Unless you have at least two devices that "speak" 802.11n, you are necessarily stuck with 802.11g all the way down the line.
Which meant that I had to revise my original configuration of the new Extreme-n. I initially set it up manually (after having completed the assisted setup phase) to use the radio mode called "802.11n only (5 GHz)." With that radio mode, neither of my Macs even saw the new base station's network (actually just a segment of the previously existing network, which was now dual-band). Because of that, I could not get my Macs to join the new network segment, and they could join only the original network segment ... the one operating at 802.11g speeds.
Not being able to join the 802.11n segment of the network, neither of my Macs could stream or sync iTunes media to the Apple TV on that relatively swift segment. Which, sadly, defeated the intended purpose of the dual-band network.
In order to get my new network segment to be one which my Macs actually could join, I had to reconfigure the Extreme-n, by way of AirPort Utility's manual setup process, to the radio mode of "802.11n (802.11b/g compatible)." That meant my Macs could join the new segment (hosted by the Extreme-n) or the old one (hosted by the Extreme-g). Alas, no matter which segment I had them join, they would be limited to using 802.11g speeds, even when talking to the Apple TV.
The next thing I wanted to do, of course, was see whether I could copy my movie files to the hard drive attached to the Extreme-n — called an "AirPort disk" in the lexicon — and then stream them via iTunes on my MacBook to the Apple TV for viewing.
Lo and behold, it worked!
But there was an issue: speed. Where the speed of 802.11g had been perfectly adequate for streaming from movie files on the internal hard drive of the MacBook, it was not adequate for streaming from the AirPort Disk, via the MacBook, to the Apple TV.
As a result, every minute or two the Apple TV's input buffer became depleted of contents, since the network couldn't keep up. The Apple TV would freeze the frame on the TV screen briefly and wait to fill up its buffer again, showing a progress bar at the screen's bottom while this went on. It took only about two seconds, but it was irritating to have to put up with the "buffer underflow" hiccup time and time again.
Experiments with other movie files tended to confirm my suspicion that this "buffer underflow" problem was likely to happen only with movies whose bitrate — the number of bits per second of video and audio — was fairly high. Lower-bitrate movies had few if any "buffer underflow" hiccups.
Still, I considered the hiccups too annoying to live with, so I looked for a fix.
I reasoned that the borderline speed insufficiency of my network just might be gotten around by having my Macs and the Apple TV join exactly the "right" respective segments of my dual-segment network. (I'll call it a dual-segment network, not a dual-band network, because it it no longer consists of one band isolated on each base station. Both base stations host network segments operating in the 2.4 GHz 802.11g band.)
Perhaps, I thought, if I had the Apple TV join the Extreme-n's segment while the Macs were on the Extreme-g's segment, that might speed things up.
And it seems to have done just that — but not enough. There were fewer hiccups, but still some. No amount of rejiggering my devices-to-segments-joined protocol seemed to eliminate the hiccups entirely.
I don't mind saying I felt a bit flummoxed at that point. It was beginning to look as if there was no way for me to painlessly achieve my original goal, which was to have all my movie files stored on a capacious hard drive attached to my new base station.
Then I hit upon the expedient of connecting my iMac to the new Extreme-n via Ethernet, where it originally used AirPort.
I ran an Ethernet cable from the iMac to one of the spare LAN ports on the Extreme-n. In the Network panel of System Preferences I selected Built-in Ethernet (rather than AirPort) under Network Status. Under Built-in Ethernet, I selected "Using DHCP" as my choice from the Configure IPv4 pop-up menu, and I entered the requisite DNS Server and Search Domain information specified by my Internet provider. I clicked "Apply Now," and my iMac switched from using AirPort to using Ethernet to contact the Extreme-n and go online!
I was worried that perhaps doing this would make it impossible to access the AirPort Disk from the iMac. I didn't have to fret: the AirPort Disk remained mountable on the iMac.
Which meant that the movies on it could be opened in the iMac's iTunes and streamed to the Apple TV. And, wonder of wonders, stringing Ethernet between the iMac and the Extreme-n had cured my "buffer underflow" hiccups!
My reasoning on that is this. When iTunes was streaming movies from my AirPort-connected MacBook to the Apple TV, all the data had to make three trips through my wireless network:
- From the AirPort Disk to the MacBook's iTunes, via a base station
- From the MacBook's iTunes back to a base station, en route to the Apple TV
- From the base station to the Apple TV
When the movie's bitrate was high, three trips were too many. The wireless network bogged down.
But when there was a "Fast Ethernet" (100 megabits per second) link between the iMac and the Extreme-n, only Trip 3 was wireless. Trips 1 and 2 still were being taken by all the data from the movie file, but they now took advantage of the Fast Ethernet connection. So the wireless network itself never got bogged down.
My hunch is that I could ditch the Fast Ethernet connection between the iMac and the Extreme-n if I were to replace my MacBook Pro (and/or the iMac) with a Mac that is 802.11n-capable. Then I could reconfigure my wireless network as truly dual-band, and then I could have both the replacement Mac and the Apple TV join the 802.11n segment, thereby taking advantage of its higher speeds. All three trips taken by the movie data would then happen at those speeds, which would presumably be fast enough to avoid all "buffer underflow" hiccups during streaming.
If you happen to have an 802.11n-capable Mac and an Apple TV, you can probably already take advantage of a dual-band wireless home network, using the Extreme-g base station you presumably already have, complemented by a new Extreme-n with a commodious USB 2.0 hard drive attached to it, ready to store all your movie files.