[LAU] Jack - buffers V periods

Tim termtech at rogers.com
Thu Jan 18 01:21:55 UTC 2018



On 01/17/2018 08:04 PM, Paul Davis wrote:
> 
> 
> On Wed, Jan 17, 2018 at 7:37 PM, Tim <termtech at rogers.com 
> <mailto:termtech at rogers.com>> wrote:
> 
> 
> 
>     On 01/17/2018 06:58 PM, Will Godfrey wrote:
> 
>         I'm getting a little confused when comparing our (Jack) buffer
>         sizes with those
>         discussed on Windows, Mac and general music groups.
> 
>         These latter never mention periods at all, and it's always
>         frames per buffer,
>         so when trying to make comparisons should I take buffers as 1:1
>         or should I be
>         comparing their buffers to our periods?
> 
> 
>     Hi Will.
> 
>      From memory on Windows years ago, and if I understand Jack correctly,
>       Jack, or more specifically ALSA (in this case let's say using the
>       ALSA driver), puts you much lower-level towards the sound hardware.
> 
> 
> ​while true, this is not necessarily a benefit.
> 
> the better design here is to completely decouple everything as much as 
> possible from device interruptsm and use DLL's to provide sub-sample 
> accurate "prediction" of where an application can read and write at any 
> time.

Ha! Yeah I remember experimenting with that sort of thing.
Like you're in a race with the DMA pointers. Nice we could read them.

> this allows you to have multiple applications using different buffer 
> sizes (different latency), and to get better latency than the device's 
> inherent interrupt intervals would allow.

I've mused a few times about whether it would be possible to do
  this with Jack midi when using large Jack buffer sizes ;-)
It's ironic because MusE supports both Jack midi (at say 2048 buffer)
  and ALSA midi (with say 1024 Hz timer) at the same time.

> it's what coreaudio does, and ALSA should do it too. i doubt if it ever 
> will. pulse sort of does this, but all in user space.​

How might sample rate conversion fit into this? Does it make it easier?
Or no difference, they might slap it on ahead of or after this layer?
So that say, we might not need the ALSA mixing layer (I forget what
  it's called, dmix?).

T.


More information about the Linux-audio-user mailing list