I have a surround receiver that can handle AC3 sound, but not DTS through optical. I understand that XBMC (release candidate 2 frodo) should be able to transcode these files to AC3 without a problem, however, depending on settings, things don't work.
With audio output set to Optical/Coax, And AC3 capable receiver ticked, I get 2.0 sound from files in other codecs. This is the same if the output is set to HDMI.
However if i tick LPCM capable receiver with HDMI selected as well, i get the two surround channels coming from the front speakers and no other sound.
Everything works fine for AC3 files.
Is there a setting in mac os that could change this. The optical cable is connected to the mac using a 3.5 mm toslink adapter if that makes a difference.
Thanks
transcoding from dts/aac to ac3 is broken currently in the new audio engine. We are not able to quick fix this for frodo - we aim 12.1 for this.
@
Memphiz - I recall a commit from Davilla some time ago forcing 2.0 if device is optical. This is likely the cause of the 2.0 sound when transcoding from AAC/DTS > AC3
I'm unaware that optical can officially handle anything but two channels of audio which includes the fake that allows passthrough of ac3/dts.
And you're correct - they issue would be that DTS/AAC can be decoded to 5.1 pcm before transcoding, and it's there that the optical 2,0 force can kill the surround & LFE channels - while we're pcm.
PS - I copied that commit over to SoftAE and borked it the same way by doing so
http://forum.xbmc.org/showthread.php?tid=149369
eh ? optical cannot support 6 channels of pcm. I still don't get what you are saying/
It's during the intermediate stage between the decoding to PCM (gets forced to 2.0) and then re-encoding to AC3. Ends up as AC3 2.0 final output.
5b62277ae34a8ae9e11d24a677881f6a3254ee05 <- CA
c3bc136c2f6981fb36f4a5d824ee6d8d6e81d3c3 <- added to SoftAE just after
so how should this get fixed ?
Both can be safely reverted IMHO.
Both were added to fix the issue that users would select 5.1 and digital then the channels would be borked because it tried to do 6 channels over optical. So fix one problem but caused another. So they can't be safely reverted
If this fixes the 1h02min slowdown effect i'd get a laugh flash...
The real fix would be that we need to know if we are ending up in an 2.0 encoded format or not. If not - we need to clamp to 2.0 - if we do - no clamp needed and we would allow the intermediate lpcm state with > 2 channels.
DDDamian - any clue how this detection could be done? (basically we would need to detect the transcoding use case).
@
Memphiz - bingo. In master's OpenSink():
Code:
if (!m_transcode)
newFormat.m_channelLayout.ResolveChannels(m_stdChLayout);
else
{
if (m_masterStream->m_initChannelLayout == AE_CH_LAYOUT_2_0)
m_transcode = false;
m_encoderInitFrameSizeMul = 1.0 / (newFormat.m_channelLayout.Count() *
(CAEUtil::DataFormatToBits(newFormat.m_dataFormat) >> 3));
m_encoderInitSampleRateMul = 1.0 / newFormat.m_sampleRate;
}
}
I still think the analog/optical/HDMI setting should go and just be replaced with the more accurate / descriptive radio buttons + a few additions like:
- force transcode
- force 16 bit
- force 44.1 lpcm
yea, let's fill that audio section with more settings so we can get even more confused users
well the hdmi/analog/optical setting is more then confusing indeed - i think you will +1 that statement too...