On 02/19/2016 11:46 PM, Robin Gareus wrote: [...] > >> Usually I use 48KHz p256 n2: >> [rocketmouse@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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
