A conceptual diagram of DigiSpeaker Prototype IV is pictured below. Unlike previous versions, this design does not include analog/digital I/O and is capable of driving stereo speakers or bi/tri-amping a single speaker.

Larger

1. Control

Like previous versions of DigiSpeaker, Prototype IV has the MPC5200B from FreeScale at its core. Even though this processor is a little expensive ($18ea. in 1000s) we still like it. It is well supported in the Linux kernel. It has a wide range of peripherals. It consumes little power yet has a lot of punch (contains an FPU also). This might change in the future, however. NXP has developed the LPC32xx family of processors. These processors are enhancements of their LPC3000 series. We previously considered these processors but rejected them because they lacked I2S interfaces. However, the new family of processors has a couple I2S interfaces. They are comparable to the MPC5200 in power yet they cost half the price (that is just a rumor at this point). For now, we are sticking with the MPC5200 until the LP32xx processors are in production.

We have dropped WiFi support in favor of a powerline modem chip set from Intellon (INT5500CS). WiFi modules are expensive and can be 'tricky' depending on the installation. We noticed in the Sonos forums that the major complaint about their unit is WiFi reliability (or lack there of). Sonos has recently elected to step up the 802.11n to try and fix the problem. This plan has a chance but is yet again, more expensive and the vendors that sell the chips are even harder to work with. So, we have decided to use the powerline modem approach. Notice that we still have USB in our system so it would be possible to slip in a USB WiFi module if it is required.

We still plan on using Insteon as our wall control. The idea here is that users will outfit their homes with Insteon compatible switches that can command the DigiSpeakers for things like volume control and playlist selection. We are also keeping our IR control link (not pictured) so that any 38KHz remote control can be used to control the unit. Also, we are keeping our browser interface to an installation for full control. Finally, Jon has been playing with the iPhone and iTouch devices from Apple. He likes them a lot and will probably build an interface into these devices (browser based?) as well.

2. Amplifier

The major difference between this prototype and previous versions is the amplifier. We are still using the TAS5504 as our PWM processor and the TAS5142 (or TAS5342 if available) as our power stage. Both are from Texas Instruments. However, we now configure the output stage as Bridge-Tied-Load (BTL) and drive the speakers differently via software depending on the product (more on the products in a minute).

At 96KHz and below, the TAS5504 has 4 independent processing channels that can be configured to accept either channel (left or right) from any of the I2S interfaces. Above 96KHz, the TAS5504 runs out of processing power and can only process 3 channels (see page 11 in this document). The processing pipeline for each channel is impressive. Each channel has seven bi-quad filters, base, treble, volume, loudness and dynamic range control. Also, each channel has an output mixer with gain control to mix any of the processing channels at output. With this flexibility, it is possible, via software, to create several products from the proposed design.

1. Simple Stereo Mode. In this mode, a single DigiSpeaker is used to drive two speakers in stereo. The speakers will have crossover circuitry to handle the separation of tweeter and woofer frequencies. In this configuration, only two of the TAS5504 processing pipelines will be used (PWM 1 & 2) for left and right channels of a stereo signal. The bi-quad filters are used for music shaping (country, rock, rap, jazz, ...etc). The treble, bass, loudness and dynamic range control are used in the traditional manor.
2. Full Stereo Mode. In this mode, a single DigiSpeaker is used to drive two speakers in stereo. In addition, a subwoofer channel is driven from a second TAS5342 built into the DigiSpeaker. In this configuration, two TAS5504 processing pipelines are used for stereo processing (PWM 1 & 2) and a third is used for subwoofer processing (PWM 4). The bi-quad filters are used for music shaping. Treble, bass, loudness and dynamic range are set as the user prefers.
3. Bi-Amp Mode. In this mode, a single DigiSpeaker is used to drive the tweeter and woofer of a single stereo channel (either left or right). Two DigiSpeakers are expected to be used in a zone to complete the delivery of both left and right stereo signals. Two TAS5504 processing pipelines are used (PWM 1 & 2) but they both are given the same input signal (either the left or right stereo channel). The bi-quad filters are used to implement the speaker crossover as well as music shaping. Treble, bass, loudness and dynamic range control are used as the user prefers. Notice that using two DigiSpeakers in a single zone doubles the power delivered to that zone. In fact, it is possible to add any even number of DigiSpeakers (2, 4, 6, ...etc) to increase the power delivered to a zone.
4. Tri-Amp Mode. In this mode, a single DigiSpeaker is used to drive the tweeter, mid-range and woofer of a single stereo channel (either left or right). Two DigiSpeakers are expected to be used in a zone to complete the delivery of both the left and right stereo signals. Three TAS5504 processing pipelines are used (PWM 1, 2 & 4) but they all are given the same input signale. The bi-quad filters are used to implement the speaker crossover as well as music shaping. Treble, bass, loudness and dynamic range control are used as the users prefers. Like the Bi-Amp mode, this mode can be used to increase the power delivered to a zone simply by installing more DigiSpeakers.

The MPC5200 requires an external clock chip to reach speeds above 96KHz. So, there are potentially two grades of each of these products depending on whether the clock chip is included or not. In addition, the addition of the second TAS5342 could also be a product differentiator.

3. Power Supply

The power supply for DigiSpeaker is still an important component. Power supplies tend to get more expensive above 100W where high efficiencies are required to keep the heat produced to acceptable levels for installation in a wall or ceiling. However, power supplies in the 60W to 70W range are pretty cheap because they are commonly used for TVs and Laptops and they produce less heat. The new DigiSpeaker design could potentially use a cheaper power supply when configured in Bi-Amp or Tri-Amp modes because they are powering less speaker. Deploying two DigiSpeakers in a zone could add up to the same power as a single DigiSpeaker in Stereo mode.

For now, the power supply remains the same as previous version. We will try to deploy a 130W power supply that can be used to power the logic and deliver 100W of power to the speakers. This is probably overkill for he Bi-Amp mode (and possibly the Tri-amp mode), but will just be comfortable for either of the Stereo modes.

Both Jon and I had to camp this project to deal with issues in RL. We are done with that now and back to work on DigiSpeaker.

During the break, Jon had a chance to rethink our model and has made some adjustments. For instance, Jon no longer feels it is important to have direct I/O in the modules (analog/digital input and output). He feels that there are other devices that do a better job of this and it is not worth the expense. I agree with this change. DigiSpeaker shines as an internet connected amplifier. How the music gets into the cache of each node is really a separate problem. I would prefer that users simply 'drag and drop' music files into the nodes of an installation and forget about it. How the music files are created (ripped from CD, recorded from analog, ..etc) is another problem that has been well solved by other devices.

Also, Jon would like me to design a system where DigiSpeakers can be 'piled' into a zone to achieve higher power levels and better sound quality. This is a little harder to explain. But what he is getting at is a system where two or more independent DigiSpeakers cooperate to play music. For instance, if a single DigiSpeaker is in a zone, then it should be capable of driving a pair of stereo speakers (traditional left and right speakers with crossover circuitry). However, if two DigiSpeakers are installed in a zone, then one should be able to play the left channel while another plays the right channel. Since two DigiSpeakers are involved, each with a separate power supply, it would be possible to double the power delivered in that zone. Furthermore, in this configuration, it would be possible to bi-amp the speakers attached to a node so that the tweeters and woofers are driven directly from the amplifier. Crossover would be achieved digitally in the PWM processor. This could greatly enhance the quality of sound for any installation because all deployment flaws could be corrected in software.

A block diagram will make these two important changes clearer. I will post one with a discussion in the coming days.

The block diagram of the third prototype can be found here. You will have to zoom in quite a bit with this diagram. This diagram is the front page of the third prototype schematics and I still don't have a good/free method for translating DXF files to PDF yet.

Notice that there are actually three separate systems in this block diagram connected to a common controller design. The intention is to build a single PCB, but change its function by including/removing certain parts. The three systems are:

1. Embedded. The Embedded Model is intended to be the unit that is installed in ceilings and walls of homes. It is assumed that this system will not have direct connections to external music sources so it does not have an I/O module. Of course, it does have an amplifier.
2. Desktop. The Desktop Model is intended to be an standalone unit that might sit on a desk or table in a room. This unit has the potential to be directly connected to legacy music sources so it does include an I/O module. Of course, it also includes an amplifier.
3. Media Center. The Media Center unit does not include an amplifier. This unit is intended to be used with other media equipment in a cabinet so it does have an I/O module. However, it is assumed that the music is shipped out to other amplifiers (including other DigiSpeakers) so it does not include an amplifier.

The controller is a Freescale MPC5200. Its subsystems have been assigned as follows:

1. Clocks and Reset. A 33MHz crystal will be used to set the MPC5200 clock speed to 528MHz (fastest setting). Soft and hard (button) resets will be supported.
2. JTAG. We are going to use JTAG to program the embedded Flash during production. We hope to make our own simple JTAG system for doing boundary scan on the MPC5200 and leave in-circuit debugging for later when we can afford a nice JTAG system.
3. SDRAM Memory Controller. We are going to add 64MBytes of DDR266 memory (MT46V16M16P-75 or equivalent). Jon says that will be plenty of memory. We might back this down to 32MBytes depending on price. Right now, there isn't much difference. Notice that the 128MBits and 256MBits share the same package footprint.
4. Local Bus. The MPC5200 boots on chip select zero of the local bus. We are going to put 8MBytes of NOR Flash at chip select zero as the boot ROM. More than likely, it will be a Spansion S29GL064. Jon thinks that 8MBytes might be a little tight (compressed kernel + root file system is about 6Mbytes). If so, we will up the flash memory to 16MBytes with a Spansion S29GL128N. The two packages have the same footprint.
5. ATA Bus. Not used
6. PCI Bus. The MII of the MPC5200 is used for the powerline modem so a PCI to Ethernet bridge is used on this port to give the system cabled Ethernet. We are going to use the KSZ8841-PMQL from Micrel.
7. PSC1. The audio clocks that the MPC5200 can generate are not very accurate, especially at 192KHz. To fix this problem, we have added an external audio clock to the design. To cut down on the amount of external logic it might take to integrate the clock, we decided to put a couple of the serial ports on the MPC5200 into 'cell phone' mode. This mode allows an external clock to be input on one port and then used as a master clock for another port. The 'master' cell phone port is PSC1. In the case of the Embedded system, we are using the MAX9485 from Maxim. For the other systems, we are using the integrated clock of the WM8580 from Wolfson.
8. PSC2. The second serial port of the MPC5200 is used as the slave cell phone port. This port receives a master clock from the first serial controller and uses it to compute bit and frame clocks for an I2S connection to the PWM modulator (TAS5504 from TI). Notice that in the case where music is being sourced from an external device, the MPC5200 can be bypassed with a direct connection from the WM8580 to the TAS5504.
9. PSC3. This port is split between a UART and SPI connections. The UART is connected to an RS232 driver and is used as the boot monitor. The SPI connections is used as the connection to a mass storage device (SD Card or MMC).
10. PSC4. This is the USB port. Right now, the USB connection is unassigned. However, it can be used for more mass storage or a WiFi module connection.
11. PSC5. This port contains an Ethernet controller that is normally connected to an Ethernet PHY. However, the powerline modem chipset (INT5500CS) acts like an Ethernet PHY and expects an MII to a controller. So, this port is connected to the powerline modem and cabled Ethernet is supported via the PCI bus.
12. PSC6. The port is used at the serial connection to the Insteon controller. The Insteon controller connects directly into the powerline and can receive and send commands from/to other Insteon devices. This is one way the unit can be remotely controlled.
13. Timers/GPIO. Various control signals are implemented with the Timer pins in GPIO mode. Examples are Mute, Reset, PowerDown, ...etc.
14. Dedicated GPIO. The Infrared receiver is connected to these pins so the user can control the device with a simple IR remote. These pins have wakeup capability so they can be used to get the system out of sleep mode.
15. Power. The power supply is split into two sections roughly corresponding to Digital and Analog power. The Analog supply is a variable power supply (+32V to 0V) that can be controlled by the volume control of the PWM modulator. The Digital supply has a separate controller and outputs the various fixed system voltages.

DigiSpeaker is a cached music system. It is intended to be used to play music that has been previously stored in the system. Because DigiSpeakers are distributed throughout a home and buried in walls and ceilings (often inaccessible), it is important that all DigiSpeakers be connected in some manor as to make loading music simple and convenient. The obvious choice, of course, is to network DigiSpeakers together. Furthermore, it seems obvious that each DigiSpeaker appear as an Internet node so that they can be accessed inside or outside the home (depending on router settings, of course).

Since DigiSpeaker is a cached system, all music scheduled for playback exists in DigiSpeaker before it is played. As mentioned in previous posts, each DigiSpeaker will have ample storage for music (provided by plug-in flash sticks or memory cards). Also, as previously mentioned, several DigiSpeakers in an installation will 'band together' to form one large storage in such a way as to make music stored on one node accessible to all nodes in the home.

So, networking is important to DigiSpeaker. But at a glance, it would appear that the required network throughput is not all that high. Each DigiSpeaker need only be able to acquire (either from its own cache or from another unit) a new song in the time it takes to play the previous song. If that new song needs to come over the network, then the required throughput is low. For example, if an MP3 file containing a 3 minute song is around 3MBytes in size, then the required network throughput is only 17KBytes a second. Hardly taxing to modern networks even given dropouts and lost packets.

However, experience has taugh us that you can never have too much bandwidth. We anticipate DigiSpeaker to be no different. As the feature set of DigiSpeaker grows, so will its bandwidth requirements. For instance, if DigiSpeaker is ever used to stream live events (like sports or concerts), then a system of caches will add unacceptable delays to the sound. Those delays will be noticed by the user watching a video of the event and expecting the sound to be in sync. We expect this type of feature growth to be common with DigiSpeaker so it suggests a design goal for network throughput (and processing power in general). That is, we want to add as much bandwidth to the system as we can afford. In this case, we think we can afford about $10.

Another thing experience has taugh us is that networking devices in places that do not have networks can be problematic. This is the exact situation in homes. Most homes do not come wired with Ethernet cables in the walls. To get around this, of course, people use wireless or powerline connections. However, we notice that any of these solutions (wired, wireless, powerline) have 'challenges'. Wireless connections are sensitive to interference and building structure. Powerline connections have trouble transmitting across phases. Wired connections are impractical and/or unattractive if they haven't been built into the walls. Seeking to avoid these shortcomings suggest another design goal for the DigiSpeaker network. That is, each DigiSpeaker should have as many connection modalities as possible to give the user multiple connection choices. In this case, it means that each DigiSpeaker should be capable of communicating over wired, wireless or powerline connections. To avoid skyrocketing the cost, the choice of connection could be specified at manufacturing time so as to avoid including connection choices that the user knows they do not want.

Always mindful of cost, we went searching for ways to implement these three connection types on the MPC5200. Our goal was to find parts that could be afforably added to the design (once again, affordable generally means about $10 or less to us).

Starting with the wireless connection, we discovered that most wireless chipset manufacturers would not return our calls. Digging a little further, I found somebody at Broadcomm that explained to me that they don't work with independent hardware vendors (read: little guys) because most were not capable of passing through the worldwide licensing requirements for certifying a wireless device (hmmm). They suggested that we look into adding a prebuilt wifi module that presumably had already been blessed by the certification process. Fine enough... we went looking and discovered that they aren't affordable (by our standards, anyway). However, we noticed that USB modules, which are banged out in the millions per year, do seem to be at least reasonable (around $30 or so retail). Of course, cheap USB dongles are hardly appropriate to be the cornerstone of our network, so we went looking for an alternative.

That alternative appeared in the form of the Intellon INT5500 powerline mode chipset. This chipset is capable of transmitting information over powerlines in homes at up to 85Mbps. It is compatible with HomePlug 1.0 and doesn't interfere with Insteon (yet to be verified). Best of all, Intellon returned our calls and agreed to sell us chips.

The Intellon INT5500 connects to the MPC5200 via its MII interface. However, each DigiSpeaker is supposed to retain a wired connection. To get around this, Jon found an Ethernet controller with a PCI interface. It is the KSZ8841-PMQL from Micrel. This chip is affordable by our standards.

So, to achieve our goals of affordable bandwidth and varied connection types, we have decided to: 1) add a second USB connector so that any Wifi module can easily be added. 2) add the Intellon INT5500 chipset so that any DigiSpeaker can network with another over powerlines, and 3) add an Ethernet connection via PCI so that any DigiSpeaker can be networked directly.

There are a couple of ways to add an external audio clock to the MPC5200. The first thought is to run the MPC5200 I2S interfaces in slave mode and use an external audio clock to clock the interface externally. The idea would be to put the audio clock in the 'middle' of the connection between the MPC5200 and the TAS5504, running both devices in slave mode. The problem with this approach is that the MPC5200 can not produce bit and frame clocks while in slave mode. So, if an audio clock is added in this fashion, external logic also has to be added to create the bit and frame clocks. That adds complication/expense because that external logic would also have to be programmable to adapt to the different data rates we hope to support.

Jon pointed out that the MPC5200 does have a 'cell phone' mode where one programmable serial controller (PSC) can be used to clock another. The cell phone mode of the MPC5200 allows PSC1 to accept an external bit clock and pass it along to another PSC as its master clock. The second PSC is then free to use that master clock to produce bit and frame clocks, as well as transmit and receive data.

One hiccup in this plan is that when a PSC is driven in this fashion, it does not emit a master clock signal itself. So, the master clock has to be sent directly from the external clock chip to the TAS5504. A potential problem might be that as the master clock propagates through the MPC5200 to produce the bit and frame clocks of the slave PSC, it becomes delayed/skewed from the original master clock signal to the point that the TAS5504 is out of sync. However, the TAS5504 documenation says that this should not be a problem.

So, to prove this point and to gain some experience with this setup, we decided to do the following experiement.

We decided to use the MAX9485 from Maxim as the audio clock source. This chip can be controlled via I2C and supports audio data rates of 32KHz, 44.1KHz, 48KHz, 88.2KHz and 96KHz. Through internal manipulation of the clocks inside the MPC5200 and the TAS5504, we can also use this chip to support 176.4KHz and 192KHz.

The Clock Output of the MAX9485 was connected to the master clock input of the TAS5504 and the bit clock input of PSC1 on the MPC5200. The bit, frame and data output pins of PSC2 on the MPC5200 were then connected to the I2S channel 1 input of the TAS5504. The pictures below (sorry for the poor quality. Time for Tyler to get a new camera!) show how the chip was added to the first prototype. I decided to mount it on the bottom of the expansion card so that I could more easily wirewrap the connections to the patch field and the TAS5504 input header. You can just make out the power capacitor hanging out the bottom of the expansion card in the top view picture.

I have also attached two programs that I used to test the setup.

1. tasclock

This program is analogous to the previous program called tastone. It can be used to play square, triangle and sine waves of the supported frequencies on the TAS5504. The MAX9485 and the TAS5504 have to be setup manually (using something like i2cset) before tasclock can be used.

2. tasplay

This program is analogous to the previous program called taswave. It can be used to play small wave files on the TAS5504. This program sets up the MAX9485 and the TAS5504 so there is no need to manually configure them. However, you do still have to set the mater volume of the TAS5504 (I2C register 0xD9).