ActiveAE: add advanced setting for forcing multichannel layout #4967
Conversation
Anthem Statement D2 audio processor only supports 2.0 and 5.1 HDMI playback properly, causing completely silent output if playback of e.g. a 4.0 audio stream is being done. Add "audio.fixedmultichannellayout" advanced setting for forcing the use of the user-specified layout in audio settings for multichannel streams in case the user has equipment that does not support all intermediate layouts properly. Stereo streams will continue to be played back as stereo and no resampling is done. Reported by Grant Warecki (gjwAudio).
|
Why does a fixed 5.1 setting in xbmc not do the same? |
|
jenkins build this please |
|
@Memphiz Two reasons AFAICS (feel free to correct me if I'm wrong):
|
|
Oops, sorry, I meant that audio output will be at 5.1 (with silent channels, not upmix), so the receiving device will not see it as stereo, which is not wanted. |
|
I don't think any consumer electronics device has such a setting. How do they work with the Anthem? Why does a 4.0 fail? Could you provide a log? Was that tested on more than one platform? Can we rule out an issue of the driver? |
They don't. Note that 4.0 is rather unusual in consumer electronics, but googling reveals that apparently 4.0 is somewhat common with classical SACDs and they do not work with Anthem D2. Here's a massive AVSforum thread where this issue is mentioned on several posts with SACD players (for some reason I can't find direct links): http://www.avsforum.com/t/678260/anthem-d2-d2v-avm50-avm50v-arc1-tweaking-guide
Because the hw does not like HDMI CA values that have 3-5 active channels for some reason.
I can get one if needed, don't have one right now.
Well, as per above, this issue exists with hardware SACD players as well, and we tested the behavior very extensively with the user (with speaker-test and driver tweaks), and it seems to be exclusively the HDMI CA value that upsets the receiver. I guess I could ask him to test with another platform if needed/possible. If this were some cheap Chinese receiver or something, I might be OK at leaving them broken and un-advanced-configurable, but this receiver is a rather high-end model (7000+ USD when it was new), albeit somewhat dated now (HDMI was still quite new at the time). |
|
Can't that be fixed in driver by just returning either FL,FR or the corresponding 5.1 Layout else? |
|
@fristch, based on what? EDID blacklist would probably be overkill (at least until/if we encounter other receivers with issues). A module parameter might be better, although it would probably be more code there than just adding the workaround in xbmc (and it isn't really driver-specific per-se, as this is about the receiver hw). Plus it would leave this broken on other non-Linux platforms... |
|
I am undecided here. Do we really want to add an advanced setting for a single user? At least a very limited number of users would benefit from this. How will we decide next time if a user wants a workaround for some buggy device?
In that range I would expect the manufacturer to move their asses and get this fixed. |
The same way we decide now, by performing cost/benefit-analysis, IMHO. There are three factors AFAICS:
Agreeing on weights might be difficult, though :) In this case, 1. Very few as far as we can estimate (1-3? assuming another use case for the option does not surface) => against option, 2. Not very => for option, 3. Quite infeasible => for option. As you probably have guessed, I'm for the option (not too strongly, though - maybe I'd feel more strongly about it if I had this piece of hardware myself, though...). Completely another way to go with this would be to make audio configuration more flexible in a more generic way, but I guess the benefits of that would be limited or even negative (unless there has been actual demand for (other) weird configs?)?
I guess the manufacturer considers it EOL at this point, unfortunately (or maybe, though unlikely, it is/was not software-fixable). Not sure if it was properly reported to them at the time when the model was more current, but there hasn't been firmware updates in years AFAICS. |
|
Reading the patch again - I am not against it. It is clean, non ambigous and non intrusive. For what's worth it, it fixes someone's audio.
wins by ++ |
|
Tomorrow the next user request an advanced setting in a similar context, the day after another, and so on, .... |
|
If we have a sane request on new settings that often, we should change our default settings capabilities, cause that would proof we are not general enough, btw. You just gave a proof why this setting should go in :-) |
|
I have cleaned out all this crappy advanced settings for audio not long ago. There must be a really really good reason for adding such a setting again. I don't consider 1-3 users with an EOL device as a good reason. |
|
I am quite interested in finding a more general configuration that can include this single user's hardware and make him happily use xbmc. The OSX guys workaround "different hardware" in the sink itself ... so what about doing that? With the disadvantage that this workaround is not platform agnostic. |
|
Dude has a $7k amp? I'll maintain a branch for him for $1k. |
|
why don't you add this as an additional mode and add it to the spinner? |
|
IMHO we should be able to avoid advancedsettings proliferation by periodically pinging out to see if a particular setting is used by anyone anymore (in addition to not adding them if the case is rare and easy to workaround/avoid)...
Because the mode seems somewhat arbitrary (as it is workarounding a specific hw issue), and adding it to the spinner and having translations for it etc. seems overkill (at least to me) for just a few users, while an advancedsetting would be less invasive, less confusing, and less developer-resource-intensive. As said, would be a different thing if we could come up with a more widely useful mode that happens to fix this as well. Anyway, if we can't find a solution to agree on, me providing a customized openELEC build periodically to the reporter is not too much work, but I'd like to avoid that if possible. @t-nelson, actually, this is a preprocessor - you get line level outputs so you'll need a separate amp |
|
Fine, $2k then. :) |
|
"fixed" mode is actually pike mode which also fits into the category "somewhat arbitrary".
only because nobody cares cleaning them out after a while. It was resource-intensive for me doing this job, one reason I am reluctant in adding those without a compelling reason. |
|
Thinking slightly outside the box, would this be taken care of once the DSP stuff comes in? i.e. a very simple DSP that just adds blank channels for 3, 3.1, 4, 4.1, 5.0 -> 5.1 ? If so, that seems a reasonable way forward given the code is somewhat on the way? |
|
@AlwinEsch is this scenario covered by DSP? |
|
Yes, if the DSP system is enabled it is always on the selected output and unused channels leaved empty. Reason there was to have for every add-on DSP Master and Post Process Mode the possibility for channel correction. Also if no up-mix (for stereo and upmix enabled) or down-mix (higher input layout, as output) is present on add-on side it becomes then performed by ffmpeg inside xbmc to the selected output channels. |
|
Also one point which must be checked with it. Is then channel alignment always correct? On DSP it has for different output types wrong channel alignment (here on alsa correct on pulse the surround and lfe channels was wrong). There it is fixed with limitation to ffmpeg channel layout until correction from sink output. see |
|
Can you emphasize on "right" or "wrong"? Is the mapping AE Channel Layout -> PA Layout faulty? https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkPULSE.cpp#L292 |
|
From my side wrong but unsure if was only with the dsp processing system from me. Mapping by me on every multichannel playback was wrong which have another channel alignment on sinks as from "CAEChannelInfo& CAEChannelInfo::operator=(const enum AEStdChLayout rhs)" channel layout. @anssih Was the alignment for you correct or must you change something for Anthem Statement D2? Performing currently a build for test of it. |
|
Fault confirmed, with a forced layout the alignment of the rear, side and LFE speaker is not correct here with ALSA and PULSE Audio. Have seen, this fault also present if the fixed output configuration is enabled. Can anyone else check it under different sound systems? |
|
Have added advanced setting to my system to check with channel alignment (dsp system off) and with call of "CActiveAEDSP::Get().GetDSPChannelLayout(stdChannelLayout)" the channel alignment is correct. Is there as temporary to see and check. |
…x fixed channel alignment (based upon pull xbmc#4967)
…x fixed channel alignment (based upon pull xbmc#4967)
|
Let me close it for now. New PR can be opened if wanted/needed and is rebased on current master branch. |
Anthem Statement D2 audio processor only supports 2.0 and 5.1 HDMI
playback properly, causing completely silent output if playback of e.g.
a 4.0 audio stream is being done.
Add "audio.fixedmultichannellayout" advanced setting for forcing the use
of the user-specified layout in audio settings for multichannel streams
in case the user has equipment that does not support all intermediate
layouts properly.
Stereo streams will continue to be played back as stereo and no
resampling is done.
Reported by Grant Warecki (gjwAudio).
@fritsch, @FernetMenta, WDYT? This basically becomes a oneliner in ApplySettingsToFormat() so IMHO it does not pollute the code too badly for a fix for obscure devices...