Re: RME HDSPe MADI under ARM issue with playback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

------------------------------------------------------------------------------
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user



[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux