Soekris R-2R: Sound impressions with Salas BiB PS & alpha20 line stage

Posted on March 29, 2015 by Dimdim

A couple of days ago I took my DAM and headed out to a good friend of mine to do some listening tests.

My DAM at the moment is powered by a Salas BiB at 12VDC. It has a DIYINHK XMOS based USB to I2S interface powered by a Salas Reflektor-D at 3.3VDC. The same power supply powers the isolated side of the DAM.

(note that this picture is a bit old. I have since swapped the transformer for the one shown in the next picture plus I have used an IEC with a built-in filter)

The first objective was to assess the importance of a good DC power supply instead of a plain transformer. In order to do that I took with me an extra 50VA toroidal with 2 x 7V windings.

My friend’s system consists of Magnepan speakers, a DIY fet-based preamp and DIY power amp (solid state, 60KG monster). It is widely regarded as a very revealing and non-forgiving system. Any change in any of its components (or a component withing the components) is clearly heard.

The DAM was connected to the preamp through its unbuffered outputs.

We gave the system some time to warm up (it was probably a couple of hours) and then sat down to listen. We started with the DAM as it was, with the Salas BiB. We then unplugged the Salas and hooked up the plain transformer.

The change was immediately obvious. The sound thinned, it became more harsh in the high end. It also lost resolution and detail. Going back to the BiB made all the good qualities come back.

Thus, I can definitely recommend a proper DC power supply for the DAM. I cannot say whether it was the Salas that did the work or that any DC power supply would do the same, but the improvement was definitely there. Note that I have the BoM for the Salas BiB I built in the Soekris’ page.

The second objective was to assess the difference that could be made by using a “proper” output stage after the unbuffered outputs.

So I built a pair of AMB alpha20 line amplifiers. I set their gain to 2 and powered them temporarily by the same Salas BiB that powers the Soekris.

Note that my DAM outputs roughly 1V RMS at its output @ 0db since I’m using a filter that includes attenuation at FIR2 (I can’t really remember which one it is though..). This meant that the alpha20 brought its output to a nice 2V RMS.

Going back and forth between using the alpha20 and just the unbuffered outputs, the conclusion was that the alpha20 removed a small amount of the “magic” of the DAM while not really helping in anything besides output volume. I was hoping that it would help improve the dynamics of the DAM – its Achilles’ heel IMHO. In my friend’s system the DAM sounds “flat” compared to his other sources (a heavily modified Sony 50ES cdp, a Buffalo 3 DAC, and an Aune S16). However, this “flatness” is not particularly obvious in other more forgiving systems.

So, my assessment of the DAM so far is as such: It has great detail, exceptional mid-range, proper bass, it is a little soft on the highs, but its main problem is the dynamics. It can sound a bit “flat”, with this “quality” either accentuated or minimized, depending on the rest on the system.

If there was a way to improve its dynamics, to make it more “aggressive”, it would be a stellar performer (with a proper DC power supply of course). As is, it is just great VFM.

Soekris R-2R: Interfacing to an Arduino

Posted on February 12, 2015 by Dimdim

The Soekris dam1021 has a serial port (J10).
This serial port serves a number of purposes:

1) It is used for uploading firmware updates via the uManager prompt.
2) It is used for uploading filter values via a software utility (not yet released).
3) Outputting info on currently selected Input, Sampling Rate and Volume level.
4) Controlling things by receiving commands. Up to now, we can select Input and change the Volume. More commands might be added in the future (or already exist, but are not yet documented by Soren).

In order to do all those things, one has to interface to this serial port. In this post I detailed how to interface a computer to this port (so as to perform a firmware upgrade). Now it is time to do the same for a microcontroller, say an Arduino.

The problem is, microcontrollers use different voltage levels compared to the “classic” RS-232 serial protocol. In order to make these different things talk to each other, we need to use what is called an “RS-232 Receiver / Transmitter” IC. Such ICs are pretty commonplace, since they are found inside of most devices that come with RS-232 interfaces. The “classic” IC that is used is the Maxim MAX232. It is very low-cost but it is also an old design, requiring 5V (instead of 3.3) and 5 x 1μF capacitors. There is a much newer version of the chip, the MAX3232, operating with a voltage between 3V and 5V and requiring much smaller caps (0.1μF), but it is not as widely available as the MAX232. Since I was in a hurry to get things up and running, I chose what I could find locally in stock: a MAX232.

This meant that I had to power it with 5V and use 1μF tantalum or ceramic capacitors, but what the heck. I was in a hurry.

After reading the MAX323’s data sheet I ended up with this:

(click on the picture for a higher resolution version)

You will notice that I am using Serial3 of the DUE to talk to the DAM DAC. Any serial port could be used, but I chose Serial3 because it was practical – it will be easy to route these specific pins on the shield that I am designing.

Once I verified that the above circuit worked, I built it on perfboard to keep handy:

The above circuit works in general but has some trouble with the DAM DAC. It works just fine upon power up but at some point loses communication with the DAC. The only way to restore communication is to power cycle the DAC. I am not sure what the problem is, but I suspect that it has to do with the power management features of the ICL3221 chip used on the DAM. I have ordered an ICL3221 to use in place of the MAX232, in hope that everything will work fine when I use this (at least in theory) fully compatible IC.

Stay tuned.

Soekris R-2R: Firmware upgrade

Posted on February 2, 2015 by Dimdim

The DAM1021 originally came with FPGA firmware 0.8. Since then Soren has released a new version of the firmware, Rev 0.9.

In order to upload it to the DAC one must connect the DAC to a computer using either a “classic” serial port, like the one found at the back of older computers, or a USB to Serial adapter. Then a cable must be made connecting three pins of the DB9 connector to the connector J10 on the DAC board.

These pictures illustrate the connections that are needed:

You use your new cable to connect the DAM to your computer’s serial port (or USB-to-serial adapter). You do not power on the DAM DAC just yet.

Once you are done with making the physical connection, you need to get your hands on some software that supports the XModem 1K data transfer protocol. This is a pretty old protocol, so your choices in software are pretty limited. One such choice is the “classic” HyperTerminal, but since it is no longer available with Windows I chose the more modern ExtraPUTTY. It is a fork of the classic PuTTY telnet/ssl client software that also supports “vintage” transfer protocols such as XModem.

Once you have it installed it is pretty easy to establish a serial connection at 115200, 8, n, 1, as specified by Soekris. You click on the “serial” tickbox and enter your computer’s serial port (in my case it’s COM5) along with the specified speed (115200bps):

You click on “open” and you get a black terminal screen. You now need to power on the DAC. Once you do that, you should get something like this:

This means that everything is fine. You might see an “I0” instead of an “I3”. That is OK.

Now you need to get to the uManager prompt. You type “+++” and wait for a second. You will not see the “+” characters as you type them. That is OK. You will get this:

Now type “download”, followed by Enter. You will see something like this:

This means that you have 30 seconds to begin sending your file. To do that you click on File Transfer -> Xmodem 1K -> Send. Select your firmware file and off you go!

When the transfer completes you will see something like this:

One thing – do not forget to give the “update” command once you have uploaded the code followed by a “y” and return.

Next you type “exit” (and Enter) to exit the uManager prompt and you are ready to power cycle the DAC. Once you have done that, you repeat the above steps to get to the uManager prompt and you verify that you have successfully updated the firmware. You should now be at FPGA firmware 0.9!

If are having problems connecting, such as getting garbage like this in your serial console:

chances are that your USB to serial adapter is not a “true” RS-232 interface, but outputs TTL levels instead. You can confirm that by measuring the voltages between GND and the RX & TX pins. You should be getting zero volts in one case and about -9V in the other. If you are getting 3.3 or 5 volts, your interface will not work with the DAM. You should try to find a proper RS-232 interface.

The Soekris R-2R DAC

Posted on January 30, 2015 by Dimdim

The UPS guy just dropped off my brand new Soekris R-2R DAC:

Also known by the very bland designation “DAM1021”.

It is a sign-magnitude R-2R DAC (a.k.a. “ladder” DAC), meaning that it is quite different in operation than the regular run-of-the-mill DACs.
It is more like a PCM1704-based DAC but with 192KHz+ support plus a bunch of high tech goodies, such as a built-in FIFO buffer.

It is available in three versions, with resistors of different tolerances (0,01% (high grade), 0,02% (mid), 0,05% (basic)). I got my hands on the 0,02% version.

It has three inputs:
1) I2S (electrically isolated)
2) Coax s/pdif
3) TTL for a Toslink receiver

It is powered directly by a 2 x 7-8V transformer, but may be powered by a bipolar DC power supply.

It outputs a single ended signal at 1.4V RMS and also has a buffer for balanced output at 4V RMS.

It has a serial port for firmware upgrades as well as control.

I have already began work on a Soekris R-2R version of my TFT HiFiDuino Arduino code, tailored to controlling this particular DAC via its serial port.

The board will of course get its own page pretty soon.. Edit: the board now has a page.

To do: hook the board up and actually listen to it play. Stay tuned.

TFT HiFiDuino v2!

Posted on December 31, 2014 by Dimdim

It’s official: Version 2 of the TFT HiFiDuino controller is complete!

There is a number of changes, thus the new version:

New minimal display mode as default. Goes into full display when changes are to be made to parameters.
Full graphics support in the minimal display.
New proportional fonts (TrueType).
New IR code. Now supports a much larger range of remote manufacturers.
Support of MCP23008 IC to control misc devices.
New option to set 0db as default (power-on) volume for connection to a preamp.

The code is (and will remain) compatible with my current shield. (Hint: shield v2 is also coming up!)

New requirements:

Plus the good old UTFT library.

I am including the necessary fonts and bitmaps in the ZIP. The fonts should go into your UTFT & UTFT_DLB directories, usually found in the Windows user’s Documents folders (for example, here: c:\Users\<user name>\Documents\Arduino\libraries\UTFT_DLB\).

The bitmaps should go into your sketch’s folder.

I have included in several places in the code SerialUSB output for debugging purposes. It is commented out in this release for performance purposes. However, it is very easy to re-enable for either debugging or viewing of the IR codes sent to the Arduino. You may use these IR codes to customize the code to support your remote by changing the relevant #define statements in the Remote control definitions section.

Due to code size and performance requirements I’m afraid that from v2 onwards TFT HiFiDuino will only be compatible with the Arduino Due. Sorry, it’s the price to pay for nice graphics. Thankfully, it’s a pretty low price. 😛

You may download it here: TFT_HiFiDuino_v2.xx (14050 downloads ) (Note: As always, the code on this page may not be the current one, i.e. there may be a newer version available. The latest version is always up at the project’s official page.)

I will soon update the code’s official page to v2.

Laying out a display is hard work, Part 2

Posted on December 29, 2014 by Dimdim

A couple of weeks back I wrote that I was working on the next version of the TFT HiFiDuino code and that I was struggling with its new aesthetic.

I was considering something resembling this:

But, I did warn you that the final version would probably look nothing like this. I was right.

Two weeks have passed since then and I am very close to a v2 release. The aesthetics are 99% complete and I am just ironing out a few bugs.

This is the final look:

Stay tuned.. v2 will be out before the end of 2014!

New page: Hypex UcD400HG Power Amplifier

Posted on December 18, 2014 by Dimdim

Back in 2011 I built a 3 channel power amplifier based on Hypex UcD400HG modules and their matching SMPS400 power supplies. It has been my favorite amplifier ever since.

Now it has its own page on my blog, filled with construction details and photos. I have also included the schematic and PCB for the custom AUX power supply that I designed for the UcD400’s input opamp.

The Raspberry Pi: Audio out through I2S

Posted on December 8, 2014 by Dimdim

There are currently four ways to get audio out of the RPi:

Use the audio out 3.5mm jack. It’s very easy to get it to work, but the sound quality is pretty bad, since it uses PWM to generate the sound. Due to that, its real resolution is in the neighbourhood of 11 bits. We have no use for that.
Use the HDMI port. It works OK, but is useless to us audiophiles.
Use a USB to I2S adapter, such as an Amanero or an XMOS-based device. Now we’re talking. They work quite well, and the quality of the I2S signal is dependent largely on the technology used (CPLD vs. XMOS, etc) as well as the quality of the on-board clocks. The problem is that they add another link to the audio chain, as well as increase the cost. Remember, the RPi is supposed to be a low cost solution.
Use the GPIO pins of the RPi to get direct I2S output. This sounds way more interesting, right? Let’s try that!

According to several sources on the Net, this is the pin out:

You will probably notice that the RPi does not support MCLK output. This means in practice that your DAC will need to have its own on-board clock (or internal PLL / oscillator or whatever). We can live with that.

Luckily, my Buffalo III has its own clock (of course it does!) and thus can be connected quite easily. Let’s try that:

Now we have to configure the software for I2S output. For my distribution of choice, Archphile, it’s a piece of cake: http://archphile.org/howto/i2s-dacs-and-the-raspberry-pi/

Audio playback works just fine!

Well, almost fine..

You see, in theory the RPi has a bit of a problem with its I2S output. Since the only clock onboard the RPi is a 19.2MHz crystal, it should have trouble generating proper clocks for its I2S output. For example, for 44.1KHz audio, the LR Clock must be running at precisely 44.1KHz. That is not possible, since the frequency is not a multiple of 19.2MHz. Thus, the frequency can be either 19.200.000 / 435 = 44.138KHz or 19.200.000 / 436 = 44.0366KHz. This is a limitation of the Broadcom BCM2835 in conjunction with the 19.2MHz crystal and there is nothing that can be done.

In order to confirm the theory, I decided to run a few tests. I hooked up my logic analyzer to my RPi, set it up for I2S output, and fed it some 44.1KHz music.

I took 1 sec worth of samples with my logic analyzer, configuring it for I2S signal. I got this:

The PCM Clock is already appearing a little dodgy. Let’s zoom in:

As you can see, the pulses do not have the same duration. They appear to alternate between two values. So it is obvious that the signal has jitter. A lot of jitter. Since we’re here, let’s have a look at the LR Clock signal as well:

The duration of the pulses appears to alternate between 11.33μS and 11.38μS, giving respectively 44.12KHz and 44.04KHz, values very close to the ones I calculated previously.

So, the theory is sound and the RPi’s clock is not up to snuff by strict standards. What this means is that the RPi’s I2S output is not capable of “Hi End” audio transmission. It is essentially not bit perfect (edit: this is not correct, strictly speaking. It is in fact bit perfect, it is just not “proper”.).

In the real world, chances are that this problematic clocking will not be particularly audible under normal circumstances, say with a normal-specc’ed sound system. But an audiophile should definitely steer clear of the RPi’s I2S output, instead opting for a USB to I2S interface.

The Raspberry Pi: Low cost music streamer

Posted on November 18, 2014 by Dimdim

Enter the Raspberry Pi B+:

It features:

A Broadcom BCM2835 SoC processor running at 700MHz
512MB of RAM
A Micro SD slot for storage
A 10/100Mbps Ethernet port
4 x USB2.0 ports
An HDMI output port
An analog audio / composite video output port
A 40-pin expansion header, exposing 26 x GPIO ports
A camera and a display interface port

Somehow they have managed to cram all that in an almost credit-card sized PCB.

And it costs less than 40€.

It runs Linux (of course..). There is a large number of general-purpose distributions available, as well as a few custom built ones. One of them is Openelec (an XBMC Media Center distro), another one is Volumio (an audiophile music player), a third one is SqueezePlug (it emulates a number of Media Servers, like Logitech Media Server, MediaTomb, MiniDLNA, etc. It also works as a Squeezebox (client)), etc.

So far, my favorite distribution is Archphile, an audiophile linux distribution. It may not have the polished look of Volumio or play 1080p video like Openelec, but is plays music wonderfully through a USB port (or through I2S if you are more of a DIYer).

So, what am I doing with it? I wanted to put a music streamer in my kitchen. I already have two Squeezeboxes in other rooms, so for the kitchen I thought I would try something more interesting.

But along the way, I discovered that it is a lot more useful than that. A very useful (and very rare) feature it has is the ability to bitstream DSD audio (a.k.a. SACDs):

Raspberry Pi B+ outputting DSD to my Buffalo DAC

So now I’m considering adding an RPi network music transport to my main system.

The TFT HiFiDuino Chronicles: 21 months in the making..

Posted on December 14, 2013 by Dimdim

Since the very beginning of my Buffalo III project, I had decided that I would use an Arduino to perform all of the control functions (source selection, volume control, setting of parameters, etc.).

At first I thought that I would just do basic interfacing, that is control the Buffalo by interfacing with the built-in controller. After taking a closer look at HiFiDuino’s work it became apparent to me that direct I2C interfacing was the way to go. Since I wanted to use a better display than the one used in HiFiDuino, I shopped around for a nice color TFT screen. I bought one from Adafruit and got busy. After a few hours of figuring stuff out and coding I got to this point:

The date was March 3, 2012.

On that day I started a thread at avclub.gr announcing my Buffalo controller.

At this point since a number of people had expressed interest in the project I thought it a good idea to look for a less expensive TFT, sourced through Ebay rather than Adafruit. $50 for a 2.8″ TFT is indeed a bit steep. I came across this little gem:

At $20 the price was right, but it was not compatible with Adafruit’s display library so I searched for a compatible library. I came across Harl Henning’s UTFT library which appeared to be exactly what I needed. It was compatible with a large number of TFTs, including the ones that I had on hand. I took care of some signalling issues (the new TFT needed 3.3V signalling but the Arduino Mega is 5V) and proceeded to adapting the code to the UTFT library.
At that time I discovered that HiFiDuino had also just discovered the UTFT library and was planning to use it as well. That was a nice surprise. He had got a hold of a 3.2″ 400×240 TFT which was also available on Ebay so I also ordered one and decided to standardize on that. The date was April 15, 2012. It was Easter.

While waiting for the 3.2″ TFT, I continued my work on adapting the code to the UTFT library. After having tried various fonts, including making a few of my own, I settled on these:

By the end of April the 3.2″ TFT had arrived and I confirmed that it worked. This is what it looked like with no code changes (they would be necessary since I wanted to make use of the total screen real estate).

At that time the weather got pretty warm so I froze all DIY activities for the summer. The DAC was not really finished but it was functional at the time so I was in no rush.
It was not until late November that I resumed the project. The new Arduino Due was becoming available in stores and I was anxious to see whether the improvement in speed would actually translate to real world improvement in Buffalo response times. Before the end of November I had received the Due.

Since the Due was built using 3.3V logic, it was now easier to interface with the 3.2″ TFT and also the I2C lines would no longer need level change to the 3.3V that the Buffalo liked.

At this time I realized that there where 2 obstacles that I had to overcome:

1) The UTFT library was not compatible with the Due.
2) The Due did not have any on-board EEPROM so I could not save my code settings.

The first problem was solved 10 days later when a couple of lovely people at arduino.cc took it upon themselves to make changes to the UTFT library so as to support the Due. The hacked version of the library worked like a charm. I was very impressed with how little time it took these guys to adapt the library.
The second problem I tackled on my own, by adding a 24LC256 EEPROM chip to the design and adapting the code.

This is when I first came up with the idea of designing a custom shield for the controller. It would accommodate the 24LC256 as well as the necessary parts for electrical isolation between the Arduino and the Buffalo.

By mid January I had made sure that my code ran equally well on the Due as well as on the Mega, so I thought that I would produce a short video demonstrating the difference in processing power. That video has since gotten more than 2.000 views per month. Here it is:

By the end of February I had proceeded with polishing the code and had a rough draft of the shield.

About a month later I had a (nearly) working prototype of my new shield:

At that time, once again, the weather got too good for DIY so I suspended the project until September.

While I was on summer leave I got a little bored so I resumed the project. It moved along pretty fast, and soon I had a final version of the shield:

..and a v.1.00 of the code:

I proceeded to release the actual code and schematics for the shield on September 3 & 7 respectively, as well as some basic instructions on building it.

The next step was to make the code more Buffalo-III SE friendly, since most people buying Buffalos were going for the SE. I had one last request: to give the option of always-on, in other word to make it possible to bypass the “on/off” portion of the code. That was pretty easy to implement. At last, I made a few aesthetic changes. The end result was v1.06b, released at December 11, and it looked like this:

(the above screens are from the Buffalo-III SE version of the code)

And that’s it so far.

Dimdim's Blog

DIY Audio, Arduino, Computers, Music

Category Archives: DIY Audio