David Henningsson wrote:
> On 01/14/2014 04:47 PM, Alexander E. Patrakov wrote:
> > In my opinion (if this counts at all), this needs to be fixed in
> > PulseAudio, and not only because of your hardware. Indeed, the
> > SND_PCM_NO_AUTO_CHANNELS_{UP,DOWN} solution proposed by David would
> > "work" for you, but it is suboptimal, because it would no longer talk
> > to the "hw" devices (as it could if it added the empty channels
> > itself). Talking to mmapped "hw" devices is, if I understand
> > correctly, a necessary condition for timestamp-based scheduling, which
> > is beneficial for applications. Due to the same reason, and again if I
> > understand correctly, timestamp-based scheduling is currently
> > unavailable for sound cards that rely on the route plugin in their
> > ALSA configs. It would be nice to get rid of this suboptimal thing,
> > too, by implementing the equivalent functionality inside PulseAudio.
>
> PulseAudio can use timer scheduling even when mmap is disabled. Besides,
> IIRC all of the plug, route and volume alsa plugins use mmap emulation,
> so PulseAudio sees it as a mmaped device anyway.
OK, I have checked the code and apologize for the misunderstanding. There is
indeed a call to pa_alsa_pcm_is_hw(), but this function returns true even for
some cases of non-raw hw. I.e. route or plug is OK (which is good), ioplug is
not OK (which is expected and also good). The problematic "unexpected OK" case
is extplug (which is used e.g. by dcaenc), where pulseaudio attempts
timestamp-based scheduling and even rewinds. But I think this looks more like
a bug in extplug (for pretending to support mmap and rewinds without any
actual means to detect a rewind) or dcaenc (for using a broken interface - but
the motivation was to reduce the boilerplate code that propagates all calls,
and to use the standard slave syntax).
> However, the performance argument is correct, and valid, as alsa-lib
> will end up converting samples without PulseAudio knowing about it.
--
Alexander E. Patrakov
