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

[Alexander E. Patrakov]

2014/1/14 Takashi Sakamoto <o-takashi at sakamocchi.jp>:
> I have an thought that this is an issue in PulseAudio-side. So I can post to
> alsa-devel to gather good ideas, not to resolve this issue.
>
> Here, I introduce my thought for this issue:
>
> 1.0 'alsa-lib' already gives a way to resolve channels/rates/formats
> mismatch between applications and ALSA drivers.
> 1.2.It's 'plug' plugin.
> 1.3.Source package of 'alsa-lib' includes default configurations. It's
> applied to all of PCM drivers. All of PCM drivers have 'plughw' in user-land
> configuration.
> 1.4.Then ALSA applications can resolve channels/rate/formats mismatch with
> 'plughw'.
>
> 2.0 In a relationships to ALSA, PulseAudio is one of ALSA applications.
> 2.1 PulseAudio opens ALSA PCM handler with flag of
> 'SND_PCM_NO_AUTO_RESAMPLE', 'SND_PCM_NO_AUTO_CHANNELS' and
> 'SND_PCM_NO_AUTO_FORMAT'.
> 2.2 This means 'When PulseAudio resolve such mismatch, PulseAudio don't use
> alsa-lib functionality, just manage by itself'.
> 2.3 This strategy works well for 'typical' sound devices with stereo/surrund
> channels.
> 2.4 But once PulseAudio encounter 'non-typical' sound devices, it fails to
> detect automatically.
>
> 3.0 One of 'non-typical' is ICE1712 based sound device.
> 3.1 ICE1712 has simple rules for its channels/rates.
> 3.2 So configuration with 'route' plugin can be a solution for this issue.
> 3.3 Then, for ICE1712, PulseAudio doesn't follow strategy 2.2. PulseAudio
> uses 'alsa-lib' functionality.
> 3.4 This was a solution for this issue, at a glance.
>
> 4.0 One of 'non-typical' is Firewire sound device for studio use.
> 4.1 This type of devices have variety of channels/rates.
> 4.2 So a solution with 'route' plugin can't apply.
> 4.3 Then this issue appears again.
>
> (When applying a solution with 'route' plugin, I must maintain much files
> for each configuration of devices. It may be over 100 configurations in
> 'alsa-lib'. This is... this is...this is not reasonable...)

I think I agree with the analysis. Let me reword what I think is important here.

PulseAudio basically disables all plugs by opening the PCMs with
SND_PCM_NO_AUTO_* flags. For the rate conversion and sample format
conversion, it already contains working replacements for the plug
functionality, but not for the channel count. Instead, it assumes that
such functionality (talking to well-known ALSA devices, giving them
less channels than they really support) is never needed. For your
hardware, this assumption is false (especially because of the rule
that relates sample rate and the only available channel count), and
the situation needs to be fixed somewhere.

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.

-- 
Alexander E. Patrakov