[LAU] Ardour session with plain ALSA, without JACK

[Paul Davis]

The device driver for these cards is broken. At least arguably.

On Fri, Feb 19, 2016 at 9:46 PM, Markus Seeber <
markus.seeber at spectralbird.de> wrote:

> 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.
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20160219/2eb974a3/attachment.html>