[pulseaudio-discuss] [PATCH] alsa: Remove four channel input profile

[Tanu Kaskinen]

On Fri, 2014-08-08 at 11:26 +0200, David Henningsson wrote:
> 
> On 2014-08-08 11:11, Tanu Kaskinen wrote:
> > Would you agree that it would be good to modify the remapping/remixing
> > logic so that if one side of the remapping has only unspecified
> > channels, then the mapping should be simply channel index based, i.e. if
> > the other side has channels aux1,aux2,aux3,aux4 and the other side has
> > front-left,front-right, then aux1 should be mapped to front-left, aux2
> > to front-right and aux3 and aux4 should be discarded? Pretending that a
> > 4-channel mic array has rear channels doesn't make sense - if an
> > application records a stereo stream, I don't think remixing the
> > pseudo-rear channels to the stream is likely to have any better result
> > than just picking the two first channels of the array.
> >
> > A separate issue that came to my mind is that I'd actually prefer using
> > the mono channel position to mean "undefined". That is, instead of using
> > maps like aux1,aux2,aux3,aux4, I'd like to use mono,mono,mono,mono. The
> > remixing logic of course then needs to be adapted to treat mono channels
> > as undefined instead of thinking that all four channels should be mapped
> > to all the counter party channels like I think is currently done (if
> > there's only one mono channel, that should be treated as a special case
> > with the same semantics as are currently used). The name "mono" is
> > unfortunate, because it implies that there is only one channel in the
> > stream, so having multiple mono channels in one stream appears strange.
> > It would be nice to have "unspecified" as the name instead - I think
> > this can be made an alias. Something to note is that alsa doesn't have a
> > "mono" at all in its position enumeration, but it does have
> > "unspecified".
> >
> > pa_simple_new() without a channel map should ideally result in an
> > unspecified channel map, not a surround map. Changing this requires
> > fixing the remapping logic first, though.
> >
> > If you agree that these changes would be a good thing, I'll add that to
> > my "list of things to do during the next decade" (it's a long todo list
> > of random lower priority things that I work on occasionally in fifo
> > order).
> 
> This seems to require some careful thought in order to not break 
> existing applications, so I'm not sure. Is it okay to defer the 
> discussion to the next decade? (Or to whenever somebody feel like 
> actually working on this.)

Sure.

-- 
Tanu