Discussion:
[Alsa-user] RME HDSPe MADI under ARM issue with playback
Axel Holzinger
2017-06-05 09:49:53 UTC
Permalink
Hi,

I'm trying to get a RME HDSPe MADI card to run in an ARM box with Linux
4.1.6. I configured the (vendor specific TI) kernel to support the card (via
hdspm) compiled into the kernel (not as loadable module).

The MADI card is detected as a PCI device and the ALSA driver is loaded.
Unfortunately playout does NOT work: aplay is reporting an error:
ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such device or
address

Does anybody have an idea what might be the reason?

I tested the card on Linux x64 and it worked flawlessly.

Below is info about the system, aplay output and an strace of the relevant
part.

Thanks in advance
Axel

Debian GNU/Linux 8 arm ttyS0
Linux arm 4.1.6-01295-g170507a #1 SMP PREEMPT Fri Jun 2 14:09:10 CEST 2017
armv7l

***@arm:~$ lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Model name: ARMv7 Processor rev 2 (v7l)
CPU max MHz: 1500.0000
CPU min MHz: 1000.0000

***@arm:~/Music$ lspci
00:00.0 PCI bridge: Texas Instruments Device 8888 (rev 01)
01:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP
MADI (rev d2)

***@arm:~/Music$ aplay --list-devices
**** List of PLAYBACK Hardware Devices ****
card 0: HDSPMx5c7496 [RME MADI_5c7496], device 0: RME MADI [RME MADI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: H58040000encode [HDMI 58040000.encoder], device 0: HDMI
58040000.encoder snd-soc-dummy-dai-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

***@arm:~/Music$ aplay --list-pcms
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=HDSPMx5c7496
RME MADI_5c7496, RME MADI
Default Audio Device
sysdefault:CARD=HDSPMx5c7496
RME MADI_5c7496, RME MADI
Default Audio Device
dmix:CARD=HDSPMx5c7496,DEV=0
RME MADI_5c7496, RME MADI
Direct sample mixing device
dsnoop:CARD=HDSPMx5c7496,DEV=0
RME MADI_5c7496, RME MADI
Direct sample snooping device
hw:CARD=HDSPMx5c7496,DEV=0
RME MADI_5c7496, RME MADI
Direct hardware device without any conversions
plughw:CARD=HDSPMx5c7496,DEV=0
RME MADI_5c7496, RME MADI
Hardware device with all software conversions
default:CARD=H58040000encode
HDMI 58040000.encoder,
Default Audio Device
sysdefault:CARD=H58040000encode
HDMI 58040000.encoder,
Default Audio Device
dmix:CARD=H58040000encode,DEV=0
HDMI 58040000.encoder,
Direct sample mixing device
dsnoop:CARD=H58040000encode,DEV=0
HDMI 58040000.encoder,
Direct sample snooping device
hw:CARD=H58040000encode,DEV=0
HDMI 58040000.encoder,
Direct hardware device without any conversions
plughw:CARD=H58040000encode,DEV=0
HDMI 58040000.encoder,
Hardware device with all software conversions

***@arm:~$ aplay --version
aplay: version 1.0.28 by Jaroslav Kysela <***@perex.cz>

***@arm:~$ aplay -vv audio.wav
Playing WAVE 'audio.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such device or
address
aplay: set_params:1297: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (46439 46440)
PERIOD_SIZE: 2048
PERIOD_BYTES: 8192
PERIODS: 2
BUFFER_TIME: (92879 92880)
BUFFER_SIZE: 4096
BUFFER_BYTES: 16384
TICK_TIME: 0

strace:
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY or SNDRV_PCM_IOCTL_INFO,
0xbecdfb64) = 0
fcntl64(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
ioctl(4, AGPIOC_INFO or SNDRV_PCM_IOCTL_PVERSION, 0xbecdfacc) = 0
ioctl(4, AGPIOC_SETUP or SNDRV_PCM_IOCTL_TTSTAMP, 0xbecdfad4) = 0
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000000) = -1 ENXIO (No such
device or address)
Axel Holzinger
2017-06-05 10:43:27 UTC
Permalink
Post by Axel Holzinger
Hi,
I'm trying to get a RME HDSPe MADI card to run in an ARM box with Linux
4.1.6. I configured the (vendor specific TI) kernel to support the card (via
hdspm) compiled into the kernel (not as loadable module).
The MADI card is detected as a PCI device and the ALSA driver is loaded.
ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such device or
address
Does anybody have an idea what might be the reason?
I tested the card on Linux x64 and it worked flawlessly.
Below is info about the system, aplay output and an strace of the relevant
part.
Thanks in advance
Axel
A friend of mine pointed me to this document:
https://kernel.readthedocs.io/en/sphinx-samples/writing-an-alsa-driver.html#
external-hardware-buffers

and especially this paragraph:
"Another case is when the chip uses a PCI memory-map region for the
buffer instead of the host memory. In this case, mmap is available only
on certain architectures like the Intel one. In non-mmap mode, the data
cannot be transferred as in the normal way. Thus you need to define the
copy and silence callbacks as well, as in the cases above."

To me it looks like the hdspm driver assumes that mmap mode is available (as
i.e. on an Intel platform) while in reality (here on ARM) it's not.

Shouldn't the driver test is mmap mode is available (could even be done at
compile time) and either not compile (or second best, not load at runtime)
or use a different technique to do what it wants to do?

Cheers
Axel
Axel Holzinger
2017-06-05 16:38:14 UTC
Permalink
I am sure others have more clever solutions to offer, but you might try invoking the mmap emulation plugin by putting something like
pcm.mmap0 {
type mmap_emul;
slave {
pcm "hw:0,0";
}
}
pcm.!default {
type plug;
slave {
pcm mmap0;
}
}
in you /etc/asound.conf file.
It will likely add some latency, which is unfortunate when using a pro level card like the HDSPe MADI, but you might at least get sound out of it...
Regards,
Anders
Hi Anders,

thank you for your reply.

Very strange: With the /etc/asound.conf file with the content you proposed, the RME card is not anymore available, even lspci doesn't list it anymore. So I tend to think that something with the PCI(e) configuration space is not (yet) working/configured correctly.

What's also interesting is that the onboard (on chip) sound device is only working with your suggestion. Without it's not playing.

Cheers
Axel
Anders Genell
2017-06-05 17:24:43 UTC
Permalink
Post by Axel Holzinger
I am sure others have more clever solutions to offer, but you might try invoking the mmap emulation plugin by putting something like
pcm.mmap0 {
type mmap_emul;
slave {
pcm "hw:0,0";
}
}
pcm.!default {
type plug;
slave {
pcm mmap0;
}
}
in you /etc/asound.conf file.
It will likely add some latency, which is unfortunate when using a pro level card like the HDSPe MADI, but you might at least get sound out of it...
Regards,
Anders
Hi Anders,
thank you for your reply.
Very strange: With the /etc/asound.conf file with the content you proposed, the RME card is not anymore available, even lspci doesn't list it anymore. So I tend to think that something with the PCI(e) configuration space is not (yet) working/configured correctly.
What's also interesting is that the onboard (on chip) sound device is only working with your suggestion. Without it's not playing.
Cheers
Axel
Huh...
Curiouser and curiouser.
Well, this is way above my head then, so I can do naught but wish you good luck.

Regards,
Anders
Takashi Iwai
2017-06-06 18:27:07 UTC
Permalink
On Mon, 05 Jun 2017 11:49:53 +0200,
Post by Axel Holzinger
Hi,
I'm trying to get a RME HDSPe MADI card to run in an ARM box with Linux
4.1.6. I configured the (vendor specific TI) kernel to support the card (via
hdspm) compiled into the kernel (not as loadable module).
The MADI card is detected as a PCI device and the ALSA driver is loaded.
ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such device or
address
Hm, this sounds odd. But the line doesn't really correspond to the
latest version of alsa-lib. Could you try to upgrade to the latest
version? Otherwise it's hard to debug.
Post by Axel Holzinger
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY or SNDRV_PCM_IOCTL_INFO,
0xbecdfb64) = 0
fcntl64(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
ioctl(4, AGPIOC_INFO or SNDRV_PCM_IOCTL_PVERSION, 0xbecdfacc) = 0
ioctl(4, AGPIOC_SETUP or SNDRV_PCM_IOCTL_TTSTAMP, 0xbecdfad4) = 0
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000000) = -1 ENXIO (No such
device or address)
This error is expected and should be OK. It's an mmap of
status/control page, and this isn't supported on ARM, thus the kernel
returns -ENXIO. alsa-lib then falls back to the normal ioctl instead
of status/control mmap.

But the ring-buffer mmap is supported as normal on ARM for MADI
driver, at least. MADI provides the SG-buffer that is mappable via
DMA coherent pages, and it should work on most of archs as is.

You should have another error from mmap, with a different offset
value. That's the real error we need to track down.

(And, 4.1.x is pretty old, rather too old for debugging, too...)


Takashi
Axel Holzinger
2017-06-08 08:26:52 UTC
Permalink
Resending without zipped attachment but instead with plain text file.
Post by Takashi Iwai
On Mon, 05 Jun 2017 11:49:53 +0200,
Post by Axel Holzinger
Hi,
I'm trying to get a RME HDSPe MADI card to run in an ARM box with Linux
4.1.6. I configured the (vendor specific TI) kernel to support the card (via
hdspm) compiled into the kernel (not as loadable module).
The MADI card is detected as a PCI device and the ALSA driver is loaded.
ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such device
or
Post by Axel Holzinger
address
Hm, this sounds odd. But the line doesn't really correspond to the
latest version of alsa-lib. Could you try to upgrade to the latest
version? Otherwise it's hard to debug.
I installed ALSA with Debian apt-get. How would I update to a newer version?
Post by Takashi Iwai
Post by Axel Holzinger
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY or
SNDRV_PCM_IOCTL_INFO,
Post by Axel Holzinger
0xbecdfb64) = 0
fcntl64(4, F_GETFL) = 0x802 (flags
O_RDWR|O_NONBLOCK)
Post by Takashi Iwai
Post by Axel Holzinger
ioctl(4, AGPIOC_INFO or SNDRV_PCM_IOCTL_PVERSION, 0xbecdfacc) = 0
ioctl(4, AGPIOC_SETUP or SNDRV_PCM_IOCTL_TTSTAMP, 0xbecdfad4) = 0
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000000) = -1 ENXIO
(No such
Post by Axel Holzinger
device or address)
This error is expected and should be OK. It's an mmap of
status/control page, and this isn't supported on ARM, thus the kernel
returns -ENXIO. alsa-lib then falls back to the normal ioctl instead
of status/control mmap.
Okay, got it. So is the mmap emulation plugin via asound.conf suggested by
Anders needed then anyhow?
Post by Takashi Iwai
But the ring-buffer mmap is supported as normal on ARM for MADI
driver, at least. MADI provides the SG-buffer that is mappable via
DMA coherent pages, and it should work on most of archs as is.
Well I found out something more: If I don't give a "--device" parameter to
aplay and the RME card is default, then audio is playing. But I give the "
--device=default:CARD=HDSPMx5c74" then the error is occuring. That doesn't
make sense to me at all. The tests made were with the asound.conf Anders
suggested. Isn't that strange?
Post by Takashi Iwai
You should have another error from mmap, with a different offset
value. That's the real error we need to track down.
I attached the complete strace.
Post by Takashi Iwai
(And, 4.1.x is pretty old, rather too old for debugging, too...)
Well, I know, but the kernel is a TI based manufacturer kernel for a SoC
(AM5728). I'm not such an expert to update that to current kernel version
unfortunately.

If you don't mind I have another question: If specifying a device
"--device", how would I "send" audio to the "upper" channels/tracks of the
MADI card? If I ommit the "--device" parameter audio is playing on
channels/tracks 1+2. How would I play audio to channels/tracks 33+34 for
example?

Thank you very much for your support!
Axel
Post by Takashi Iwai
Takashi
Takashi Iwai
2017-06-08 08:40:11 UTC
Permalink
On Thu, 08 Jun 2017 10:15:34 +0200,
Post by Axel Holzinger
Post by Takashi Iwai
On Mon, 05 Jun 2017 11:49:53 +0200,
Post by Axel Holzinger
Hi,
I'm trying to get a RME HDSPe MADI card to run in an ARM box with Linux
4.1.6. I configured the (vendor specific TI) kernel to support the card
(via
Post by Takashi Iwai
Post by Axel Holzinger
hdspm) compiled into the kernel (not as loadable module).
The MADI card is detected as a PCI device and the ALSA driver is loaded.
ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such device
or
Post by Axel Holzinger
address
Hm, this sounds odd. But the line doesn't really correspond to the
latest version of alsa-lib. Could you try to upgrade to the latest
version? Otherwise it's hard to debug.
I installed ALSA with Debian apt-get. How would I update to a newer version?
Compiling by yourself?
alsa-lib has very few dependency, so it should be easy.
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY or
SNDRV_PCM_IOCTL_INFO,
Post by Axel Holzinger
0xbecdfb64) = 0
fcntl64(4, F_GETFL) = 0x802 (flags
O_RDWR|O_NONBLOCK)
Post by Takashi Iwai
Post by Axel Holzinger
ioctl(4, AGPIOC_INFO or SNDRV_PCM_IOCTL_PVERSION, 0xbecdfacc) = 0
ioctl(4, AGPIOC_SETUP or SNDRV_PCM_IOCTL_TTSTAMP, 0xbecdfad4) = 0
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000000) = -1 ENXIO
(No such
Post by Axel Holzinger
device or address)
This error is expected and should be OK. It's an mmap of
status/control page, and this isn't supported on ARM, thus the kernel
returns -ENXIO. alsa-lib then falls back to the normal ioctl instead
of status/control mmap.
Okay, got it. So is the mmap emulation plugin via asound.conf suggested by
Anders needed then anyhow?
It's irrelevant with the mmap emulation.
Post by Axel Holzinger
Post by Takashi Iwai
But the ring-buffer mmap is supported as normal on ARM for MADI
driver, at least. MADI provides the SG-buffer that is mappable via
DMA coherent pages, and it should work on most of archs as is.
Well I found out something more: If I don't give a "--device" parameter to
aplay and the RME card is default, then audio is playing. But I give the "
--device=default:CARD=HDSPMx5c74" then the error is occuring. That doesn't
make sense to me at all. The tests made were with the asound.conf Anders
suggested. Isn't that strange?
Are you using dmix or such? It appears more like a configuration
issue. With the unmodified configuration, the "default" PCM for HDSPM
should be equivalent with "plughw".

Could you check whether aplay -M works without device option?
Post by Axel Holzinger
Post by Takashi Iwai
You should have another error from mmap, with a different offset
value. That's the real error we need to track down.
I attached the complete strace.
OK, the strace shows the mmap failure of the second channel.
Post by Axel Holzinger
Post by Takashi Iwai
(And, 4.1.x is pretty old, rather too old for debugging, too...)
Well, I know, but the kernel is a TI based manufacturer kernel for a SoC
(AM5728). I'm not such an expert to update that to current kernel version
unfortunately.
If you don't mind I have another question: If specifying a device
"--device", how would I "send" audio to the "upper" channels/tracks of the
MADI card? If I ommit the "--device" parameter audio is playing on
channels/tracks 1+2. How would I play audio to channels/tracks 33+34 for
example?
Well, you likely need to fiddle with the asoundrc in such a case.
Maybe a better option is to use JACK or such, I suppose.


Takashi
Axel Holzinger
2017-06-08 09:57:14 UTC
Permalink
Post by Takashi Iwai
On Thu, 08 Jun 2017 10:15:34 +0200,
Post by Axel Holzinger
Post by Takashi Iwai
On Mon, 05 Jun 2017 11:49:53 +0200,
Post by Axel Holzinger
Hi,
I'm trying to get a RME HDSPe MADI card to run in an ARM box with
Linux
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
4.1.6. I configured the (vendor specific TI) kernel to support the card
(via
Post by Takashi Iwai
Post by Axel Holzinger
hdspm) compiled into the kernel (not as loadable module).
The MADI card is detected as a PCI device and the ALSA driver is loaded.
ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such
device
Post by Axel Holzinger
Post by Takashi Iwai
or
Post by Axel Holzinger
address
Hm, this sounds odd. But the line doesn't really correspond to the
latest version of alsa-lib. Could you try to upgrade to the latest
version? Otherwise it's hard to debug.
I installed ALSA with Debian apt-get. How would I update to a newer
version?
Compiling by yourself?
alsa-lib has very few dependency, so it should be easy.
I'm fine with that but does it suffice to compile only alsa-lib or do I have
to compile other moduels also (hdspm driver, hdspmixer, etc)? Is the ABI
stable within different versions?

If only alsa-lib, configure, make, make install? Should I uninstall the
alsa-lib debian package before?
Post by Takashi Iwai
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) =
4
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY or
SNDRV_PCM_IOCTL_INFO,
Post by Axel Holzinger
0xbecdfb64) = 0
fcntl64(4, F_GETFL) = 0x802 (flags
O_RDWR|O_NONBLOCK)
Post by Takashi Iwai
Post by Axel Holzinger
ioctl(4, AGPIOC_INFO or SNDRV_PCM_IOCTL_PVERSION, 0xbecdfacc) =
0
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
ioctl(4, AGPIOC_SETUP or SNDRV_PCM_IOCTL_TTSTAMP, 0xbecdfad4)
= 0
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000000) = -1
ENXIO
Post by Axel Holzinger
Post by Takashi Iwai
(No such
Post by Axel Holzinger
device or address)
This error is expected and should be OK. It's an mmap of
status/control page, and this isn't supported on ARM, thus the kernel
returns -ENXIO. alsa-lib then falls back to the normal ioctl instead
of status/control mmap.
Okay, got it. So is the mmap emulation plugin via asound.conf suggested by
Anders needed then anyhow?
It's irrelevant with the mmap emulation.
Well, not with my tests. Without asound.conf (with the mmap emulation
plugin) aply does NOT play audio on the MADI card. With asound.conf it does.
Post by Takashi Iwai
Post by Axel Holzinger
Post by Takashi Iwai
But the ring-buffer mmap is supported as normal on ARM for MADI
driver, at least. MADI provides the SG-buffer that is mappable via
DMA coherent pages, and it should work on most of archs as is.
Well I found out something more: If I don't give a "--device" parameter to
aplay and the RME card is default, then audio is playing. But I give the "
--device=default:CARD=HDSPMx5c74" then the error is occuring. That
doesn't
Post by Axel Holzinger
make sense to me at all. The tests made were with the asound.conf Anders
suggested. Isn't that strange?
Are you using dmix or such? It appears more like a configuration
issue. With the unmodified configuration, the "default" PCM for HDSPM
should be equivalent with "plughw".
Only ommitting "--device=" or "--device=default" is working. aplay
--device=plughw:CARD=HDSPMx5c7496,DEV=0 does NOT work. Again it's working
only with asound.conf.
Post by Takashi Iwai
Could you check whether aplay -M works without device option?
aplay -M audio.wav is working (but as written above, only WITH asound.conf
and only without "--device" or with "--device=default").
Post by Takashi Iwai
Post by Axel Holzinger
Post by Takashi Iwai
You should have another error from mmap, with a different offset
value. That's the real error we need to track down.
I attached the complete strace.
OK, the strace shows the mmap failure of the second channel.
The second audio channel? Please forgive my ignorance.
Post by Takashi Iwai
Post by Axel Holzinger
Post by Takashi Iwai
(And, 4.1.x is pretty old, rather too old for debugging, too...)
Well, I know, but the kernel is a TI based manufacturer kernel for a SoC
(AM5728). I'm not such an expert to update that to current kernel version
unfortunately.
If you don't mind I have another question: If specifying a device
"--device", how would I "send" audio to the "upper" channels/tracks of the
MADI card? If I ommit the "--device" parameter audio is playing on
channels/tracks 1+2. How would I play audio to channels/tracks 33+34 for
example?
Well, you likely need to fiddle with the asoundrc in such a case.
Maybe a better option is to use JACK or such, I suppose.
Okay, I will do that as soon as the card is working relaibly.

Thank you!
Axel
Post by Takashi Iwai
Takashi
Takashi Iwai
2017-06-08 12:38:17 UTC
Permalink
On Thu, 08 Jun 2017 11:57:14 +0200,
Post by Axel Holzinger
Post by Takashi Iwai
On Thu, 08 Jun 2017 10:15:34 +0200,
Post by Axel Holzinger
Post by Takashi Iwai
On Mon, 05 Jun 2017 11:49:53 +0200,
Post by Axel Holzinger
Hi,
I'm trying to get a RME HDSPe MADI card to run in an ARM box with
Linux
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
4.1.6. I configured the (vendor specific TI) kernel to support the
card
Post by Takashi Iwai
Post by Axel Holzinger
(via
Post by Takashi Iwai
Post by Axel Holzinger
hdspm) compiled into the kernel (not as loadable module).
The MADI card is detected as a PCI device and the ALSA driver is
loaded.
Post by Takashi Iwai
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such
device
Post by Axel Holzinger
Post by Takashi Iwai
or
Post by Axel Holzinger
address
Hm, this sounds odd. But the line doesn't really correspond to the
latest version of alsa-lib. Could you try to upgrade to the latest
version? Otherwise it's hard to debug.
I installed ALSA with Debian apt-get. How would I update to a newer
version?
Compiling by yourself?
alsa-lib has very few dependency, so it should be easy.
I'm fine with that but does it suffice to compile only alsa-lib or do I have
to compile other moduels also (hdspm driver, hdspmixer, etc)? Is the ABI
stable within different versions?
If only alsa-lib, configure, make, make install? Should I uninstall the
alsa-lib debian package before?
At first you can try to upgrade alsa-lib manually.

But I guess you'd need to build the kernel by yourself, too, as this
seems to be a kernel driver problem.
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) =
4
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY or
SNDRV_PCM_IOCTL_INFO,
Post by Axel Holzinger
0xbecdfb64) = 0
fcntl64(4, F_GETFL) = 0x802 (flags
O_RDWR|O_NONBLOCK)
Post by Takashi Iwai
Post by Axel Holzinger
ioctl(4, AGPIOC_INFO or SNDRV_PCM_IOCTL_PVERSION, 0xbecdfacc) =
0
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
ioctl(4, AGPIOC_SETUP or SNDRV_PCM_IOCTL_TTSTAMP, 0xbecdfad4)
= 0
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000000) = -1
ENXIO
Post by Axel Holzinger
Post by Takashi Iwai
(No such
Post by Axel Holzinger
device or address)
This error is expected and should be OK. It's an mmap of
status/control page, and this isn't supported on ARM, thus the kernel
returns -ENXIO. alsa-lib then falls back to the normal ioctl instead
of status/control mmap.
Okay, got it. So is the mmap emulation plugin via asound.conf suggested
by
Post by Takashi Iwai
Post by Axel Holzinger
Anders needed then anyhow?
It's irrelevant with the mmap emulation.
Well, not with my tests. Without asound.conf (with the mmap emulation
plugin) aply does NOT play audio on the MADI card. With asound.conf it does.
Post by Takashi Iwai
Post by Axel Holzinger
Post by Takashi Iwai
But the ring-buffer mmap is supported as normal on ARM for MADI
driver, at least. MADI provides the SG-buffer that is mappable via
DMA coherent pages, and it should work on most of archs as is.
Well I found out something more: If I don't give a "--device" parameter
to
Post by Takashi Iwai
Post by Axel Holzinger
aplay and the RME card is default, then audio is playing. But I give the
"
Post by Takashi Iwai
Post by Axel Holzinger
--device=default:CARD=HDSPMx5c74" then the error is occuring. That
doesn't
Post by Axel Holzinger
make sense to me at all. The tests made were with the asound.conf Anders
suggested. Isn't that strange?
Are you using dmix or such? It appears more like a configuration
issue. With the unmodified configuration, the "default" PCM for HDSPM
should be equivalent with "plughw".
Only ommitting "--device=" or "--device=default" is working. aplay
--device=plughw:CARD=HDSPMx5c7496,DEV=0 does NOT work. Again it's working
only with asound.conf.
Post by Takashi Iwai
Could you check whether aplay -M works without device option?
aplay -M audio.wav is working (but as written above, only WITH asound.conf
and only without "--device" or with "--device=default").
Please give the output of aplay with -v option for both working
cases. Especially interesting with -M because it should access via
mmap mode.
Post by Axel Holzinger
Post by Takashi Iwai
Post by Axel Holzinger
Post by Takashi Iwai
You should have another error from mmap, with a different offset
value. That's the real error we need to track down.
I attached the complete strace.
OK, the strace shows the mmap failure of the second channel.
The second audio channel? Please forgive my ignorance.
The HDSPM board supports only non-interleaved PCM streams, thus the
mmap is performed per channel unlike the other standard interleaved
format.

Now looking at the issue closely, I guess it's an issue that is
specific to the non-interleaved PCM format. It performs multiple
mmaps, once per channel. And for non-x86, we provide only the mmap
for the full buffer.

Below is an untested patch to address it. Give it a try.
It should be applicable to 4.1.x kernel, too.


thanks,

Takashi

---
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3324,12 +3324,15 @@ int snd_pcm_lib_default_mmap(struct snd_pcm_substream *substream,
#endif /* CONFIG_GENERIC_ALLOCATOR */
#ifndef CONFIG_X86 /* for avoiding warnings arch/x86/mm/pat.c */
if (!substream->ops->page &&
- substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
+ substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV) {
+ unsigned long offset = area->pgoff << PAGE_SHIFT;
+
return dma_mmap_coherent(substream->dma_buffer.dev.dev,
area,
- substream->runtime->dma_area,
- substream->runtime->dma_addr,
+ substream->runtime->dma_area + offset,
+ substream->runtime->dma_addr + offset,
area->vm_end - area->vm_start);
+ }
#endif /* CONFIG_X86 */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;

Loading...