Re: [LAU] Sound from/to custom ADC/DAC

Thanks for the advice so far.
Based on this post, I managed to make my own I2S overlay.
https://www.raspberrypi.org/forums/viewtopic.php?t=189152

However, still only two channels.
I found that the Pi can in fact understand TDM, but the SoC can only get 2
of the channels for some reason.
https://github.com/raspberrypi/linux/pull/1982

For the Beagle Bone, I also found someone who makes a cape with a lot of
inputs and outputs.
There are some forum post scattered here and there with references to
McASP, as you mentioned.
This overlay seems a good starting point, potentially:
https://github.com/ctag-fh-kiel/ctag-face-2-4/blob/master/device-tree-overlays/BB-CTAG-SW-8CH-00A0.dts

So to sum it up, I2S works on the Pi for 2 channels, Beagle Bone is
something to look at more closely.

Pepijn

On Wed, Mar 14, 2018 at 3:35 PM, Chris Caudle <chris@email-addr-hidden> wrote:

> Server rejected this the first time for some reason, resending
>
> On Sun, March 11, 2018 8:35 am, pepijn de vos wrote:
> > The problem with that seems to be that JACK is in control of the sampling
> > rate.
>
> I think you are missing a fundamental aspect of how audio hardware works.
> The device which converts to and from analog is always in control of the
> sampling rate. When you say that jackd is in control of the sampling
> rate, what that really means is that jackd is following the sampling rate
> dictated by the device which you have told jackd to use as the backend.
>
> > It would make sense to write an ALSA driver for what is pretty much a
> > custom sound card.
>
> Either an ALSA driver or a custom jackd backend.
> The only way that makes sense for audio data transfer to work is that the
> audio hardware fills a buffer then signals to software that the data is
> ready to be read. In the other direction the audio hardware converts a
> buffer of data to analog then signals to the software that it is ready to
> have another buffer filled. Unless the software is capable of filling a
> buffer of data in less time than one sample period (hint: it is not) that
> implies at least two buffers, one which is being read by the hardware and
> converted to analog a sample at a time, and another buffer which the
> software can fill while the first buffer is being converted to analog.
>
> --
> Chris Caudle
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> https://lists.linuxaudio.org/listinfo/linux-audio-user
>

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Jun 18 21:49:15 2018