Resonant SMPS for Audio

SMPS have gotten a bad rap for audio because they emit large amounts of EMI. No more! The quest for higher and higher efficiencies especially for digital TVs Home Theater Systems and PCs have made the “resonant” topology more popular and more affordable. Currently available resonant SMPS power supplies provide the highest efficiency and lowest EMI radiation attainable. [You can check the reviews of PC power supplies on Hardware Secrets and you'll find that the latest, high end supplies are based on resonant topologies]

Hifiduino in Malaysia…

A reader from Malaysia has implemented the Hifiduino controller for his Buffalo II DAC (click for larger image)

More H/W and S/W on the Apple Aluminum Remote

HARDWARE

here is a post showing the disassembling of the Apple Aluminum Remote. Indeed, it is manufactured from a single piece of aluminum. Very nice engineering implementation not just in manufacturing the case, but in designing the insides to allow a simple snap-in assembly.

SOFTWARE

The latest release of the Arduino IDE (v 0022) has added a time out during the measuring of a pulse. This allows “native” support for my remote code. The release notes indicate:

* Applying the timeout parameter of pulseIn() during measurement of the  pulse, not just while waiting for it.

Readers that have read the code will note that in order to measure the pulses of the Apple Remote, I rely on the function “pulseIn()” to measure the size (time) of the different pulses generated by the remote.

By definition all pulses have a start and an end. In the absence of an external pulse, the IR receiver outputs HIGH. When there is a pulse from the remote, the IR receiver will output LOW and then back to HIGH, so measuring pulses from the IR receiver point of view is measuring pulses going LOW.

However, the NEC protocol used by the Apple remote utilizes pulse distance (not pulse width) to encode information.

(Diagram taken from here)

Therefore, from the IR receiver point of view, measuring the time distance between pulses  is the same as measuring the size of UP pulses after you’ve detected the start of communication (there are other methods of doing this but this way seems the easiest). Think of it as measuring the time of the white space in the diagram above. (Remember an up-pulse from the remote results in a down-pulse at the IR receiver; thus, between two pulses in the remote, you will see an up-pulse at the IR receiver)

A problem may arises when you try to measure the last pulse of the communication. From the IR receiver point of view, this is the white space after the last pulse which goes on forever (or until you press the remote again). If there is no time out in the pulse reading routine, then your code will hang right there.

The pulseIn() function in previous releases lacked a time-out during the measurement of the pulse which resulted in the code being stuck waiting for the end of that UP pulse (or the end of the white space, which in real life goes on forever). In order to remedy that problem, I redefined pulseIn() with a new function”newpulseIn()” as follows

unsigned long newpulseIn(uint8_t pin, uint8_t state, unsigned long timeout)
{
  uint8_t bit = digitalPinToBitMask(pin);
  uint8_t port = digitalPinToPort(pin);
  uint8_t stateMask = (state ? bit : 0);
  unsigned long width = 0;

  unsigned long numloops = 0;
  unsigned long maxloops = microsecondsToClockCycles(timeout) / 16;

  // wait for any previous pulse to end
  while ((*portInputRegister(port) & bit) == stateMask)
    if (numloops++ == maxloops)
      return 0;

  // wait for the pulse to start
  while ((*portInputRegister(port) & bit) != stateMask)
    if (numloops++ == maxloops)
      return 0;

  // wait for the pulse to stop
  while ((*portInputRegister(port) & bit) == stateMask){
    if(width++ == maxloops)  // added the check for end of pulse       return 0;
  }
  return clockCyclesToMicroseconds(width * 20+16);  // Recalibrated because of additional code
   // in the width loop }

I added the code indicated by the comments in red (thanks to users in the Arduino Forum). This allowed exit from the measuring part of the pulse (in my case while measuring “white space”) and also re-calibrated the timing because more instructions are present in that part of the code.

The latest release of the Arduino software implements that fix. Release B07c of the Hifiduino code and newer leverage this fix. This means no need for a new function “newpulseIn()” and just use the plain pulseIn() function.  However, one advantage of the older code with the “newpulseIn()” function is that it works with either the old or new Arduino S/W. With Release B07c, Arduino v 0022 or newer is required

APPLE REMOTE CODES

The Apple remote returns the following codes:
 
   Up key:     238 135 011 089
   Down key:   238 135 013 089
   Left key:   238 135 008 089
   Right key:  238 135 007 089
   Center key: 238 135 093 089 followed by 238 135 004 089 
   Menu key:   238 135 002 089
   Play key:   238 135 094 089 followed by 238 135 004 089 

For our application the only significant byte is the third byte. Also notice that the center key and the play key emit two sets of 4-byte codes. According to iospirit.com, the double set of code is for backwards compatibility since the new remote has an additional button as compared to the old remote. For the center key and play key, the second set of code corresponds to the old way and the first code distinguishes the separate keys.

Legacy hardware and old driver software receive the additional prefix code and ignore it. Right after, they receive and handle the “old” button code that follows and react to the “Center” and “Play/Pause” button presses like they previously did when receiving a “Play/Pause” button press from a plastic Apple® Remote.

Apple® found a smart solution to achieve backward compatibility. But it comes at a price: hardly any current Universal Remote will be able to correctly learn and emulate the new codes. I fully expect that, instead, they’ll just record and replay the raw IR signal of the new buttons. The effect of this will be that one button press on the Universal Remote will be translated into several raw replays of the new Apple® Remote codes. Or, in other words: one button press on the Universal Remote will act like multiple button presses, because that’s what’ll be sent.

Update: for some reason, there exist another set of valid codes for the Apple Aluminum Remote. You can read about it here.

More on Sabre32 I2S Locking

Perusing the old diyaudio threads (circa 2006), I came to a thread describing the initial designs of the Sabre DAC chip. The ASRC was being designed by Dustin Forman and included a SPDIF receiver. The SPDIF receiver was designed to be superior to any current design, being able to lock into an incoming signal even in the presence of large amount of jitter. This post summarizes the capabilities of the receiver:

“…I did however do a side by side test with my ASRC and the CS8421 looses lock with about 50ns of sine jitter added to the SPDIF stream (Tested with APS2) . Then with my ASRC it still maintained lock with up to 400ns (of sine) jitter…”

The output of the SPDIF receiver is connected to the input of the ASRC. In this post, Dustin shared the challenges of designing the ASRC:

“…designing the ASRC I ran into the problem that the higher my “PLL” bandwidth, the worse the SRC got. Lowering the loop bandwidth does create a better SRC, however something bad happens. If the bandwidth is too low, and your source sample rate is not rock solid (jitter, or just any slight frequency variation) then the locked output would get tiny glitches in it when the ASRC accidentally missed an input sample point or grabbed one twice.

Imagine I lock my “PLL” to the input rate at say 44.10000 kHz and then lowered the loop bandwidth so low it could not respond to the input rate changing to 44.10001 kHz before the PLL misses one of the input samples since it is only looking for data at 44.10000 kHz but the data is now actually coming at 44.10001 kHz.

This was the hardest part of the ASRC design: having enough loop bandwidth to handle source data rate variation, but not too much that it causes errors in the SRC.”

The ASRC as a standalone product was never released, but the technology was incorporated in the ESS DAC chip.

From the above information, one can probably deduce that the SPDIF receiver, being an “integral part” of the ASRC, will enable additional jitter suppression as compared to I2S input.

Update Feb, 2012: The current understanding is that with the same setting the DPLL for the I2S input is narrowed 64X, thus the “difficulty” in locking to the signal

Inside The McIntosh Tin Can…

Always wanted to know what was inside the McIntosh tin can in their ESS Sabre-based CD player, the MCD500

High Fidelity Magazine has reviewed the CD/SACD player and published photos of the internals.

It was once speculated that inside the tin can was a custom, high performance clock for the ESS DAC. It tuns out that the components are:

• Ordinary metal can 27 MHz crystal
• BB PLL1705, a multiclock generator (from a 27Mhz crystal). The resultant clocks (256 fs, 384 fs and 768 fs) are specified at 50 psec of RMS jitter
• AD1986, A sample rate converter for up to 4x oversampling capability (up to 192KHz). It would make sense that the master clock is taken from the output of the PL1705.
• LC4032v, a “programmable logic device” which is a device like an FPGA but usually of less complexity. These devices can be used to implement digital filters and the like. It would then make sense that the 4x oversampled signal is fed to this device.

According to ESS, the chip’s oversampling filter can be bypassed and fed an 8xfs signal; from this we can deduce that the programmable logic device in the Mcintosh CD player is implementing a 2x oversampling filter (4x is already applied by the ASRC). Also, according to ESS, the Jitter elimination engine can also be bypassed when a synchronous signal is fed as it is in this case. It is  likely (I don’t know for sure)  that the McIntosh implementation bypasses the jitter elimination engine because an 8xfs signal is fed into the DAC.

If this is the case, then the McIntosh implementation only uses the “Dynamic Element Matching” present in the ESS DAC in order to achieve the >135dB SNR.

It is notable to mention that one of the limiting factor in this design is the 50 psec jitter specification of the clock generation PLL device; yet this device consistently receives good reviews…

Bulk Transfer Mode in Musiland Monitor Devices

After some reports at head-fi indicating that the Musiland device driver uses bulk mode transfer, I decided to do some USB port snooping of my own by downloading one of the many USB protocol analyzers tools available in the internet. I decided to try USBlyzer BETA (no real reason, other tools should be just as good) to capture the data through the Musiland device while playing a music track.

This is what I found:

• Transfer mode is indeed bulk transfer.
• The size of the packet varies with the sample frequency. For 44.1K material, the size is 2KB and for 96K material, it is 4KB. I also tested 176.4K material and the packet size is 8KB (8,192 bytes).
• Bulk data transfers happens about every 5 msec. If you do the math, the size of the transfer at this rate is about 2x the data required to support the music sample rate (24bits x 2 channels x sample rate). I suppose this “headroom”  is to prevent loosing data due to things like transfer retries, bandwidth sharing, etc. And of course the device only transfers enough data to keep a constant data transfer to the DAC. In contrast, Isochronous transfers in a fixed 1-msec interval
• There is a ~20 msec latency between the request and delivery of data, but there is a request every 5 msec.
• From the trace, we can see a “success” status. This I think reflects the guaranteed data delivery feature of bulk transfer (the endpoint has received the data with no error)

The following images show the captured data flow through the Musiland device while playing a 24/96KHz track. In order to understand the data we can reference the following explanation:

OUT: When the host wants to send the function a bulk data packet, it issues an OUT token followed by a data packet containing the bulk data. If any part of the OUT token or data packet is corrupt then the function ignores the packet. If the function’s endpoint buffer was empty and it has clocked the data into the endpoint buffer it issues an ACK informing the host it has successfully received the data. If the endpoint buffer is not empty due to processing a previous packet, then the function returns an NAK. However if the endpoint has had an error and it’s halt bit has been set, it returns a STALL.

Some observations:

• Since bulk transfer protocol ensures data integrity and there is ample headroom, timely and accurate data delivery is virtually guaranteed
• Based on the above observation, the Musiland device should be insensitive to USB cable length and other “issues”
• Transfer rate is about 5X less than Isochronous transfer which requires a transfer every 1 msec. This means that a PC needs to service a transfer every 1 msec for a Isochronous device and “only” once every 5 msec for the Musiland device. Thus the Musiland device is less sensitive to how busy the microprocessor is doing other things
• It is still a good idea to use a usb port that is not shared with other devices; however, with ample headroom, this doesn’t seem to be that critical

Conclusion

It appears the Musiland device is the only “hifi” consumer USB device that uses bulk mode transfer. Other notable devices including the highly acclaimed M2Tech use Isochronous-asynchronous transfer mode. The advantage of bulk transfer over Isochronous-asynchronous transter is the guaranteed nature of the data delivery. The advantage of Isochronous transfer over bulk is the guaranteed bandwidth; however if there is plenty of bandwidth available (for example, you are not maxing out the bandwidth of the USB connection by plugging in several devices), then guaranteed bandwidth is never an issue.

Musiland has designed an audio class device driver that is robust, accurate and with guaranteed data delivery. The fact that this makes it insensitive to “whatever’ happens in the PC is perhaps a reflection of Musiland’s primary market where people’s preferences and living conditions would likely preclude having a PC dedicated for music alone. My own experience reflects that reality. I have often marveled at the fact that the music “never skips a beat” no matter what I do in the PC.

Update: 7/5/11

Here is “proof” that the bulk transfer mode works well: [link]

A test was performed to evaluate data integrity of the Musiland 01USD. The test consisted in playing a 24/192k file, captured digitally (through the SPDIF interface) with another sound card and then making a comparison between the original file and the captured file.

Simmconn downloaded a 24/192K file in flac format and converted it to WAV 24/192 (almost 600MB, the size of a typical CD), played it with foobar and output the digital signal through a Musiland 01USD. The digital signal was then captured through an M-audio Audiophile sound card and Adobe’s Audition software.  The source and destination files were aligned and then compared bit by bit with an HEX editor. The result: exact match.

Musiland USB Interface: Bandwidth Optimization

The USB transfer mode of the Musiland USB interface is bulk mode. It is the only audio device I am aware of that uses bulk transfer mode.

Almost all USB audio interfaces are designed to operate in isochronous transfer mode, with the majority operating in isochronous-adaptive mode and some operating in isochronous-asynchronous mode. The main difference between adaptive and asynchronous mode is that in asynchronous mode the USB device tells the device driver to speed-up or slow-down the data transfer so that it conforms with the data throughput of the USB device. The data throughput of the device (the data that is fed to the DAC)  is controlled by a local clock that is independent of data transfer frequency which is controlled by the clock in the PC.

With adaptive mode, the USB device has to track the data rate of the source and derive the clock from the data stream. The USB device has to adjust its derived clock in order to prevent overflowing or under running its data buffer. The net result is that with adaptive mode you may introduce data-induced jitter and with asynchronous mode you avoid data-induced jitter and only have to worry about the jitter of the local clock. With bulk transfer mode, you also avoid data-induced jitter plus you have the advantage of higher maximum data throughput as compared with isochronous transfer mode. [In reality, I think it doesn't matter whether it is asynchronous or bulk until you saturate the bus. At that point, asynchronous wins because it guarantees timely data delivery]

According to a Cypress EZ-USB application note:

Isochronous endpoints have a guaranteed bandwidth but not guaranteed data  delivery.  The  timely  delivery  of  isochronous  data  is ensured  at  the expense  of  potential  transient  losses  in  the data  stream.  No  retries  of  data  transfer  are  ever  done  for isochronous  data.

Bulk endpoints, on the other hand, cannot be configured for high-bandwidth   transfers.   However,   bulk   endpoints   can provide  a  greater  maximum  throughput  than  isochronous endpoints can  with  a  trade  off  that  the  bandwidth  is  not guaranteed. [There is also no data loss because the protocol while not guaranteeing bandwidth, it guarantees data delivery through acknowledge and retry]

Thus it is important to ensure that the Musiland device can take full advantage of the bandwidth available in the USB bus which means that it is best NOT to share the bandwidth with other devices.

—

In order to determine if the Musiland device was sharing bandwidth with other devices in the USB bus, I moved the USB connector to different ports and looked at the USB device tree.

The following screenshot shows the USB device tree with the Musiland connected to one of the available USB ports. This port happens to be on the same side (of a laptop) where I also plugged the external HD where the music is stored. Noticed that there are three devices in that hub. The three devices are sharing the bandwidth available through that hub.

Then I moved the Musiland device to another available port. This port happens to be in the opposite side of the laptop. Notice that the Musiland device is alone in that hub, without having to share bandwidth with other devices. Therefore, this is the optimal port for the Musiland device.

Having a usb device not sharing bandwidth with other devices is beneficial to all USB audio interfaces, not just bulk transfer mode interfaces; but it is more important to bulk devices because these have the lowest priority when it comes to bandwidth sharing. According to the USB specification, “bulk transfers will use spare un-allocated bandwidth on the bus after all other transactions have been allocated. If the bus is busy with isochronous and/or interrupt then bulk data may slowly trickle over the bus. As a result Bulk transfers should only be used for time insensitive communication as there is no guarantee of latency.”

—

Additional reading:

SPDIF or USB?