[LAU] Ardour session with plain ALSA, without JACK

[Markus Seeber]

On 02/19/2016 11:46 PM, Robin Gareus wrote:
[...]

> 
>> Usually I use 48KHz p256 n2:
>> [rocketmouse at archlinux ~]$ jackd -dalsa -dhw:0 -r48000 -p256 -n2
>> jackdmp 1.9.10
>> Copyright 2001-2005 Paul Davis and others.
>> Copyright 2004-2014 Grame.
>> jackdmp comes with ABSOLUTELY NO WARRANTY
>> This is free software, and you are welcome to redistribute it
>> under certain conditions; see the file COPYING for details
>> no message buffer overruns
>> no message buffer overruns
>> no message buffer overruns
>> JACK server starting in realtime mode with priority 10
>> self-connect-mode is "Don't restrict self connect requests"
>> audio_reservation_init
>> Acquire audio card Audio0
>> creating alsa driver ... hw:0|hw:0|256|2|48000|0|0|nomon|swmeter|-|32bit
>> configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 2 periods
>> ALSA: final selected sample format for capture: 32bit integer little-endian
>> ALSA: use 64 periods for capture
>> ALSA: final selected sample format for playback: 32bit integer little-endian
>> ALSA: use 64 periods for playback
> 
> and 64.
> 
> I dimly recall seeing some message on LAU fly by about some RME devices
> requiring 16K buffers.
> 
> If you have such a kernel/card, Ardour/ALSA won't currently support it
> directly, sorry.
> 

That is correct, the AIO, same as the RayDAT has a fixed buffer of 16K.
This means that regardless of the requested number of periods and frame
size, it will always report a buffer size of 16K and a number of periods
equal to buffersize divided by framesize. Never the less, if requested 2
periods with framesize of 64 samples, the card will still work correctly
and have a latency that corresponds to 2 frames of 64 samples.
As said before, there are applications that make (most likely too many)
assumptions about these numbers and therefor break with these cards.