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@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user