Deciding on a SBC.

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
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.

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.

Digital Communication , Audio (Why Digital Cables matter, slew rate , optical/copper)

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

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.


Digital Communication , Synchronous vs ASynchronous.

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).

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.

 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.


ASynchronous Serial Communication. (c)

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.

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

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.


How Does the music get from a Digital File to the Speakers ?

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.

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.

For more details you can read

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.

For more details you can read


Windows (SMB) & NFS Shares

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.

To Index or Not To Index ID3 tags.

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.

Technical Details

We are in the process of shortlisting the DACs and SBCs (Single Board Computer). Our initial design requirements looks like this.

A 32 bit 384KHz DAC , If the DAC is designed to play 34 bit 384KHz music really well, it will be awesome at playing 44.1/48Khz . Which is most of our music anyway.

Fully isolated power supplies for the SBC and the DAC. We would be using Linear supplies for both and a shield will separate the DAC and SBC boards to avoid EMI from the SBC corrupting the signals on the DAC.

We would be using the highest audio grade passive components in the analog section.

The SBC would use a Quad Core Processor with one core dedicated for the player by making it run at RT priority. At-least 1 GB of RAM.

The design would move the UI management to a separate Processor to keep the SBC free to only play the media, buffer etc. Most media player software available now tend to over load the main CPU with UI driving tasks, making it more prone skipping lockups etc.

To avoid IO bottlenecks, The player would move the files from the USB / Server to Ram-disk before playing so network / USB bottlenecks do not affect the playback.  It will also buffer other songs in the playlist in the background to avoid skips and delays.

The USB drive would support Drives up to 4TB with GPT and filesystems like FAT , FAT32, NTFS , EXT2, EXT3, EXT4.



Welcome to Rasa Audio .

We at Rasa have set ourselves a  mission to bring Great Audiophile Gear to Everyone.

As our first endeavor, we are building a Flagship Digital Audio File Transport and player. The player can play files from 128k MP3s to FLACS and DSD/DXDs up to 32bits, 384Khz. The player can play files from USB disks and stream files from uPNP servers on NAS. The stream will be avaialbe on SPDIF and TOSLink to feed it your DAC. We will also have variants with DAC + Bluetooth (BT4 with aptx) + PreAmp with analog Volume control.

UI will be completely controlled by a standard IR remote, no need for Smartphone or Keyboards or Mice or Touch Screens. From the Listening position you will be able to change tracks albums using the remote instantly. No need to unlock the phone open the app wait for it to connect to just skip to the next track. I would be as simple to use as a CD player. Just plug in your music on thumb drive into the USB port and use the remote.