On Tue, 31 Jan 2017, at 07:39 PM, Tanu Kaskinen wrote: > On Sun, 2017-01-29 at 10:36 +0900, Takashi Sakamoto wrote: > > On Jan 29 2017 01:08, Tanu Kaskinen wrote: > > > The pa_channel_map_init_extend() call later in the function crashes if > > > if ss->channels is greater than PA_CHANNELS_MAX. > > > > > > Reported here: > > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-January/027404.html > > > --- > > > src/modules/alsa/alsa-util.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > Reviewed-by: Takashi Sakamoto <o-takashi at sakamocchi.jp> > > Tested-by: Takashi Sakamoto <o-takashi at sakamocchi.jp> > > Thanks! I pushed the patch now. > > > I tested with a device which has 34ch capture and 30ch playback. > > PulseAudio adds a sink for the playback PCM substream with multichannel > > profile, and ignores the capture PCM substream. > > > > But I think there's a space to discuss this issue more. In this world, > > we have some devices with over-32ch, or users can add virtual sound card > > with over-32ch. Although such users seem to work without PulseAudio, > > it's better to drop this kind of restriction for better future of this > > sound server. > > Being able to use a 32-channel subset of the available channels would > be a very welcome addition for the alsa modules, but without concrete > use cases I don't think it makes sense to implement support for more > channels outside the internals of the alsa modules, due to the > invasiveness of the required changes. > > Another idea: it would be generally useful to split alsa devices into > multiple sinks more easily than by fiddling with module-remap-sink. > Such splitting feature could perhaps also be used to split e.g. a 64- > channel device into two 32-channel sinks. > > -- In the mean time, should we bump up PA_CHANNELS_MAX so that these cards work out of the box? -- Arun
