[LAU] Jack - buffers V periods

[Will Godfrey]

On Wed, 17 Jan 2018 20:21:55 -0500
Tim <termtech at rogers.com> wrote:

>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.

Very interesting info here, but I'm trying to understand a scenario where you'd
want different latencies within a single environment.

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.