After going thru internal discussion about if we
need to include BT audio receiver we found that in the
last 5 years BT has changed so much and will continue to change.
If we include it inside the chassis we would most
defiantly obsolete our hardware in the next 3 years when
better BT technology like BT HD or the next version APTx
comes along. So we decided to include BT as a plugable external
component. This way when a better BT module comes along
we can always easily replace it.
We decided to do the same with google chrome cast audio too.
This is also available as an external component.
The Player uses its preamp switching circuit to seamlessly switch
between the internal digital transport and external devices
like BT module, Chrome cast Module, Airplay etc.
From the end-user perspective all these modules are integrated
into a seamless software interface.
The added benefit of using external modules is that we don’t
have ugly antennas poking out and we get very good WiFi and
Bluetooth signals.
How well a system performs depends a lot on how well you feed it, this is true for living organisms , automobiles and electronics. When We started exploring the best way to power our Player, we had to choose between SMPS and Linear power supplies. Linear power supplies use large transformers and an elaborate rectification and filtering circuit which allows the pre and power amps to perform well. Noise in the power supply will eventually trickle into the audio signal and will become audible. For example if there is a 100mv power supply ripple noise in the power supply on a 1v Peak to Peak audio signal that is 10% of the signal and will get amplified by the power amplifier just as much as the audio signal.
The advantages of Switch mode power supplies is that they are small and efficient so for a given amp rating, the power supply is much smaller. The downside is that it is pretty noisy.
On the other hand linear power supplies can be very quiet but if the current requirement is large then we need large heavy transformers and big filtering circuits. Large transformers come with their own problems of noise and EMI interference in sensitive pre-amp circuits if they are wired too close.
We stared testing and measuring various power supplies to evaluate the performance and found that SMPS was pretty noisy , linear power supplies were quiet but even their noise level started increasing when we increased the current draw (power).
We needed about 5v 3 amp for the SBC , 5V 50ma for the DAC and about +/- 15 100ma for the preamp. We initially wanted to use a single linear power supply but found that whenever the SBC’s power consumption increased when WIFI was active or when a large file was being downloaded, it increased the noise floor of the Linear Power supply. This introduced the noise into our pre-amp circuits.
So we decided to use two power supplies one for SBC and one for the DAC and the Preamp, we ended up using two transformers one with a 5A rating and one with a 1A rating, this created additional headaches of EMI HUM noise from the transformers. So we decided we needed a simpler solution.
Solution: We are using a 5v 10A SMPS for the SBC, MCU for Remote, Front panel, protection circuits, Input and speaker Switcher Relays,where the audio signal never travels.
We have a separate Linear power supplies with a torroidal transformer to supply power for the DAC and the Preamp. Thiese power supplies have CRC filter ,CLC filters and large power caps to ensure extremely low noise (less than 5mv and full power draw).
We have taken extreme care to ensure the transformers are as far away as possible from our sensitive audio circuits.
This is the Power supply board for the DAC with +5V
This is the +12 / 0 / -12 Supply for the Preamp. We can adjust the voltage up to +/- 18 V based on the opamps used.
Here we can see the measurements , This is the Noise in SMPS, this about 216mV . The frequency displayed is of the switching frequency of the SMPS.
Closer Look at the Waveform (250nS).
This is using a Linear PSU where the Noise is reduced and is around 17.2mV. and you can see the frequency is more closer to the AC Supply Freq.
This is the Noise level after CRC and CLC Filters. at just 6.4mV.
To evaluate the performance of various DACs and AMPs we decided to measure them. Our Measurements are not extremely accurate,but accurate enough to give us relative performance numbers in our setup so that we could make an informed decision. We knew the manufactures had provided the numbers but we wanted to ensure that we chose the right combination for our player.
Once we finalized the SBC the next important thing was the DAC. Choosing a DAC was not as easy as choosing the SBC, it is very subjective selection process. DAC Sound quality changes between DAC chips and Analog front ends and some are liked by some and some are hated, So we had quite a complex task ahead of us.
We took a non scientific approach of doing listening tests with people from all age groups and backgrounds (audiophile/casual/ipod listeners). We played music from all genres like Rock ,Pop ,Classical, Ilayaraja , AR Rehman etc and got their feed back.
The DACs we tested were
Burr Brown PCM PCM5122 in Slave Mode. (Allo Piano )
PCM Dacs were smoother and warmer.
The best sounding PCM DAC was the Allo BOSS.
The Piano and the PCM Module did not sound as good on
Hires and 44.4 FLAC files. For MP3 it sounded good enough.
The BOSS DAC had the warmth and depth we were looking for without compromising on the clarity. It was also non fatiguing.
ESS DAC had the best hi frequency resolution , the highs were very clear
and crisp but was fatiguing after a few songs. The younger listeners hated it
since they were very sensitive to the Highs and thought it sounded too harsh.
We could tame the harshness with the analog filters. The high freq characteristic is something we have seen in other ESS DAC like the SABRE DAC from Youlong. ESS felt like it had some unfiltered HF artifacts.
AK DAC This had the best audio quality but needed I2S input with clock which the RPI3 did not have so we used a XMOS USB to I2S converter to get the I2S. This DAC had the warmth ,clarity and had the best tonal reproduction.
So we decided to go with the Allo BOSS for our Rasa Player and AK4490EQ for our reference player.
We at Rasa decided that we will use two Platforms one for Affordable RASA Player and one for High End Reference Player. Our needs were a powerful SBC hardware with good Software stack.
Features we identified for our affordable player included
1) Powerfull Quad or higher core SBC ( 1.2 gHz or higher ) with atleast 1GB RAM.
2) Ethernet port.
3) USB port.
4) I2S Port.
5) Mature OS and Distro.
6) Good Software support.
We Evaluated the following SBCs for the RASA Player.
Allo Sparky
This had the same form factor as RPI and had good performance.
Had I2S and the RAM we required, but we were not comforable with the
maturity of the Software stack.
Orange PI (PC)
Good inexpensive boards but unsatisfactory sofware support
Banana PI
They are similar to Orange PI and use somewhat similar SOCs
from Allwinner on the low end ones.
Raspberry PI 3
We decided to go with this because it was inexpensive with
very good software support and a vibrant community. It had I2S for
connecting to DACs. Companies such as allo have good Reclockers and
DACs.
For RASA we will be using the I2S on RPI3 to drive the DAC
directly. With a custom analog section built using high quaity
discrete components. We would be using low tolerence thru hole
components for all passives. For the DAC we have selected
the PCM 5102a . There is a blog article on how we chose this
DAC here.
We Evaluated the following SBCs for the Reference Player.
Features we identified for our High End player included
1) Powerfull Quad or Octa Core SBC ( 1.6 gHz or higher ) with atleast 2GB RAM.
2) Ethernet port.
3) USB port.
4) I2S Port (Optional).
5) Mature OS and Distro.
6) Good Software support.
BananaPI M3
We decided to go with this because it had an Octacore chip
with 2GB ram. The cores automatically throttle down when not in use
but do get very hot when you push them. We had to comeup with a good
heat sink to allow all the cores of the M3 to run at full speed for
long times. If the heat sink was not adequete, the cores would hit the
thermal protection and scaled down their speed (clock frequency).
When we used it continually we started noticing issues like boot problems when USB DAC is inserted .
Getting to compile the kernel was painfull to say the least.
The compiled kernel will not boot , so after contless hours of researching
we found that you have to use an older version of GCC to compile.
The GCC that comes with the SDK wont do.
RPI3
Not enough horsepower to run our Remote Browser Player.
Intel Atom Motherboards.
Too big and too power hungry , would require a ATX SMPS
or noisy DC to DC converters.
Intel NUC Board
We finally decided to use this since it was compact and easy to power.
In the player we decided to use the USB to I2S XMOS solution.
As XMOS reclocks the data based on the sample rate (44.1 or 48) we found
this to be a better solution than to use I2S directly from the SBC. We
use high quality clocks on the XMOS board to ensure very low jitter.
In the previous article we saw that Pulses of Clock and Data are used for communication between digital systems. Now lets look at how SPDIF / TSOLINK works when transporting digital audio data from a Source (say a CD Player) and the destination (say AVR or DAC).
As we can see there is only one signal line in SPDIF, for optical there is one fiber that pulses laser light and in case of RCA it same data is sent over copper.
So we can see that the data is actually asynchronous data where the receiver figures out the speed of the data using some techniques (PLL or Phase locked loops). This way the sender can send the data and the receiver can figure out the speed by looking at the data and figure out its own clock and then use it to reconstruct the data.
As we saw already digital signals are pulses
https://i.stack.imgur.com/rTpKu.png
When this pulse goes over a copper cable and reaches receiver, based on the capacitance of the cable the square wave pattern will change where the voltage will rise gradually instead of instantly.
When this happens if the pulses are too close together (high frequencies) the pulse will start falling before it reaches full potential so the receiver will never register it, so hi-frequency data will get lost.
This is the reason you will see sometimes the optical cables have better hi-freq response than a bad coax copper cable.
In this series of posts we will see how a digital file is converted to music. We will see also see what parameters affect the quality of music we listen to.
Digital Communication
There are two broad ways in which digital systems communicate (in this context).
Parallel
In parallel communication each bit of the number being sent has a separate physical wire between the sender and receiver and a seperate line that tells the receiver when to pickup the data (Clock). In this system the sender sets the all bits (say 8) of the data to send and tells the receiver to pick it all up in one go. so for each clock pulse 8 bits are transferred. This is how old Printers with Parallel port used to work. In these systems there are as many data lines as there are bits Widths to send. For example PC Parallel ports have 8 Data Lines.
Serial Most of the systems these days have switched to a serial way of sending data where there is only one data line and the data is sent one bit at a time. There are two types of serial communication, Synchronous and Asynchronous.
In ASynchronous communication both the send and receiver decide on the speed of communication and send and receive the data. This speed is called bits per second or baud. All PC Serial ports work this way. A start and stop bit allows the receiver to figure out when the bit starts and bit ends.
https://en.wikipedia.org/wiki/Serial_port
Baud rates are from 300 bits per second to 460,800 bits per second. The problem here is that there is no synchronization between the sender and receiver except for agreed upon speed. So if the sender or receiver are expecting the data at a wrong speed they will get only garbled corrupted data. This is what happens when one PC is sending data at 9600 baud and another PC is expecting at 115200 baud.
Two things are required for this type of communication to work, both the sender and receiver should agree on the speed and should have clocks which are accurate.
There is only one data line for unidirectional communication and two data lines for full duplex bidirectional communication.
One more way the receiver can work is by rebuilding a clock from the data using PLLs (Phase locked loops) and use this to time the data.
SPDIF is a synchronous protocol where the receivers reconstruct the clock using PLLs.
Synchronous Communication is similar to parallel communication where a separate clock line tells the receiver when to pick up the bit (instead of the byte) so now the senders and receivers don’t have to agree on anything . They can have not so accurate clocks and still the data will reach the receiver pretty reliably.
There is one data line and one clock line for communication. The clock tells the receiver when to pickup the data from the dataline.
As we can see Synchronous Communication is better as the sender and receivers do not have to agree on anything prior to communication and changes in speed will not affect the data integrity.
In this series of posts we will see how a digital file is converted to music. We will see also see what parameters affect the quality of music we listen to.
First this would be the process.
MP3, FLAC or WAV file is parsed (decompressed if needed) by a computer (or a streamer ) and converted in to a PCM Stream (We will see how DSD works later). PCM stands for pulse coded modulation. In PCM a number that represents amplitude (loudness) of sound at a particular instant is sent few thousand times a second (for CD it is 44,100 times a second). This is called the sample rate. So when we say 16 bit 44.1 Khz PCM stream , it means that the stream has 44,100 numbers for each second of music . The numbers range from 0 – 65,536 or (−32,768 to 32,767) which is 2^16.
So a loud region will have numbers close to 40,000-60,000 and silent portions will have numbers less than 3000.
The digital signal is a square wave where Bit 1 is represented by 5v and Bit 0 any voltave <~2.5 , 8 such pulses(bits) from one byte of data.
https://i.stack.imgur.com/rTpKu.png
These numbers are fed into a DAC (digital to analog converter), which converts these numbers in to voltage levels ranging from 0-2v (assuming 2v Peak to Peak output) . This analog signal is fed into an amplifier which in turn drives the speakers.
So this system depends on getting those numbers into the DAC in a timely fashion without corruption.
We can assume that Digital Hi Resolution file we get has the correct data since it is not under our control anyway, our objective in our system is to get this data as perfectly as possible to the DAC.
In our system let assume that we have a Streamer (PC or Dedicated Transport Device) which will give the raw decompressed digital data. The data might be sent over USB , SPDIF over Optical or COAX , I2s , HDMI etc based on the device.
you would connect a USB DAC or USB to spdif converter to the Transport to get the data out. Here the type USB receiver is very important.
After adding DLNA Controller Support , we have added the SMB (Windows Sharing) and NFS Share support for playing files from NAS. We found that this is actually faster and easier than using DLNA servers since there is always a indexing lag from the time you copy the files to the server to the time it actually appears on the player. With SMB or NFS files appear instantly and it much faster to browse. We can always use folders to organize our collection.
Would you want to wait 10 minutes for the player to be ready before playing a file ?
Well the answer is NO.
When a disk is inserted in to most players , they start indexing. A process where they go thru each and every file in each and every folder and read the ID3 tags in them like album artist genre etc. This is time consuming and prevents the users from playing music right after inserting the disk. If a player tries to do this in the background it will interfere with the player trying to read the disk to play the file. You will have two processes contending for the disk access, the player to play the file, the Indexer which is making the disk read each and every file. The caching mechanism in the OS is useless for the indexer since it reads one file only once so the OS needs to keep dumping its cache. This is the reason you will see the Drives continually run during the indexing process.
We made a clear decision not to index the tags for USB disks, so when you insert the disk you can play files on them instantly. Only once process access the disk and that is the player. We assume most disks users insert will already have well organized folders that they are familiar with. We would still display the tags when the song is played, just not when the disk is inserted. This saves so much time and frustration when playing files from the USB disks.
