[pulseaudio-discuss] 'Failed to find a working profile' for firewire sound devices

Alexander E. Patrakov patrakov at gmail.com
Thu Jan 16 01:02:29 PST 2014

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

More information about the pulseaudio-discuss mailing list