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
