[LAU] Sound from/to custom ADC/DAC

[pepijn de vos]

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 at 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 at 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 at lists.linuxaudio.org
>> https://lists.linuxaudio.org/listinfo/linux-audio-user
>>
> --
> Thanks,
>
> Christopher Obbard
> 64 Studio Ltd.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20180311/1addab28/attachment.html>