Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-10-19 Thread Axel Holzinger 
Hi Takashi et al,

I did a bit more research, please find my findings at the end of the email.

On Friday, October 6, 2017 4:50 PM Axel Holzinger wrote:
> On Friday, October 6, 2017 2:30 PM Takashi Iwai wrote:
> > On Tue, 03 Oct 2017 19:23:04 +0200,
> > Axel Holzinger wrote:
> > >
> > > On Thursday, June 8, 2017 10:40 AM Takashi Iwai wrote:
> > >
> > > > On Thu, 08 Jun 2017 10:15:34 +0200,
> > > > Axel Holzinger wrote:
> > > > >
> > > > > On Tuesday, June 6, 2017 8:27 PM Takashi Iwai wrote:
> > > > > > On Mon, 05 Jun 2017 11:49:53 +0200,
> > > > > > Axel Holzinger wrote:
> > > > > > >
> > > > > > > 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
> > > > > >
> > > > > > 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.
> > > >
> > > > > > > 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, 0x8000) =
> -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.
> > > > >
> > > > > 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.
> > > >
> > > > > > 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?
> > > >
> > > > > > 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.
> > > >
> > > > > > (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
> > >
> > > Hello Takashi, hello list,
> > >
> > > I did some further testing

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-10-06 Thread Axel Holzinger 
On Friday, October 6, 2017 2:30 PM Takashi Iwai wrote:
> On Tue, 03 Oct 2017 19:23:04 +0200,
> Axel Holzinger wrote:
> >
> > On Thursday, June 8, 2017 10:40 AM Takashi Iwai wrote:
> >
> > > On Thu, 08 Jun 2017 10:15:34 +0200,
> > > Axel Holzinger wrote:
> > > >
> > > > On Tuesday, June 6, 2017 8:27 PM Takashi Iwai wrote:
> > > > > On Mon, 05 Jun 2017 11:49:53 +0200,
> > > > > Axel Holzinger wrote:
> > > > > >
> > > > > > 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
> > > > >
> > > > > 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.
> > >
> > > > > > 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, 0x8000) = -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.
> > > >
> > > > 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.
> > >
> > > > > 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?
> > >
> > > > > 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.
> > >
> > > > > (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
> >
> > Hello Takashi, hello list,
> >
> > I did some further testing with a Sound Blaster Live Audigy Rx (Emu10k1
> > driver based) and this card works without any change in asound.conf,
etc.
> 
> Yes, it's because emu10k1 supports only interleaved stereo format (two
> channels) which works with one-shot mmap via dma_mmap_coherent().
> Meanwhile HDSP MADI supports only non-interleaved format that performs
> multiple mmaps, and currently it doesn't work with
> dma_mmap_coherent().

Understood.

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-10-06 Thread Takashi Iwai 
On Tue, 03 Oct 2017 19:23:04 +0200,
Axel Holzinger wrote:
> 
> On Thursday, June 8, 2017 10:40 AM Takashi Iwai wrote:
> 
> > On Thu, 08 Jun 2017 10:15:34 +0200,
> > Axel Holzinger wrote:
> > >
> > > On Tuesday, June 6, 2017 8:27 PM Takashi Iwai wrote:
> > > > On Mon, 05 Jun 2017 11:49:53 +0200,
> > > > Axel Holzinger wrote:
> > > > >
> > > > > 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
> > > >
> > > > 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.
> > 
> > > > > 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, 0x8000) = -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.
> > >
> > > 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.
> > 
> > > > 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?
> > 
> > > > 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.
> > 
> > > > (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
> 
> Hello Takashi, hello list,
> 
> I did some further testing with a Sound Blaster Live Audigy Rx (Emu10k1
> driver based) and this card works without any change in asound.conf, etc.

Yes, it's because emu10k1 supports only interleaved stereo format (two
channels) which works with one-shot mmap via dma_mmap_coherent().
Meanwhile HDSP MADI supports only non-interleaved format that performs
multiple mmaps, and currently it doesn't work with
dma_mmap_coherent().

> While with the RME MADI card:
> 
> debian@arm:~/48kHz$ aplay -vv audio.wav
> Playing WAVE 'audio.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
> Stereo
> ALSA lib pcm_mmap.c:374:(snd_pcm_mmap) mmap failed: No such device or
> address

So my previous patch didn't help?
(BTW, area->pgoff was indeed a typo

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-10-03 Thread Axel Holzinger 
On Thursday, June 8, 2017 10:40 AM Takashi Iwai wrote:

> On Thu, 08 Jun 2017 10:15:34 +0200,
> Axel Holzinger wrote:
> >
> > On Tuesday, June 6, 2017 8:27 PM Takashi Iwai wrote:
> > > On Mon, 05 Jun 2017 11:49:53 +0200,
> > > Axel Holzinger wrote:
> > > >
> > > > 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
> > >
> > > 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.
> 
> > > > 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, 0x8000) = -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.
> >
> > 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.
> 
> > > 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?
> 
> > > 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.
> 
> > > (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

Hello Takashi, hello list,

I did some further testing with a Sound Blaster Live Audigy Rx (Emu10k1
driver based) and this card works without any change in asound.conf, etc.

debian@arm:~/48kHz$ aplay -vv audio.wav
Playing WAVE 'audio.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Plug PCM: Hardware PCM card 0 'SB Audigy 5/Rx [SB1550]' device 0 subdevice 0
Its setup is:
  stream   : PLAYBACK
  access   : RW_INTERLEAVED
  format   : S16_LE
  subformat: STD
  channels : 2
  rate : 48000
  exact rate   : 48000 (48000/1)
  msbits   : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min: 4096
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary : 1073741824
  appl_ptr : 0
  hw_ptr   : 0
# +| 10%

While with the RME MADI card:

debian@arm:~/48kHz$ aplay -vv audio.wav
Playing WAVE 'audio.wav' : Signed 16

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-06-08 Thread Takashi Iwai 
On Thu, 08 Jun 2017 11:57:14 +0200,
Axel Holzinger wrote:
> 
> On Thursday, June 8, 2017 10:40 AM Takashi Iwai wrote:
> > On Thu, 08 Jun 2017 10:15:34 +0200,
> > Axel Holzinger wrote:
> > >
> > > On Tuesday, June 6, 2017 8:27 PM Takashi Iwai wrote:
> > > > On Mon, 05 Jun 2017 11:49:53 +0200,
> > > > Axel Holzinger wrote:
> > > > >
> > > > > 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
> > > >
> > > > 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.


> > > > > 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, 0x8000) = -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.
> > >
> > > 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.
> 
> > > > 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".
> 
> 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.
> 
> > 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.


> > > > 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.

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-06-08 Thread Axel Holzinger 
On Thursday, June 8, 2017 10:40 AM Takashi Iwai wrote:
> On Thu, 08 Jun 2017 10:15:34 +0200,
> Axel Holzinger wrote:
> >
> > On Tuesday, June 6, 2017 8:27 PM Takashi Iwai wrote:
> > > On Mon, 05 Jun 2017 11:49:53 +0200,
> > > Axel Holzinger wrote:
> > > >
> > > > 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
> > >
> > > 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?

> > > > 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, 0x8000) = -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.
> >
> > 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.

> > > 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".

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.

> 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").

> > > 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.

> > > (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

> Takashi


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-06-08 Thread Takashi Iwai 
On Thu, 08 Jun 2017 10:15:34 +0200,
Axel Holzinger wrote:
> 
> On Tuesday, June 6, 2017 8:27 PM Takashi Iwai wrote:
> > On Mon, 05 Jun 2017 11:49:53 +0200,
> > Axel Holzinger wrote:
> > >
> > > 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
> > 
> > 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.

> > > 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, 0x8000) = -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.
> 
> 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.

> > 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?

> > 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.

> > (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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-06-08 Thread Axel Holzinger 
Resending without zipped attachment but instead with plain text file.

On Tuesday, June 6, 2017 8:27 PM Takashi Iwai wrote:
> On Mon, 05 Jun 2017 11:49:53 +0200,
> Axel Holzinger wrote:
> >
> > 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
> 
> 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?

> > 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, 0x8000) = -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.

Okay, got it. So is the mmap emulation plugin via asound.conf suggested by
Anders needed then anyhow?

> 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?

> 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.

> (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

> Takashi
execve("/usr/bin/aplay", ["aplay", "--device=default:CARD=HDSPMx5c74"..., 
"audio.wav"], [/* 36 vars */]) = 0
brk(0)  = 0x78b000
uname({sys="Linux", node="arm", ...})   = 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6f7a000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=49056, ...}) = 0
mmap2(NULL, 49056, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f6e000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/arm-linux-gnueabihf/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0@\30\0\0004\0\0\0"..., 
512) = 512
lseek(3, 21260, SEEK_SET)   = 21260
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1320) = 1320
lseek(3, 20868, SEEK_SET)   = 20868
read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53
fstat64(3, {st_mode=S_IFREG|0644, st_size=22580, ...}) = 0
mmap2(NULL, 86588, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb6f3f000
mprotect(0xb6f44000, 61440, PROT_NONE)  = 0
mmap2(0xb6f53000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xb6f53000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/arm-linux-gnueabihf/libasound.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\350\346\1\0004\0\0\0"..., 512) 
= 512
lseek(3, 609792, SEEK_SET)  = 609792
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1160) = 1160
lseek(3, 609420,

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-06-06 Thread Takashi Iwai 
On Mon, 05 Jun 2017 11:49:53 +0200,
Axel Holzinger wrote:
> 
> 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

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.

> 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, 0x8000) = -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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-06-06 Thread Anders Genell 


> 5 juni 2017 kl. 18:38 skrev Axel Holzinger :
> 
> Anders Genell wrote:
>> 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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-06-05 Thread Axel Holzinger 
Anders Genell wrote:
> 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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] RME HDSPe MADI under ARM issue with playback

2017-06-05 Thread Axel Holzinger 
Axel Holzinger wrote:
> 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

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



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user