Today I spent several hours looking for a hardware problem of the HiFiBerry DAC. I had a quick look at the I2S line and the power supply – everything seemed to be ok. After some hours testing I noticed, the the sound output was working with FLAC files, but not with WAV files. WTF? At least it was clear now, that I should look for a software problem, not a hardware problem.
Here is a picture of the BCLK and LRCLK lines when playing back the FLAC file:
And this is the playback of the WAV file:
Can you see the difference? In the second scope picture you can see, that the driver only creates 20 clock cycles for the left and the right channel, in the first case there are 32. Because the DAC supports only BCLK=64xLRCLK, it does not create any output in the second example.
Therefore, when debugging I2S circuits, not only have a look if there is a signal on all lines, but also check, that the clock frequencies are correct.
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.