15 May
2021
15 May
'21
2:05 a.m.
Does anyone know if jackd (or the Ardour ALSA backend) can be forced to
use interleaved mode? I am trying to work around a problem where a driver
only supports interleaved access, but apparently jackd and Ardour try to
open in non-interleaved mode. In parallel I am helping someone else check
if there is some function missing that should inform applications that
only interleaved mode is supported, and someone else is going to look at
adding non-interleaved mode, but in the mean time I would like to find a
work around if possible.
--
Chris Caudle
15 May
15 May
2:10 a.m.
On 14/05/21 23:04, Chris Caudle wrote:
Does anyone know if jackd (or the Ardour ALSA backend)
can be forced to
use interleaved mode? I am trying to work around a problem where a driver
only supports interleaved access, but apparently jackd and Ardour try to
open in non-interleaved mode. In parallel I am helping someone else check
if there is some function missing that should inform applications that
only interleaved mode is supported, and someone else is going to look at
adding non-interleaved mode, but in the mean time I would like to find a
work around if possible.
Pulseaudio for sure supports this, and last time I checked Ardour has a
pulseaudio backend.
Might be worth a shot.
2:27 a.m.
On 5/15/21 12:04 AM, Chris Caudle wrote:
Does anyone know if jackd (or the Ardour ALSA backend)
can be forced to
use interleaved mode?
Ardour's ALSA backend is based on zita-alsa-pcmi and does support
interleaved mode, but there is no switch to force it on.
It cannot be forced since it requires at least 2 parameters (offset and
stride) the first of which may differ every cycle depending on where
memory is mapped to.
Relevant methods are snd_pcm_mmap_begin() [1] which provides the info
and pointers in a snd_pcm_channel_area_t [2] struct.
but apparently jackd and Ardour try to open in
non-interleaved mode.
Ardour indeed tries SND_PCM_ACCESS_MMAP_NONINTERLEAVED first and falls
back to SND_PCM_ACCESS_MMAP_INTERLEAVED (and
SND_PCM_ACCESS_MMAP_COMPLEX) if the former fail.
One could add an option to override this configuration behavior, but
that would only be useful for driver development/debugging.
--
robin
[1]
https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___direct.html
[2]
https://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__pcm__channel__are…
3:25 a.m.
Ardour indeed tries
SND_PCM_ACCESS_MMAP_NONINTERLEAVED
first and falls back to SND_PCM_ACCESS_MMAP_INTERLEAVED (and
SND_PCM_ACCESS_MMAP_COMPLEX) if the former fail.
So no simple explanation for why that failed.
Is there an environment variable or command line option to give to cause
verbose backend debug information to be printed?
This is the network audio driver from Merging, running in AES67 mode, to a
device which only supports 48 sample frames in AES67 mode, so will
probably be a challenging configuration no matter what. I believe the
Windows equivalent drivers have additional buffering so that on the user
space side the applications can use larger buffers, and the kernel driver
breaks the larger application buffer down to the smaller network buffers.
That would be useful for this driver as well, but first step would be to
at least get Ardour running at all, even if with xruns. The driver does
work with aplay and mpd, so non-pro type apps are working, but not Ardour
or jackd.
I will gather more debug output this weekend, maybe something will give an
indication why the fallback to interleaved is not working.
--
Chris Caudle
3:39 a.m.
On Fri, May 14, 2021 at 5:25 PM Chris Caudle <6807.chris(a)pop.powweb.com>
wrote:
This is the network audio driver from Merging, running in AES67 mode, to a
device which only supports 48 sample frames in AES67 mode, so will
probably be a challenging configuration no matter what. I believe the
Windows equivalent drivers have additional buffering so that on the user
space side the applications can use larger buffers, and the kernel driver
breaks the larger application buffer down to the smaller network buffers.
That would be useful for this driver as well, but first step would be to
at least get Ardour running at all, even if with xruns. The driver does
work with aplay and mpd, so non-pro type apps are working, but not Ardour
or jackd.
while running aplay,
cat /proc/asound/cardN/pcmDp/subS/hw_params
cat /proc/asound/cardN/pcmDp/subS/sw_params
substituting for N, D and S appropriately.
that will show the hw and sw configuration of the device/driver in a
"working" configuration (or non-working one)
10:43 p.m.
On Fri, May 14, 2021 6:39 pm, Paul Davis wrote:
while running aplay,
cat /proc/asound/cardN/pcmDp/subS/hw_params
cat /proc/asound/cardN/pcmDp/subS/sw_params
substituting for N, D and S appropriately.
that will show the hw and sw configuration of the device/driver in a
"working" configuration (or non-working one)
Currently playing a 16 bit file (from a CD but converted to 48kHz); the
driver is set for S24_LE but apparently will accept S16_LE without
problem.
$ cat /proc/asound/card4/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 48
buffer_size: 24576
[chris@chubb ~]$ cat /proc/asound/card4/pcm0p/sub0/hw_params/sw_params
cat: /proc/asound/card4/pcm0p/sub0/hw_params/sw_params: Not a directory
[chris@chubb ~]$ cat /proc/asound/card4/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
avail_min: 48
start_threshold: 24576
stop_threshold: 24576
silence_threshold: 0
silence_size: 0
boundary: 6917529027641081856
I did not realize that aplay used such huge buffers, but I guess there is
no reason not to for a non-realtime playback application, and probably
advantages in CPU usage and avoiding under-run.
I did have to change the driver to be configured for only 2 channels; the
interface it is connecting to on the other end has 8 output channels, but
when I configured the driver with 8 outputs and told aplay to use 2, the
audio was very distorted.
--
Chris Caudle
11:29 p.m.
On Sat, May 15, 2021 1:42 pm, Chris Caudle wrote:
$ cat /proc/asound/card4/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 48
buffer_size: 24576
I did get jackd to start with a 48 sample buffer size (I thought I had
tried that before and it dropped to 32). I set the number of periods to
32 or 64, but neither of those settings worked, Ardour connected to jackd
without complaining, but when I played a project jackd had this repeating
on the console:
JackEngine::XRun: client = ardour was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = ardour was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = ardour was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = ardour was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = ardour was not finished, state = Running
No better results trying to use the Ardour ALSA backend, but that only
allows choosing 32 or 64 for period size, it will not allow configuring
for 48.
--
Chris Caudle
16 May
16 May
10 p.m.
On 5/15/21 9:28 PM, Chris Caudle wrote:
No better results trying to use the Ardour ALSA
backend, but that only
allows choosing 32 or 64 for period size,
Try ardour/git that allows for non power of two buffers. or more
specifically the ALSA backend explicitly offers millisecond buffer-sizes
for devices that require it e.g. recent HDA Intel via SOF (Sound Open
Firmware).
Also as of yesterday's git, today's nightly.ardour.org build
ARDOUR_ALSA_DEBUG=1024 Ardour6
will first try to use interleaved access and then fall back to
non-interleaved instead of the other way around.
--
robin
PS. With a HDA Intel card here all I/O is MMAP interleaved. The device
returns an error when trying to configure it with
SND_PCM_ACCESS_MMAP_NONINTERLEAVED.
29 May
29 May
12:09 a.m.
On Sun, May 16, 2021 1:00 pm, Robin Gareus wrote:
Try ardour/git that allows for non power of two
buffers. or more
specifically the ALSA backend explicitly offers millisecond buffer-sizes
for devices that require it e.g. recent HDA Intel via SOF (Sound Open
Firmware).
Also as of yesterday's git, today's nightly.ardour.org build
ARDOUR_ALSA_DEBUG=1024 Ardour6
Thanks, the latest version of the driver also allows setting 64 as a
period size now (even though the network side is still using 48 samples
per network packet). Others have reported that the recent driver change
allows running jackd with period 64, but on my machine it does not seem
possible at the moment to run at periods that small. I have a PREEMPT
kernel, but not PREEMPT_RT, perhaps full RT is needed, at least on my
machine, to run with periods that short.
Still investigating as I get time. I like the flexibility that network
interfaces will give, but this is definitely not going to be like using a
USB interface any time soon.
will first try to use interleaved access and then fall
back to
non-interleaved instead of the other way around.
Also found that the driver was advertising non-interleaved access as a
valid mechanism, but did not properly implement that. The latest driver
version does not set the attribute bit for non-interleaved, so I think
that problem is also solved at the driver side now.
thanks,
Chris Caudle
15 May
15 May
12:23 p.m.
On Sat, May 15, 2021 at 12:27:12AM +0200, Robin Gareus wrote:
Ardour's ALSA backend is based on zita-alsa-pcmi
Really ? That's funny because the original version of zita-alsa-pcmi
(more than 15 years ago, then known as clalsadrv) was based on Jack's
ALSA backend. For the simple reason that it was a much better source
of information than ALSA's documentation.
and does support interleaved mode, but there is no
switch to force it on.
AFAIK, none of the canonical ALSA apps (like aplay) supports such
a switch.
I always wondered why it should be necessary to test 'modes' until
one of them succeeds. The ALSA code could easily find that out for
itself, and in the end the same interface (using snd_pcm_channel_area_t)
supports all of them, so for the user code the mode doesn't matter [1].
[1] One could claim that knowing that the mode is non-interleaved
would enable the user code to be simpler, like using memcpy()
instead of looping over the samples. But
* the channel_area params would reveal that anyway, and
* usually the loop also does the sample format conversion,
so memcpy() would be ruled out anyway.
Ciao,
--
FA
4:49 p.m.
On Sat, May 15, 2021 at 2:24 AM Fons Adriaensen <fons(a)linuxaudio.org> wrote:
I always wondered why it should be necessary to test 'modes' until
one of them succeeds. The ALSA code could easily find that out for
itself, and in the end the same interface (using snd_pcm_channel_area_t)
supports all of them, so for the user code the mode doesn't matter [1].
[1] One could claim that knowing that the mode is non-interleaved
would enable the user code to be simpler, like using memcpy()
instead of looping over the samples. But
* the channel_area params would reveal that anyway, and
* usually the loop also does the sample format conversion,
so memcpy() would be ruled out anyway
In the case of JACK, it historically comes down to the RME hardware being
among the first to be supported on Linux that actually exposed
non-interleaved "in hardware" (mostly because RME was quite taken with
their idea of "ASIO in hardware". In 1999 or thereabouts, the cost of
deinterleaving the dta was still a notable cost to incur, so if the
hardware itself could support this (which is what the driver was really
supposed to indicate, not "well, i could make it look that way for you")
there was a small gain in performance.
Also, at that time, ALSA didn't yet properly support the mmap'ed mode ...
it was under development but not finished (as evidenced by the way it could
not handle non-interleaved devices like the RME digi series.
5:24 p.m.
On Sat, May 15, 2021 at 06:49:28AM -0600, Paul Davis wrote:
Also, at that time, ALSA didn't yet properly
support the mmap'ed mode ...
it was under development but not finished (as evidenced by the way it could
not handle non-interleaved devices like the RME digi series.
That's another thing that puzzles me...
At the time audio cards like the RMEs would be sitting on a PCI bus,
and the mmap area could/would be actual hardware buffers.
So then, mmapped mode would be the 'natural' way, with read()/write()
being implemented on top of it. But apparently it was the other way
around...
Ciao,
--
FA
8:26 p.m.
On Sat, May 15, 2021 at 7:24 AM Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sat, May 15, 2021 at 06:49:28AM -0600, Paul Davis
wrote:
That's what was changing in the late 1990s. Before "DMA-capable" audio
interfaces, you needed special data transfer operations to get data to/from
the audio interface. By 2000-2002, that mostly went away, and they were all
DMA capable. ALSA evolved to accommodate this, but there had been no reason
to focus on mmap-style access before then.
Also, at that time, ALSA didn't yet properly
support the mmap'ed mode ...
it was under development but not finished (as evidenced by the way it
could
not handle non-interleaved devices like the RME
digi series.
That's another thing that puzzles me...
At the time audio cards like the RMEs would be sitting on a PCI bus,
and the mmap area could/would be actual hardware buffers.
So then, mmapped mode would be the 'natural' way, with read()/write()
being implemented on top of it. But apparently it was the other way
around...
1064
days inactive
1077
days old
linux-audio-user@lists.linuxaudio.org
12 comments
5 participants
participants (5)
-
Chris Caudle -
Filipe Coelho -
Fons Adriaensen -
Paul Davis -
Robin Gareus