If you need a cheap solution for just audio out, you can try a TDA1543 (a very common and cheap, 16-bit, stereo, I2S DAC @ 9Mhz Max). Couple of days ago I managed to play an mp3 using the command:
ffmpeg -i file_name.mp3 -f alsa "default:CARD=Black" -re -vol 20
Yes, it did sound like crap, for it was on a perf-board, connected with crappy wires, output was cheap passive I/V, and the connections to the BBB was also long and prone to lotsa noise on my desk.
I got the clock signal from pin 31 on P9, and divided it by four, using two D-Flip Flops (both in a 74HCT74, PIN31 provides the clock for the HDMI Framer Processor, and it’s at 24.576MHz). The rest of the signals are at the links below. Recently, I designed a good PCB for the whole thing (using a NE5532 for outputs), and hopefully I’ll get better results when I print it.
This page was rather helpful for me:
I don’t think pin 31 is a 24.576MHz clock. The sys ref manual says that the clock is DERIVED from Y4, which is 24.576MHz, but the pin 31 clock is the real I2S synchronous audio clock.
I think using those two FFs to divide that clock by 4 is a mistake. I think that AP0(SPI1_D0) should be connected directly to WS, AP1(SPI1_CS0) should be connected directly to SD, and ACLK (SPI1_SCLK) should be connected directly to SCK.
The framer pixel clock really comes into the TDA19988 on pin 4 of the chip as LCD_PCLK.
If the clock on pin 31 is faster than 9MHz, you simply need a faster I2S DAC (but I suspect your DAC is just fine).
If your breadboard is still together, you should try bypassing that divider chain and see if the audio improves. If you report joy, I’m going to order a few DACs!
Actually, I’ve looked into this further, and the pin 31 clock could be 24.576MHz. I looked at two different I2S DACs…
If the audio sample rate is 48KHz, then the interface looks like it would match up well with a Max5556 I2S DAC. That particular DAC has internal PLLs and wants an MCLK at a rate of either 256 or 512 times the sample rate. Edges line up with 16 bit audio, but this chip (and really all I2S DACs) can accept 24bit audio too, even if it is a 16 bit DAC (the LSBs are discarded). The PLLs must clock things different internally if 24 bit data is sent to the DAC…
OK, so looking at the TDA1543 datasheet, the timing diagram shows that the clock input is expected to be synchronous with the data input (no PLL). This means that for a (24.576/4) = 6.144MHz clock, if you have two channels of 16 bit data (32 bits), the sampling rate would be 6.144MHz/32 = 192KHz. So, if the audio sampling rate is 192KHz, your divide-by-four clock is the correct frequency.
However, there is still one more worry. When you divide a clock down asynchronously like that, the clock-to-data phase relationship after power on or reset will come up in one of four random states. Only one of those states gives you the optimum timing margin for clocking in your data. If you are violating some setup and hold times, that could cause messed-up audio.
I verified tonight that the MAX5556 DAC appears to work. I am getting some very low level clicks occasionally, but overall the sound is very good. I just did a quick and dirty prototype tonight on a solderless breadboard. The digital lines were kept short, but the grounding was far from ideal for a digital/audio interface. I will move the setup onto a proto-cape board with a groundplane next and do an eval of the signal integrity of the digital interface with a slope.
In a perfect world, there would be some ground pins near the mcasp pins to take the digital return currents.
Everything I have thrown at mplayer seems to be converted to 48KHz by alsa. If that is universally true, that would be a good thing™ because I think the MAX5556 setup depends on the clock ratios resulting from that scheme.
I’ve linked a picture. The MAX chip is on the bottom (made a header assembly out of a 16 pin DIP socket). The other SO-8 chip (on the top) is a dual op-amp that is unused so far. I came out of the chip outputs, through 560 ohm series resistors, and straight to earphones.
I did nothing to change the pin configuration of the card, so if this doesn’t totally mess up the signal integrity of the signals going to the HDMI chip, it MIGHT be possible to have both HDMI and embedded audio at the same time.