<div dir="ltr"><div><div><div><div><div><div>Thanks for the advice so far.<br></div>Based on this post, I managed to make my own I2S overlay.<br><a href="https://www.raspberrypi.org/forums/viewtopic.php?t=189152">https://www.raspberrypi.org/forums/viewtopic.php?t=189152</a><br><br></div>However, still only two channels.<br></div>I found that the Pi can in fact understand TDM, but the SoC can only get 2 of the channels for some reason.<br><a href="https://github.com/raspberrypi/linux/pull/1982">https://github.com/raspberrypi/linux/pull/1982</a><br><br></div>For the Beagle Bone, I also found someone who makes a cape with a lot of inputs and outputs.<br></div>There are some forum post scattered here and there with references to McASP, as you mentioned.<br></div><div>This overlay seems a good starting point, potentially:<br><a href="https://github.com/ctag-fh-kiel/ctag-face-2-4/blob/master/device-tree-overlays/BB-CTAG-SW-8CH-00A0.dts">https://github.com/ctag-fh-kiel/ctag-face-2-4/blob/master/device-tree-overlays/BB-CTAG-SW-8CH-00A0.dts</a><br><br></div><div>So to sum it up, I2S works on the Pi for 2 channels, Beagle Bone is something to look at more closely.<br><br></div><div>Pepijn<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 14, 2018 at 3:35 PM, Chris Caudle <span dir="ltr"><<a href="mailto:chris@chriscaudle.org" target="_blank">chris@chriscaudle.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Server rejected this the first time for some reason, resending<br>
<span class=""><br>
On Sun, March 11, 2018 8:35 am, pepijn de vos wrote:<br>
> The problem with that seems to be that JACK is in control of the sampling<br>
> rate.<br>
<br>
</span>I think you are missing a fundamental aspect of how audio hardware works.<br>
The device which converts to and from analog is always in control of the<br>
sampling rate.  When you say that jackd is in control of the sampling<br>
rate, what that really means is that jackd is following the sampling rate<br>
dictated by the device which you have told jackd to use as the backend.<br>
<span class=""><br>
> It would make sense to write an ALSA driver for what is pretty much a<br>
> custom sound card.<br>
<br>
</span>Either an ALSA driver or a custom jackd backend.<br>
The only way that makes sense for audio data transfer to work is that the<br>
audio hardware fills a buffer then signals to software that the data is<br>
ready to be read.  In the other direction the audio hardware converts a<br>
buffer of data to analog then signals to the software that it is ready to<br>
have another buffer filled.  Unless the software is capable of filling a<br>
buffer of data in less time than one sample period (hint: it is not) that<br>
implies at least two buffers, one which is being read by the hardware and<br>
converted to analog a sample at a time, and another buffer which the<br>
software can fill while the first buffer is being converted to analog.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Chris Caudle<br>
______________________________<wbr>_________________<br>
Linux-audio-user mailing list<br>
<a href="mailto:Linux-audio-user@lists.linuxaudio.org">Linux-audio-user@lists.<wbr>linuxaudio.org</a><br>
<a href="https://lists.linuxaudio.org/listinfo/linux-audio-user" rel="noreferrer" target="_blank">https://lists.linuxaudio.org/<wbr>listinfo/linux-audio-user</a><br>
</div></div></blockquote></div><br></div>