(2014-06-25, 14:32)elsmandino Wrote: (2014-06-25, 05:02)pr0xZen Wrote: Passthrough is also worth keeping in mind. If you do use passthrough, XBMC volume control is out the door - its full blast in that end. If you do software decode/transcode, to always output (L)PCM - this will draw more resources. Might not matter much on a good rig, but it could weigh heavier on a Pi, low-level NUC etc.
Sorry, pr0xZen, but could you just clarify what that might mean for me please? Bit of a novice when it comes to that stuff.
Sure, which part was the confusing bit? I guess Kib might have clarified some of this a bit already. I'll give you a dissertation - it might be a bit of a read, but I've written it so that it should be simple to understand, and will hopefully enhance your understanding of how audio handling and connectivity works. In short; This knowledge will very much come in handy, and knowing how these things work - will make you capable of resolving many issues on your own.
There are 4 main ways to transfer audio from the "playback unit" (Computer, DVD/Blu-Ray player, Cable box, XBOX/PS3(/4) etc etc) - on to the next unit in chain - typically either an AV receiver, a pre-amp, stand-alone DAC or your TV. In case of any confusion - by "unit in chain", I mean (as an example): Computer -> AV receiver -> TV. This is a 3-point chain. I use this term because other users reading this, might have a setup consisting of more or fewer units.
- Passthrough
- (L)PCM
- Transcoding
- Analog
(For the "pros"; yes, there are more to it than this, but thats not relevant here)
Passthrough
AC3 (Dolby Digital), DTS, Dolby TrueHD, DTS-HD (DTS:MA) etc - these are all
encoded and to a varying degree, compressed audio streams (commonly called an
audio bitstream). They need to be decoded either by XMBC/other software, an AV receiver, your TV etc. The way "passthrough" work, is that the playback unit (in your case, the Pi running XBMC) takes that audio bitstream from the media source, and passes it on to the next unit (AVR, TV etc) untouched. This way, the "the next" unit in chain (need to) do the decoding of the audio bitstream. Unless for some reason the next unit
also is also configured to "passthrough", then
that unit will pass it along to the next one in chain, and so on.
As an effect of passing on this audio bitstream undecoded and untouched, XBMC (the playback unit) cannot modify or alter this audio in any way. This includes volume adjustment. To simplify it a bit; When a unit is performing audio bitstream passthrough - it doesn't see any "audio" or "sound", it just blindly passes on that data stream on to the next unit. It doesn't become "sound" / "audio", until this data stream is decoded. Volume needs to be adjusted either at the unit that does the actual decoding of the bitstream, or/and any unit "next in the chain" that does the actual sound output, audio post processing etc (in case you have a very high-end or complex AV setup).
In some instances and configurations, it seems to possible to adjust the volume level of an S/PDIF (optical/coaxial) output, on an OS level. This will depend on capabilities and limitations of settings, drivers and operating system - and if it works, it means adjusting "System" volume - which cannot be done within XBMC.
(L)PCM
Transferring audio from one unit to another through
Pulse-
Code
Modulation or
Linear
Pulse-
Code
Modulation, is basically trasferring a digital representation / "version" of either an original
uncompressed and
unencoded audio signal - or an audio signal that has already been decoded from AC3, DTS, Dolby TrueHD, DTS-HD / DTS:MA etc, to (L)PCM. The "original" audio should ideally be "perfect" still, as decoding is not a "variable" process; Either it comes out as it "went in", or decoding fails completely.
You can, however, adjust the volume. This alters the audio signal, but should not pose any real audio quality impact.
An (L)PCM audio stream does not need the "next unit in chain" to be capable of decoding any particular "audio format" (although it does have to be able to handle (L)PCM audio - which pretty much all units today except purely analog amplifiers, are). To go this route when doing playback of an
encoded audio format - either the software on the playback unit (XBMC), or the units hardware, has to perform the decoding of the audio stream from its original format, "down" to (L)PCM - and then pass the (L)PCM signal on to the next unit in chain. The next unit will then convert this uncompressed and unencoded audio signal to analog audio and amplify the sound for output to speakers. (Or, pass it on to the next unit - depending on your setup).
If your playback unit (Pi, computer, Android stick etc) does not have any dedicated hardware
specifically capable of / designed to decode those encoded audio bitstream formats - then you'll have to rely on software to do the decoding from [XX] encoded format, to (L)PCM. As the software is likely to "run" as any other software process, it will utilise your "main processor core(s)" to do so. Many of todays low-budget units used as media units, have fairly weak "main" processors. They still work well for media playback, as the most common "big main load" is video decoding, and modern units have (separate) internal hardware specifically designed to perform this task. Decoding AC3 or DTS isn't particulary resource demanding, but the HD audio formats take MUCH more resources to decode by means of software. While XBMC itself can decode most audio formats (not sure DTS-HD/DTS:MA is supported yet - licencing and all that), this doesn't automatically mean that your hardware can keep up. If it it can't - both video and audio playback will be lagging, skipping and so on.
Transcoding
Transcoding is a little bit like a "mix" of both cases above. It utilizes XBMC (software) - or dedicated hardware (very little hardware have dedicated transcoding support, but there probably is
some hardware out there that does this), to decode the original encoded audio format, then
encode it again, to a
different - compressed and encoded audio format (or if capable, transcode directly in a 1-step process).
Some might wonder "why would you waste resources on that?". Well, lets say you have an older AV receiver, that doesn't have HDMI connectivity. This means you'll have to rely on optical or coaxial S/PDIF connections, for digital audio connectivity. Another case is your source audio is DTS, but your AV receiver/TV etc, can only handle AC3. Not everyone knows it, but HDMI has an extremely high bandwith. Even with HDMI 1.0 the theoretical maximum was almost 5 Gbit/s - and HDMI 1.4; ~10 Gbit/s. Within specification standards,
audio bandwith for HDMI is 36.86 Mbit/s. For the much older S/PDIF, the story is different. Its a more complex thing to explain, but lets just say the theoretical maximum is closer to 15
Mb/s - and within standard specifications, audio max bitrate is
much lower than that.
This means, S/PDIF (optical/coaxial) has too small a bandwith to transport
either "multi-channel" (2.1 or more) PCM audio, or the encoded HD audio formats. Decoding a HD-audio format to (L)PCM is one thing, but the S/PDIF connection's low bandwith limits it to a maximum of
2 channel PCM. The only way to get 2.1/5.1 and the likes, across S/PDIF, is by means of AC3 or DTS formats. These 2 formats have a low enough bitrate to get through, due to their compression. So if your source material only has (for instance) a Dolby TrueHD audio track, and you want 5.1 surround sound out (through an S/PDIF connection) - you have to
transcode the audio from TrueHD format, to AC3 format (Or DTS, if your system can actually
encode DTS).
To do this, your AV receiver / TV etc (next in chain) needs to actually capable of decoding AC3 and/or DTS - and the
source/playback unit needs to support "bitstream passthrough". This is due to the fact that - while you
have already decoded the original audio format - you have also
re-encoded that output, into a new, differently encoded audio bitstream.
Transcoding means you have to
encode and compress the signal (again). At this point, audio quality WILL be affected. How much, depends on the quality of the encoder, and the processor resources available. It is usually possible to adjust the quality settings of transcoding and resampling, which in turn will affect how much resources are needed to perform the task. The last bit is
very important here, as trancoding is usually done "on the fly" - which means the playback unit needs to perform this task as fast as possible, for the audio to stay in sync with the video.
The good news here is that since you, in the process of transcoding, have to decode the original audio format - then you can alter the volume
before encoding the signal into the target format. Note: In a "1-step transcode process", this might not be an option. Also - to my knowledge, at the time of this post -
XBMC will not do transcoding of AC3 -> AC3. (Passthrough setting takes precedence over resampling settings). Hopefully there will be a "fix" / option for this, in the near future.
Analog
Analog output means that the hardware of your playback unit decodes the audio bitstream to (L)PCM, and then converts that digital signal to analog audio - before outputting it through (mini)jack, RCA or XLR connection(s) to your AV receiver / Amplifier / TV etc. This requires resources (CPU load or dedicated hardware) to do the decoding to (L)PCM. And it WILL impact audio quality. How much so, depends on the quality of the Digital -> Analog coverters (DAC) in your unit.
As this means the playback unit does "everything" except amplify the signal for speaker output, you can have full control of volume.
