Currently, if remixing is disabled in daemon.conf (enable-remixing=no), playing a mono stream to a stereo sink results in silence. There should be a possibility to enable remixing only when adapting audio between mono and non-mono. The suggested solution is to add "mono-only" as a possible value for the enable-remixing option (currently only "yes" and "no" are supported). I already made a patch that changes the behavior of the "no" option so that remixing between mono and non-mono would still be enabled, but that approach got opposition: "no" should mean "no", not "no, except sometimes yes". My patch is probably a useful starting point anyway, so here's a link to it: https://gitorious.org/~tanuk/pulseaudio/tanuk-clone/commit/97906429424dbd8a047b5e34dc3568bc6cbdb508
I can't understand why this hasn't been implemented yet... (In reply to comment #0) > I already made a patch that changes the behavior of the "no" option so that > remixing between mono and non-mono would still be enabled, but that approach > got opposition: "no" should mean "no", not "no, except sometimes yes". If that's the problem change this to something like: # 1 - full remxing, 2 - mono-to-stereo only, 3 - off ; remixing=1 Applications having the power to ask for remixing on-demand yould be awesome but that's another bug I guess. Thank's creating this patch. Pulseaudio upmixing everything to 5.1, in my case, is (for lack of better words) fucking stupid and retarded.
Please, automatic upmixing non mono streams is ridiculous and with remixing disabled ("no" option), the playback of mono streams should be in front-left channel at least, but silence is what we have.
*** Bug 60292 has been marked as a duplicate of this bug. ***
Created attachment 124454 [details] [review] Mono only remixing patch This patch adds a new config option, to allow remixing only between mono and non-mono streams.
I have created a new patch against the current git master. It adds a new configuration option to daemon.con (mono-only-remixing) which is disabled by default, so it won't interfere with an existing configuration. When set to yes it will disable all remixing, except between mono and non-mono streams. If enable-remixing=no is set, it will not change current behavior, so remixing will be disabled completely.
Thanks for the patch. I have not tested it yet, but the added code looks sensible - assuming that the "remix only between mono and non-mono" is indeed the setting which is needed. Which is actually up to discussion, and I am afraid of proliferation of settings that end up being insufficient anyway. My own opinion about the whole remixing issue is below. Some people want stereo sources to be upmixed to their 5.1 speakers. The motivation seems to be that they actively object to unused output channels. That's the group for which the default remixing rules (which protect both against unused outputs and unused inputs) are fine. Other people don't want stereo sources to be upmixed to 5.1. The motivation is that such upmixing often destroys pin-point spatial localization of musical instruments in the composition, i.e. adds unwanted ambience. However, their needs are misinterpreted, as if they were saying that they don't want any remixing at all. And of course, everyone wants to use VoIP and films with 5.1 soundtracks (that often have important information in center and rear channels) on headphones. I think that "remix mono only" formulation captures a subset of the problem. The real problem is that input channels are lost, and "mono source" is just an important special case. In other words, my opinion is that two modes should exist: 1. The current one, equivalent to enable-remixing = yes. It avoids both unused inputs and unused outputs. 2. A new one, to be used instead of the current enable-remixing = no (because the only use case for this seems to be for speaker calibration tools, which should request this via the API). It should avoid unused inputs, but should not try to connect "something" to otherwise-unused outputs. As for the opposition mentioned in the original report, I think it won't apply to this new proposal. Upmixing is either enabled or disabled, no "no, except sometimes yes". Downmixing is always enabled.
how do pulseaudio treat mono , left and right channel map when playing mono audio ? it seem that those mono system sound are playing to left and right using the corresponding channel map those alsa drivers which support mono are supposed to copy mono to both left and right channels and seem not copy mono to all channels when they support multi channels
https://bugs.freedesktop.org/attachment.cgi?id=123531 ( 23.816| 0.000) I: [pulseaudio] resampler.c: Forcing resampler 'copy', because of fixed, identical sample rates. ( 23.816| 0.000) D: [pulseaudio] resampler.c: Resampler: ( 23.816| 0.000) D: [pulseaudio] resampler.c: rate 48000 -> 48000 (method copy) ( 23.816| 0.000) D: [pulseaudio] resampler.c: format s16le -> s16le (intermediate s16le) ( 23.816| 0.000) D: [pulseaudio] resampler.c: channels 1 -> 2 (resampling 1) ( 23.816| 0.000) D: [pulseaudio] resampler.c: Channel matrix: ( 23.816| 0.000) D: [pulseaudio] resampler.c: I00 ( 23.816| 0.000) D: [pulseaudio] resampler.c: +------ ( 23.816| 0.000) D: [pulseaudio] resampler.c: O00 | 0.000 ( 23.816| 0.000) D: [pulseaudio] resampler.c: O01 | 1.000 ( 23.816| 0.000) I: [pulseaudio] remap.c: Using stereo arrange remapping ( 23.817| 0.000) D: [pulseaudio] memblockq.c: memblockq requested: maxlength=33554432, tlength=0, base=4, prebuf=0, minreq=1 maxrewind=0 ( 23.817| 0.000) D: [pulseaudio] memblockq.c: memblockq sanitized: maxlength=33554432, tlength=33554432, base=4, prebuf=0, minreq=4 maxrewind=0 ( 23.817| 0.000) I: [pulseaudio] sink-input.c: Created input 2 "Front Right" on alsa_output.pci-0000_01_07.0.analog-stereo with sample spec s16le 1ch 48000Hz and channel map front-right ( 23.817| 0.000) I: [pulseaudio] sink-input.c: event.id = "audio-channel-front-right" ( 23.817| 0.000) I: [pulseaudio] sink-input.c: media.name = "Front Right" ( 23.817| 0.000) I: [pulseaudio] sink-input.c: media.role = "test" ( 23.817| 0.000) I: [pulseaudio] sink-input.c: media.filename = "/usr/share//sounds/freedesktop/stereo/audio-channel-front-right.oga" ( 23.817| 0.000) I: [pulseaudio] sink-input.c: application.name = "libcanberra" as libcanberra can play mono file to right channel,
Alexander's proposal sounds pretty good to me. I'll elaborate it a bit, according to my understanding of the proposal. The "enable-remixing" option would be de-emphasized in the documentation (e.g. dropped from the default daemon.conf), because nobody really wants to disable all remixing. We can still support "enable-remixing=no", but in practice the option will be almost always set to "yes". Then there would be a new option: "remix-to-fill-all-output-channels" (other naming ideas are welcome). Setting it to "yes" would enable upmixing to all unused channels, except lfe. "enable-lfe-remixing" would remain unchanged. In this scheme mono audio would be played to all channels even when "remix-to-fill-all-output-channels" is set to "no". That seems ok to me, but I'm not one of those who is annoyed by the upmixing of stereo streams (I don't have a surround system anyway), so comments from that crowd would be welcome.
Proposal for the new option name: enable-channel-upmixing or even enable-upmixing
(In reply to Alexander E. Patrakov from comment #10) > Proposal for the new option name: enable-channel-upmixing or even > enable-upmixing "enable-upmixing" was what I first thought of too, but then it occurred to me that mixing e.g. mono to all channels seems like upmixing too, which is not covered by the new option. But I'm fine with "enable-upmixing" if other people prefer it.
This is now fixed in the "next" branch. There's a new daemon.conf option, "remixing-use-all-sink-channels". By default it's set to "yes", which keeps the old remixing behaviour. Setting the option to "no" changes the remixing logic so that we don't try to fill all output channels if there are no corresponding input channels, but all input channels are still mixed to some output. Thanks to David Mandelberg for implementing the change, and to Alexander Patrakov for coming up with the idea!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.