Peufeu's Electronic Stuff Unfinished projects since 1912

Slaving software is done : the software in question is a simple test Python program which opens a pipe to the flac decoder and reads the samples from it, which it then properly formats and sends to the DAC.

Wire format is simple : a packet contains a packet ID, magic string, checksum, and number of chunks (chunk type, length, contents) which can be data, status info, and commands.

Checksum is computed by the onboard hardware (it adds a few lines of code in the DMA engine which shuffled data to and from the network chip).

I had to add a checksum and magic string packet ID because Windoze keeps flooding the network with file sharing UDP noise and sometimes the DAC would get some and try to parse them... The checksum also helps for debugging : at first it failed, which meant too tight bus timings. Once I had transferred a few gigabytes without checksum errors I could

Synchronization with the DAC is very simple : about 1000 times a second the DAC sends a data and status packet. If ADCs are activated, this contains ADC data, but it always contains streaming information :

- how many audio clock beats have occurred since the beginning of the stream
- how many samples the DAC has in its onboard buffers. Onboard FIFO is 16 MBytes of SDRAM and 8-16 kbytes of superfast dual port on-chip block RAM.

For low-latency synchronization (in the tens of ms), the clock count information must be used. I will do this when I write a JACK driver.

For simple audio listening (ie not synchronized with video), a latency of, say, 0.2 s is perfectly acceptable, so my test program just uses the second information. If it sees the buffer contents get below a threshold, it sends data. If not, it waits. Synchonization is thus obvious.

This simplifies embedded programming too. The DAC does not request data. If it sees data coming, it stores it ; it also streams from the FIFO to the DAC. It sends ACKS, which are ignored by the PC (there are no lost packets on a LAN unless you mix feet and wires). So it is up to the PC to decide the how much data there should be in the DAC buffers.

The PC can also send commands like, stop and reset buffers, start buffering, start playing, etc.

The onboard software had to fit in 48 KB RAM including all the buffers, so it is as simple as possible. There is no command for changing sample rate or number of channels, for instance. Instead, there are Peek and Poke packets which allows the PC to read and write memory addresses in the onboard peripherals.

This simple Python program is pretty robust, and I only got buffer underruns when launching a Java application on the PC.

Since making your machine grind is a feature of Java, I think it's okay.