Hey,

Paul, the only clock I care about is the FPGA clock, so if I can tell JACK to use my clock and just ignore ALSA, that would be fine.

But that probably involves writing a JACK backend, which is probably not much easier than writing an ASLA driver.

Chris, I was unaware of I2S, it seems perfect for our purpose!

Thank you! That probably saves me a ton of trouble.

I looked into I2S support on the Raspi and the BBB a bit, and found surprisingly little.

For the Raspi there seem to be some device tree overlays for specific ADC and DAC boards, but it's unclear how to use for our custom FPGA.

For BBB it seems to be supported somehow, but not much info on how to actually use it.

My main concern is that I need more than two input channels and at least one output channel.

I'm unable to find out if either board supports more than one I2S device (each device can be stereo it seems)

Regards,

Pepijn

On Sun, Mar 11, 2018 at 2:45 PM, Chris Obbard <chris@64studio.com> wrote:

Hi Pepijn,
Why not make the FPGA talk i2S to the Raspberry Pi?
There is already a neat SoC driver there that can do a couple of channels.
The beagle bone I2S is a lot more comprehensive.

Why reinvent the wheel?

Cheers!
Chris

On Sun, 11 Mar 2018 at 13:36, pepijn de vos <pepijndevos@gmail.com> wrote:
Hello,

For a university project we're building a custom audio system with our own input and amplifier.
We will most likely use an FPGA that communicates sound data over SPI to a Raspberry Pi.
On the Raspberry Pi the sound can be further processed by for example Sonic Pi.

Sonic Pi uses SuperCollider which uses JACK which uses ALSA.
At some point in this chain we need to be able to interface with our FPGA.

Initially I thought it would be easy to write a JACK client, and it is.
The problem with that seems to be that JACK is in control of the sampling rate.
So if I read data from the FPGA into a buffer and the clocks drift, I get overruns or underruns.

I found a few potential solutions.
What alsa_in and alsa_out do is resample between the two clocks. Maybe a bit of work, but definitely works.
There is some business about clockmaster in JACK, which seems to be something different, but maybe I don't understand it.
There is a freerunning mode, which makes it OK to do IO in the callback. I'm not sure if this plays well with SuperCollider. It seems that in this case the processing is directly driven by how fast I get data from the FPGA, which is what I want.

If all of the above turns out to be bad ideas, I need to look at a different location in the chain.
It would make sense to write an ALSA driver for what is pretty much a custom sound card.
However, it seems that writing an ALSA driver is orders of magnitudes more complex than registering a callback with JACK.

Any ideas what would be the easiest way to get sound from our FPGA into SuperCollider and back?

Regards,
Pepijn de Vos
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user

--
Thanks,

Christopher Obbard
64 Studio Ltd.