<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hello,<br><br></div>For a university project we're building a custom audio system with our own input and amplifier.<br></div>We will most likely use an FPGA that communicates sound data over SPI to a Raspberry Pi.<br></div>On the Raspberry Pi the sound can be further processed by for example Sonic Pi.<br><br></div>Sonic Pi uses SuperCollider which uses JACK which uses ALSA.<br></div>At some point in this chain we need to be able to interface with our FPGA.<br><br></div>Initially I thought it would be easy to write a JACK client, and it is.<br></div>The problem with that seems to be that JACK is in control of the sampling rate.<br></div>So if I read data from the FPGA into a buffer and the clocks drift, I get overruns or underruns.<br><br></div>I found a few potential solutions.<br>What alsa_in and alsa_out do is resample between the two clocks. Maybe a bit of work, but definitely works.<br></div>There is some business about clockmaster in JACK, which seems to be something different, but maybe I don't understand it.<br></div>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.<br><br></div>If all of the above turns out to be bad ideas, I need to look at a different location in the chain.<br></div>It would make sense to write an ALSA driver for what is pretty much a custom sound card.<br></div>However, it seems that writing an ALSA driver is orders of magnitudes more complex than registering a callback with JACK.<br><br></div>Any ideas what would be the easiest way to get sound from our FPGA into SuperCollider and back?<br><br></div>Regards,<br></div>Pepijn de Vos<br></div>