Category Archives: Information

Hardware vs. Software Volume Control

Some users asked why the HiFiBerry DAC does not support volume control. It is true that the card itself does not come with the volume control widget that can be used by “amixer”. However, most music playback software has its own volume control. How does this work? Basically, the incoming audio samples will be scaled by dividing them by a given value. Dividing by 2 gives an output voltage reduction of 6 dB.

The following picture shows what happens. At the left side is the original, unscaled signal and on the right side a signal that has been reduced by factor 3 (which is roughly a 9db voltage reduction).

sin-fullpfeil200sin-half

With volume control in the playback software, the software will do this scaling and feed the data on the right side to the DAC.

But many people tell me, that is bad! Why is it bad? Because you will lose some resolution. Reducing the volume by 50% means that you will lose 1 bit. The resulting resolution will be only 23 bits now. If you decrease the volume further, you will lose more bits of resolution.

Is it really that bad? Remember, that most music that is available today is still recorded with 44.1kHz and 16bit. That means you can “lose” 8 bit with volume control on the DAC without really loosing anything from your music.

There is another downside of digital volume control: signal-to-noise ratio will decrease. That might be an issue in some areas. But many modern DACs have the noise floor at -110dB or even lower. If this increases to e.g. -90dB it is still a good value.

But some DACs have a “hardware” volume control. Having a mixer control in Linux means, that your software does not have to scale down the samples. The DAC will reduce the output volume. But how does it do this? Just have a look at the datasheets of the chips used on these sound cards. You will notice, that almost all chips with integrated volume control also use digital volume control, that means reduce the volume by dividing the digital data by some number.  This is not better than doing it purely in software.

Summary: Software volume control might have an impact on the audible performance, but with modern 24bit DACs, it often works quite well. Not every “hardware” volume control is really hardware. In many cases, it means that the software scaling is done inside a chip, but works exactly like a software volume control.

HiFiBerry Digi Linux driver

tux_enhanced_penguin_linux_art-1979pxThere wasn’t any hardware development news in the last time. The reason for it was mostly that we spent time developing a Linux driver for our new HiFiBerry Digi S/PDIF output board. And finally the first working version is there. Getting around the mixer controls and the power management (we don’t need both) took us some time. I want to thank Florian Meier personally for the tips he gave during the driver development phase.

Do you want to test if you can compile it yourself? You can download the code from Github (the new driver is in the 3.10 branch).

Build your Squeezebox client with piCorePlayer

Steen Pedersen has updated his piCorePlayer to support our HiFiBerry DAC. piCorePlayer is a Squeezebox client based on a minimal Linux system. It boots from the SD card, but runs completely in the RAM after booting. It also supports WiFi dongles. We tested it with the small Raspberry Pi Model A, that has only a single USB port and used a small LogiLink USB WiFi adapter – it worked very well.

picoreplayer

We can recommend piCorePlayer for all Squeezebox fans!

HiFiBerry DAC support in Raspbmc

logoSam Nazarko has released a new version of the Raspbmc distribution. There are a lot of interesting changes but one is especially exciting to us: It now has ALSA sound card support including a kernel with HiFiBerry DAC support.

We did not have the time to test it yet but we will do this soon! Did somebody test it already?

Are you interested in buying the HiFiBerry DAC – check out our HiFiBerry website. You can order the DAC kit there.

Update 29.12.: It seems that one necessary kernel module for HiFiBerry is still missing in the Rasmbmc december release.  We will check with the Raspbmc developer to see how this can be fixed.

Link

opamp_blockI’ve found this nice article on op amps for audio applications: Op Amps: Myths and facts. It not only gives some information, why there should be no audible differences, but also explains, why there may be audible differences if you simply replace an op amp by a “better” one. That does not mean, there is no need for high-quality op amps, but you should think which characteristics are necessary in which part of your circuit. If you don’t understand how a circuit works, try not to improve it by replacing op amps by more expensive types.

The truth about gold-plated connectors

For the HiFiBerry DAC I was looking for gold-plated RCA connectors. Unfortunately they are hard to source. But finally I got a pair. They are from a well-known manufacture and from a well-known distributor. They are not fakes.

Have a look at it:

goldplated

The outer contact is gold-plated and the inner contact has still a normal nickel-surface. There is nothing wrong with nickel contacts. They usually work well. However, if  the ground contact is gold-plated, I would expect also the other contact to be gold-plated.  Looking at the manufacturer specs, it says “gold ground shell plating”. These connectors are purely made for devices that should look expensive. I guess, there are many devices out there with these or similar connectors.

Optical SPDIF transmission and jitter

One argument against optical SPDIF transmission is jitter. I want to show the impact of a TOSLINK transmission line on jitter. This is a purely visual approach showing the jitter. I do not do exact jitter measurements!

The setup is as follows: A WM8804 drives an Everlight PLT/133 optical transmitter. This is connected via a 2m optical cable to a Everlight PLR/135 receiver. The SPDIF interface chip used an external 27MHz crystal as clock source.

Have a look at these two oscilloscope pictures. The first shows an audio transmission at 48kHz sample rate, the second at 192kHz sample rate .

jitter-48

jitter-192

Interesting difference – isn’t it? At 48kHz sample rate, there is almost no jitter visible, but at 192kHz, there is a lot of jitter.

This shows only, that jitter is measurable. Is it audible? Many modern DAC chips should have no problems with this kind of jitter. But it cannot be excluded, that there might be audible differences, especially on high sample rates.

Apart from the jitter there is one major advantage of an optical digital connection: there is no electrical connection between transmitter and receiver. This means, there is no risk for ground loops, which are usually a bigger problem, than jitter.

What happens, if we use a high-quality sine wave from a function generator as the input? Look at this:

jitter-siggenNo visible jitter! Why does the signal look so much better? Is it only a better signal quality created on the input? I don’t know it yet. But I suppose, that the SPDIF interface chip also has an impact on the jitter. In our tests, the 48kHz sample used an internal master clock of 256xfs, while the 192kHz test used only 128xfs for the internal master clock. Therefore it is possible, that the internal clock configuration of the chip has a major impact on jitter, even with the same external clock source (a crystal oscillator in our case).

There are a lot more questions than answers, e.g.:

  • What is the impact of jitter from the external clock source?
  • Does the internal master clock configuration have an impact on jitter?
  • How do other SPDIF sender/receiver perform?

We will look into some of these aspects in the future.

References:

  1. Wikipedia: S/PDIF
  2. Wikipedia: TOSLINK

Linux 3.10 sucessfully installed on RaspyFi

tux_enhanced_penguin_linux_art-1979pxToday I replaced the Linux 3.8 kernel on my RaspyFi installation by the new 3.10 kernel. Comparing both versions, the sound subsystem for SOC chips is now much cleaner than before. Hardware drivers are the same for “normal” PCs and SOCs. That means drivers developed for the Raspberry Pi can be reused also on all other Linux platforms. Also the driver is split now in a low-level device driver that directly communicated with the chipset and a higher-level sound card driver, that is used for a specific sound card.

At the moment HiFiBerry Mini (now called HiFiBerry DAC) is the only sound interface supported in this version. But I started working on a driver for the upcoming HiFiBerry Digi.
But first lets check out this output:

[email protected]:~$ uname -a
Linux Raspyfi 3.10.19+ #1 PREEMPT Sun Dec 1 14:21:39 CET 2013 armv6l GNU/Linux
[email protected]:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_mini], device 0: HifiBerry Mini HiFi pcm5102a-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

Looks cool :-)

P.S. Upgrading from Linux 3.8 to Linux 3.10 also needs a newer firmware. I will update the kernel compilation guide on the next time.