On 02/20/2016 10:47 AM, Robin Gareus wrote: > On 02/20/2016 03:46 AM, Markus Seeber wrote: >> 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. > > Thanks for confirmation. > >> 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. > > What is the case for exposing those this to userland? > > I ask for two, I get behavior of two, but when checking the parameters > the value is 16. That sounds like a bug to me. > > Did anyone flag this up at ALSA-dev, or report a bug? > >> As said before, there are applications that make (most likely too many) >> assumptions about these numbers and therefor break with these cards. > > Ardour is not as forgiving as JACK. if a call to a snd_pcm_hw_params_* > fails or if the requested value does not match the one reported by the > card, it constitutes hard failure. > > best, > robin > I am unsure. It seems as if this behaviour is really broken but I am not that familiar about which assumptions ALSA permits here. @Adrian what do you think? You have been working on these drivers. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
