On 2014-08-08 11:11, Tanu Kaskinen wrote: > On Thu, 2014-08-07 at 14:03 +0200, David Henningsson wrote: >> >> On 2014-08-07 13:18, Tanu Kaskinen wrote: >>> On Fri, 2014-08-01 at 18:13 +0200, David Henningsson wrote: >>>> With the new multichannel profile, we can remove this one and >>>> handle the four channel input as a generic multichannel fallback. >>> >>> I believe the generic fallback initializes the channel map to a surround >>> channel map that doesn't really make sense. Maybe we should modify the >>> fallback channel map logic so that if it's an input device, use stereo >>> map if the device is a stereo device, but otherwise use an aux-only >>> channel map. >> >> I think a surround channel map makes a lot more sense than an aux-only >> channel map. Most apps do a simple stereo recording, and AFAIK they will >> just record silence instead of recording the first two channels, if the >> channel map is aux-only. >> >> So this patch is improving the OOTB experience for those devices. >> >> If that didn't convince you, consider the fact that an app calling e g >> pa_simple_new() without specifying a channel map, will get a surround >> mapping by default, regardless of direction. I e, anything else than a >> surround mapping on the device level causes a mismatch. > > Ok, if a surround map actually improves things, even though it doesn't > make conceptual sense, feel free to apply this patch. Ok, thanks. > 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.) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
