Today 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 
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.
Florian Meier successfully added support for the HiFiBerry DAC in Linux 3.10. The patched kernel is available on GitHub. The next step will be the integration in the mainstream Raspberry Pi kernel. This may still take time. However, we will provide the patched kernel for major distributions to make it easy for you to use HiFiBerry.
We’re working together with two major Linux distributions focussing on audio and media playback to get the HiFiBerry integrated into these distributions. We will announce these partners when we get their feedback, that HiFiBerry works out-of-the-box with the distribution.
Are you interested in becoming a software partner for HiFiBerry? Contact us!
Our DSP project for the Raspberry Pi has reached the next milestone: hardware prototyping. The digital part of the circuits is working. There was still a minor bug (wrong pinout of a transistor) that was easy to correct by soldering the transistor on its back. The rest of the circuit worked well. As you can see on the picture, the analog part is not assembled yet. First I want to be able to upload the software to the chip.
Unfortunately, the simple approach to upload the program did not work. The chip simply did not acknowledge any I2S requests. Soldering some cables and connecting the I2S bus to the logic analyzer showed some unexpected behavior. While I2C read requests did not work, there was no problem with write requests. What happened? I had a look at the datasheet again and I think, I found the problem. Before every read request, the chip expects a write request with the address to read. However, both requests have to be in the same I2C transaction. The chip expects multiple start bits. Unfortunately, the Python I2C library that I wanted to use does not support multiple starts. It seems that I have to use the lower-level device driver of the operating system to upload the software to the chip.
I just wanted to start to develop a kernel module for the HiFiBerry Mini. But looking at the current code on Github, I noticed, that there is already a driver for the PCM5102A chipset now. This is great news, because it means that the HifiBerry Mini board is supported by the I2S-enabled kernel already. I will do some tests with RaspyFi in the next week to see, how this combination performs.
It looks like a simple task – connect the Raspberry Pi with an external ADAU1701 DSP chip. Both features an I2S interface – just connect it. However, it is not that easy. The ADAU1701 can only work as a slave device on the I2S input. Why not just using the Raspberry Pi as the master? This also won’t work, because the Raspberry Pi can create the BCLK and LRCLK signal, but not a 256xFs master clock signal that is needed by the ADAU1701. Using a local master clock on the ADAU1701 and the I2S clock from the Raspberry Pi will also not work, because both clocks have to be synchronous. Looks like a bit more complexity is needed.
We use the following setup: An external frequency generator creates the 12.288 MHz master clock and a synchronous 3.072 MHz BCLK signal. This BCLK signal will be the master clock for the I2S output of the Raspberry Pi. From this clock signal, the Raspberry Pi creates the 48 kHz LRCLK signal. Why are we not creating this clock externally? Because we have only a 2 channel signal generator available in the lab. This needs some tweaking in the sound card driver.
For measurements I use a Rigol DS2072 DSO and a Intronix Logicport Logic analyzer. That’s a lot of equipment to connect two simple devices:
I had serious trouble to get this setup running. The reason for this was a simple mistake: I switched BCLK and LRCLK. But during debugging I had another idea. The output of the ADAU1701 is an I2S master. That means it can be used also as the master clock for the input. With this setup – output BCLK and LRCLK connected to input BCLK and LRCLK, there is no need for an external clock source. The ADAU1701 can create all the necessary clocks with the onboard resonator. This will simplify our DSP project a lot.
Finally when everything worked, it looked like this on the oscilloscope: a nice analog output from the ADAU1701.
After some work and helpful web resources, one of our Raspberry Pi’s is now generating I2S signals.
You can see, that this is a 44.1kHz playback, the LRCLK frequency is 44.17kHz, the bit clock frequency is 2.778MHz which is about 64x LRCLK (almost, the frequency counter on the oscilloscope is not extremely accurate).
Having a look at the signal curves, you can see that there is a lot of noise and ringing on the signals. However, this is no problem, the voltages are never in the forbidden area.
Another interesting question is: How much jitter do we see on both clock signals? Using the statistics functions on the oscilloscope (which are not the best method to measure jitter) we see a jitter on the clock signal of about 800 ps. On the lower frequency LRCLK, the jitter can’t be measured with my oscilloscope anymore. It is too low – which is a good sign for a high quality sound reproduction.
Many thanks to Koalo and Noise if good for the helpful guide to compile a new kernel with I2S support.
Are you looking for a Raspberry Pi I2S sound interface? Check out our HiFiBerry Mini!
Our HiFiBerry project is still ongoing. The PCB design is almost finalized and we expect the device to be ready in about 4-6 weeks. With HiFiBerry you will get an inexpensive and high-quality sound card for the Raspberry Pi. However, there is one thing it cannot provide: high-resolution sound, that means sampling frequencies above 48kHz are not supported. There are a lot of Pros and Cons for or against higher samples rates than 48kHz. At least when it comes to post processing like equalizing or digital crossovers, higher samples are a good idea.
You could also add an external USB sound card. But we are looking for a real DIY solution ;-) The 2nd revision of the Raspberry Pi provides access to the I2S pins of the processor. You can add an I2S capable ADC or DAC on these pins.
Unfortunately, the Linux kernel of the standard Raspberry Pi does not support devices connected to the I2S pins. Therefore you need to compile your own kernel. Check out the “Noise is good” blog for more information. Hmm, looks like an interesting project for another Raspberry add-on board. We will have a look into this.