Re: [LAU] Ardour session with plain ALSA, without JACK

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@email-addr-hidden ~]$ 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sat Feb 20 20:15:02 2016