Using plughw device and samplerate conversion with an ALSA driver not supporting memory mapped access

[Christian Gruber <christian.gruber@voiceinterconnect.de>]

Hello,

I have problems using the plughw device with samplerate conversion on an embedded board 
having an ALSA driver, which does not support memory mapped access. The audio codec only 
supports 48 kHz sampling rate. The problem occurs, when I want to playback for instance a 
16 kHz file via plughw device, which is the default device. Interestingly the behaviour of 
the ALSA system is as follows:

    1. aplay -D default audio_16kHz.wav        does not work
    2. aplay -D default -M audio_16_kHz.wav    works correctly

This is quite strange, since although the ALSA driver does not support memory mapped 
access, using the option -M works, but the default read write access method without option 
-M does not, although the driver supports read write access. In this case the function 
snd_pcm_hw_params() returns with an error (EINVAL).

I started debugging this and could see, that in the second case, when using option -M, the 
plughw device establishes the following signal processing chain:

     plughw -> rate -> mmap_emul -> hw

This is what I expected from the plughw device. It first introduces a samplerate converter 
for conversion from 16 kHz to 48 kHz, since the codec only supports 48 kHz. And second it 
introduces a memory mapped access emulator to be able to use memory mapped access method 
on the application side and read write access method on the driver side (hw device).

In the first case without using option -M the plughw device establishes the following 
processing chain:

     plughw -> rate -> hw

This means, it does not introduce a memory mapped access emulator, which is comprehensible 
as well, since the application already uses read write access method, the same as the ALSA 
driver does. But nevertheless an error occurs.

Further debugging showed, that the error occurs in the function hw_refine_call() 
(pcm_hw.c) during the call to _snd_pcm_hw_params_internal() within the function 
snd_pcm_plug_hw_params() (pcm_plug.c). For some reason the rate plugin wants to use memory 
mapped access only on the hw device.

So I ask myself, if this is the expected behaviour of the rate plugin. Does the rate 
plugin only support memory mapped access? If yes, why is no mmap_emul plugin introduced 
into the signal processing chain in this case? If not, why does the rate plugin choose 
memory mapped access method? Is the ALSA driver maybe buggy giving wrong information about 
its hw capabilities?

Can anybody help me?

Regards,
Christian