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