Raspberry Pi Forums

Posted: **Thu Jan 03, 2013 2:06 pm**

I think we all have done what we can do. We are just need to keep working on letting DTS know that we are not going away until we get the licenses that we need.

Posted: **Thu Jan 03, 2013 2:30 pm**

In the meantime, until hardware DTS decoding is available, is there a workaround for streaming 1080P Video with DTS? I am currently using Rasbmc but am open to other versions of XBMC on Raspberry Pi. My files are the full size output from MakeMKV and I would strongly prefer not having to use something like handbrake to transcode my movies. I would be fine with just stereo sound for now as long as playback was smooth. I am sure I am not the first to ask this question, but Goggling did not turn up an obvious answer. Thanks.

Posted: **Thu Jan 03, 2013 2:48 pm**

mjsandbe wrote:In the meantime, until hardware DTS decoding is available, is there a workaround for streaming 1080P Video with DTS? I am currently using Rasbmc but am open to other versions of XBMC on Raspberry Pi. My files are the full size output from MakeMKV and I would strongly prefer not having to use something like handbrake to transcode my movies. I would be fine with just stereo sound for now as long as playback was smooth. I am sure I am not the first to ask this question, but Goggling did not turn up an obvious answer. Thanks.

You could try this tool:
http://www.networkedmediatank.com/showt ... ?tid=20887
which can convert dts audio to ac3, whilst leaving the video untouched, so it is quite quick.

Posted: **Thu Jan 03, 2013 3:00 pm**

ghans wrote:Oh yeah , the distributors will like that.
Just imagine a board with license and without license
getting mixed up , that is already a case of license fee evasion
if undetected ....

ghans

You think a professional distributor who carries hundreds of products cannot somehow cope with two variations of one particular product? LOL, genius.

Posted: **Thu Jan 03, 2013 3:02 pm**

gman529 wrote:I think we all have done what we can do. We are just need to keep working on letting DTS know that we are not going away until we get the licenses that we need.

Damn straight!

Keep the pressure up!

Posted: **Thu Jan 03, 2013 3:09 pm**

@1080p_at_35b
Well i know a distributor which has problems with a certain
low-margin product advertised to consumers ...

ghans

Posted: **Thu Jan 03, 2013 3:38 pm**

mjsandbe wrote:In the meantime, until hardware DTS decoding is available, is there a workaround for streaming 1080P Video with DTS? I am currently using Rasbmc but am open to other versions of XBMC on Raspberry Pi. My files are the full size output from MakeMKV and I would strongly prefer not having to use something like handbrake to transcode my movies. I would be fine with just stereo sound for now as long as playback was smooth. I am sure I am not the first to ask this question, but Goggling did not turn up an obvious answer. Thanks.

You may be interested in XBian. Back up this thread a little you can see that it has potential to allow for smooth playback of DTS already. I can't guarantee it of course but if you don't want to try dom's handy option, XBian could be worth a look. The people behind XBian are working daily to ensure that any and all optimisations, from either nightly XBMC builds, the Raspbian distribution or the Linux kernel itself, are applied and made available to users as easily and quickly as possible.

Sometimes development speed that fast can cause somewhat of a bleeding edge scenario however at least XBian focuses on the Raspberry Pi whereas OpenELEC, another alternative no doubt worth investigating, develops for many platforms which may arguably dilute focus. About 6 months ago I tried both Raspbmc and OpenELEC before XBian and had problems with both however with XBian it was third time lucky! I would be interested to see how the current version of OpenELEC treats the test file I mentioned earlier though. XBian has a helpful and objective community accessible via their forum, IRC on Freenode and social media. Just last night one participant in IRC admitted running OpenELEC and being quite happy with the results, but he remained interested in XBian.

Good luck finding your solution but I think you can feel safe that there is one out there, even though Google is not so good for finding answers to specific qualitative queries like this one

I feel good about a positive resolution to this problem everyone. Keep your chins up!

Posted: **Thu Jan 03, 2013 3:53 pm**

ghans wrote:@1080p_at_35b
Well i know a distributor which has problems with a certain
low-margin product advertised to consumers ...

ghans

That's a shame. Hopefully it will not come to a situation where there's a little extra pressure on distributors. It already seems like, from dom's news about the code being ready and DTS finally talking with the Raspi Foundation, that we are only the home straight away from the finish line.

Posted: **Thu Jan 03, 2013 4:25 pm**

Kainz wrote:Sure hope that we hear from Dolby :/

For those who may not be aware, Dolby Digital (DD) is also known as AC3 and you may find that you already have support for AC3//DD in your HDMI device, particularly if the device is a reasonably new TV. I can't comment on how this may relate to HDMI computer monitors and TVs in different regions of the world might differ to mine, however I use an LG and a Sony TV and both of those have support for AC3/DD built in!

Of course my TVs are just standard two-speaker units but what happens with XBMC (at least I can testify to this with XBian) is that if your TV or surround sound receiver supports AC3/DD (or maybe even DTS), XBMC will go into 'pass through' mode. This means that the audio channel(s) of a video bypass the Raspberry Pi CPU and are fed directly to the TV or surround system untouched. From there the TV or surround system's own hardware and AC3/DD (or perhaps even DTS) support will downmix the audio (in my case, since 5.1 channels does not squeeze into 2.0 speakers without downmixing) and play it back smoothly.

To find out if your HDMI device supports DD/AC3 (or maybe even DTS), SSH into a Raspberry Pi distribution such as Raspbian or any of the three main boot-to-XBMC distributions (Xbian, OpenELEC or Raspbmc) and run this command:

Code: Select all

/opt/vc/lib/tvservice -a

In my case, with XBian running on my Pi and HDMI hooked up to my Sony Bravia KDL-32W5500, I see the following output:

Code: Select all

     PCM supported: Max channels: 2, Max samplerate:  48kHz, Max samplesize 24 bits.
     AC3 supported: Max channels: 6, Max samplerate:  48kHz, Max rate  640 kb/s.

So you can see that the second line indicates the Sony supports DD (AC3) 5.1 (5+1 = Max channels: 6).

Sorry for waffling a bit in this post but I thought I'd go into a little detail in case it might help. If you want any more help, please let me know.

Posted: **Mon Jan 07, 2013 8:16 am**

Any recent update on this topic?

Will we get hardware accelerated decoding of DTS-Streams?

Posted: **Thu Jan 10, 2013 4:32 am**

I'm sorry; I'm not sure if I understood correctly. Is downmixing to 2.0 PCM from multichannel DTS *forced* when not bitstreaming? Can't just output the original channels (5.1, 7.1, you name it) in PCM? Because this has been my experience, with a 7.1 receiver, and I'm not sure what to make of it.

Posted: **Thu Jan 10, 2013 4:37 am**

I'm waiting on this as well. Some of my 1080p content runs piss poor because of this. Unfortunatly my TV and Reciver both have Dolby decode but not DTS. I'm not a huge fan of re-encoding.

Whoever owns rights to DTS is missing out on some free money here.

Posted: **Thu Jan 10, 2013 5:00 am**

In other words, I read this:

There are 3 scenarios.
DTS passthough: DTS 5.1 bitstream -> VCHIQ -> television
ARM decode: DTS 5.1 bitstream -> ARM decode to 6 channel PCM -> VCHIQ -> audio_mixer -> television
GPU decode : DTS 5.1 bitstream -> VCHIQ -> GPU decode to 6 channel PCM -> audio_mixer -> television

VCHIQ is the message passing interface from ARM to GPU.
The GPU decode is just software, as is audio_mixer (although 16-way SIMD accelerated, so more efficient than ARM).

So does audio_mixer automatically downmix to 2.0, capabilities of the device being outputted to be damned? That has been my experience, and I'm not sure if this is a bug or if it's intentional. I am also experiencing total silence with 7.1 AAC files atm.

Posted: **Thu Jan 10, 2013 5:28 am**

LastSilmaril wrote:In other words, I read this:
There are 3 scenarios.
DTS passthough: DTS 5.1 bitstream -> VCHIQ -> television
ARM decode: DTS 5.1 bitstream -> ARM decode to 6 channel PCM -> VCHIQ -> audio_mixer -> television
GPU decode : DTS 5.1 bitstream -> VCHIQ -> GPU decode to 6 channel PCM -> audio_mixer -> television

VCHIQ is the message passing interface from ARM to GPU.
The GPU decode is just software, as is audio_mixer (although 16-way SIMD accelerated, so more efficient than ARM).
So does audio_mixer automatically downmix to 2.0, capabilities of the device being outputted to be damned? That has been my experience, and I'm not sure if this is a bug or if it's intentional. I am also experiencing total silence with 7.1 AAC files atm.

Could this not be somewhat dependant on software? XBMC for example, has some settings relevant to this:

"Dolby Digital (AC3) capable receiver"
"DTS capable receiver"

When enabled, XBMC will pass (AFAIK) unmodified audio to the TV or receiver.

Some more XBM information is available here:

http://wiki.xbmc.org/index.php?title=AudioEngine

Posted: **Thu Jan 10, 2013 5:34 am**

1080p_at_35b wrote:
LastSilmaril wrote:In other words, I read this:
There are 3 scenarios.
DTS passthough: DTS 5.1 bitstream -> VCHIQ -> television
ARM decode: DTS 5.1 bitstream -> ARM decode to 6 channel PCM -> VCHIQ -> audio_mixer -> television
GPU decode : DTS 5.1 bitstream -> VCHIQ -> GPU decode to 6 channel PCM -> audio_mixer -> television

VCHIQ is the message passing interface from ARM to GPU.
The GPU decode is just software, as is audio_mixer (although 16-way SIMD accelerated, so more efficient than ARM).
So does audio_mixer automatically downmix to 2.0, capabilities of the device being outputted to be damned? That has been my experience, and I'm not sure if this is a bug or if it's intentional. I am also experiencing total silence with 7.1 AAC files atm.
Could this not be somewhat dependant on software? XBMC for example, has some settings relevant to this:

"Dolby Digital (AC3) capable receiver"
"DTS capable receiver"

When enabled, XBMC will pass (AFAIK) unmodified audio to the TV or receiver.

Some more XBM information is available here:

http://wiki.xbmc.org/index.php?title=AudioEngine

Thanks for the reply, but as I say, bitstreaming (what you just described) works just fine. I want to know if on-board decoding to PCM is forced to downmix and output 2.0 or not, because whatever the speaker configuration I specify in the settings don't seem to matter - it is always downmixed. This is true of AAC audio as well, which can't be decoded by most (I haven't actually encountered *any*) receivers on the market today.

Posted: **Thu Jan 10, 2013 5:52 am**

LastSilmaril wrote:Thanks for the reply, but as I say, bitstreaming (what you just described) works just fine. I want to know if on-board decoding to PCM is forced to downmix and output 2.0 or not, because whatever the speaker configuration I specify in the settings don't seem to matter - it is always downmixed. This is true of AAC audio as well, which can't be decoded by most (I haven't actually encountered *any*) receivers on the market today.

You seem to be determined to not mention what software setup you are using, for reasons which I guess are understandable

It's definitely a fascinating topic. I wish that we could know all there is to know on this topic. AFAIK in Windows the multimedia system (DirectShow ?) uses what they call 'graphs' which are, to me, can be displayed as flowcharts of each stage in the process from source to output. Here's an example of an open-source version of the software used:

I would love to see if our questions could be explained through a similar documentation style applied to the Raspi.

Posted: **Thu Jan 10, 2013 6:17 am**

1080p_at_35b wrote:
LastSilmaril wrote:Thanks for the reply, but as I say, bitstreaming (what you just described) works just fine. I want to know if on-board decoding to PCM is forced to downmix and output 2.0 or not, because whatever the speaker configuration I specify in the settings don't seem to matter - it is always downmixed. This is true of AAC audio as well, which can't be decoded by most (I haven't actually encountered *any*) receivers on the market today.
You seem to be determined to not mention what software setup you are using, for reasons which I guess are understandable

LOL, I'm sorry dude, I'm so used to posting in the media center and xbmc forums that I didn't see the need to mention that I'm using xbmc or totally process what you said. I'm using the latest builds of OpenELEC with XBMC 12.0-RC3.

Posted: **Thu Jan 10, 2013 6:29 am**

LastSilmaril wrote:
1080p_at_35b wrote:
LastSilmaril wrote:Thanks for the reply, but as I say, bitstreaming (what you just described) works just fine. I want to know if on-board decoding to PCM is forced to downmix and output 2.0 or not, because whatever the speaker configuration I specify in the settings don't seem to matter - it is always downmixed. This is true of AAC audio as well, which can't be decoded by most (I haven't actually encountered *any*) receivers on the market today.
You seem to be determined to not mention what software setup you are using, for reasons which I guess are understandable
LOL, I'm sorry dude, I'm so used to posting in the media center and xbmc forums that I didn't see the need to mention that I'm using xbmc or totally process what you said. I'm using the latest builds of OpenELEC with XBMC 12.0-RC3.

No worries mate, I can relate to that as I've been posting in the XBian forums myself.

I thought you might be deliberately excluding the software you are using in order to try and force anybody tempted to reply to think about the lower level of processing before it hits XBMC. FWIW I think "audio mixer" is XBMC but I could be wrong.

Posted: **Thu Jan 10, 2013 6:17 pm**

Downloaded xbian alpha 4. Has the exact same issue (and also doesn't recognize xbox 360/mce remote codes).

Posted: **Thu Jan 10, 2013 6:39 pm**

So according to this:
http://forum.stmlabs.com/showthread.php?pid=35504

right now, Multichannel PCM is not enabled (as I suspected). I'm not sure what the audio patch would entail - I would try to tackle it, even though I'd probably get a bit lost - but am also surprised more people didn't ask for one.

Posted: **Thu Jan 10, 2013 7:51 pm**

https://github.com/huceke/omxplayer/blo ... MRemap.cpp

It looks like OMXPlayer already checks to see what the output capabilities are. I don't think it hardcodes 2.0 over there. It could be that the check isn't done properly or something, but really this is speculation.

Posted: **Thu Jan 10, 2013 9:26 pm**

LastSilmaril wrote:https://github.com/huceke/omxplayer/blo ... MRemap.cpp

It looks like OMXPlayer already checks to see what the output capabilities are. I don't think it hardcodes 2.0 over there. It could be that the check isn't done properly or something, but really this is speculation.

There may be an issue with ALSA sound. The XBian people are waiting for ALSA to be supported (I can't remember by whom/what - Raspi, XBMC, something ...) before they can implement some audio features such as simultaneous analog and HDMI output. The following links may be of interest:

https://github.com/xbianonpi/xbian/issues/172
http://forum.xbian.org/thread-66.html

and to a lesser extent:

http://forum.xbian.org/post-1804.html

Please excuse some cross-posting within those links.

Posted: **Thu Jan 10, 2013 10:57 pm**

1080p_at_35b wrote: https://github.com/xbianonpi/xbian/issues/172

From there it seems like someone is working on a workaround for that specific issue (dual audio output via hdmi and 3.5mm analog at once) that doesn't involve either ALSA or PulseAudio.

In OMXAudio.cpp, the number of output channels is hardcoded to 2 (line 244)
https://github.com/xbmc/xbmc-rbp/blob/m ... XAudio.cpp
But I'm not sure how to find out how many channels are actually supported by output hardware/what the guisetting for audio is. There is a blob of code that's commented out that might do that, around line 250, but with no hint as to why or what else needs to be implemented for it to work.

Posted: **Thu Jan 10, 2013 11:11 pm**

LastSilmaril wrote:
1080p_at_35b wrote: https://github.com/xbianonpi/xbian/issues/172
From there it seems like someone is working on a workaround for that specific issue (dual audio output via hdmi and 3.5mm analog at once) that doesn't involve either ALSA or PulseAudio.

I think raspbmc has already implemented this but it has caused some unwanted side-effects.

LastSilmaril wrote:In OMXAudio.cpp, the number of output channels is hardcoded to 2 (line 244)
https://github.com/xbmc/xbmc-rbp/blob/m ... XAudio.cpp
But I'm not sure how to find out how many channels are actually supported by output hardware/what the guisetting for audio is. There is a blob of code that's commented out that might do that, around line 250, but with no hint as to why or what else needs to be implemented for it to work.

Sounds like you know your C/C++

Unfortunately I do not. I wonder if we might start a new thread on this topic though since, for better or worse, I *think* this topic is mainly focused on getting support (license) for GPU-assisted decoding of DTS streams. I guess this touches on your question of channels though. Tricky one. I don't want to seem like I am censoring. I didn't even start this thread

Essentially though, I think this topic might as well be renamed "Hardware-assisted DTS downmixing" because unlike yourself, I expect a lot of people might be happy with 2.0 DTS if the ARM CPU was capable of downmixing without choking too much, because that would at least allow anybody to play DTS audio movies. For me, it's a question of 5.1+ is great for those who can use it, but 2.0 is best because everyone can use it, albeit may not be ideal for those wishing for surround sound.

Posted: **Thu Jan 10, 2013 11:28 pm**

LastSilmaril wrote:
1080p_at_35b wrote: https://github.com/xbianonpi/xbian/issues/172
From there it seems like someone is working on a workaround for that specific issue (dual audio output via hdmi and 3.5mm analog at once) that doesn't involve either ALSA or PulseAudio.

In OMXAudio.cpp, the number of output channels is hardcoded to 2 (line 244)
https://github.com/xbmc/xbmc-rbp/blob/m ... XAudio.cpp
But I'm not sure how to find out how many channels are actually supported by output hardware/what the guisetting for audio is. There is a blob of code that's commented out that might do that, around line 250, but with no hint as to why or what else needs to be implemented for it to work.

Re guisettings, maybe here is a place to start:

https://github.com/xbmc/xbmc/blob/maste ... ttings.cpp

There is some documentation for that section here:

http://wiki.xbmc.org/index.php?title=Settings
https://github.com/xbmc/xbmc/blob/maste ... ttings.cpp

Then there is also:

http://wiki.xbmc.org/index.php?title=Ad ... ttings.xml
https://github.com/xbmc/xbmc/blob/maste ... ttings.cpp

and if something is configured in advancedsettings.xml, it will be hidden from the XBMC interface.

Not sure if that helps you at all.

Raspberry Pi Forums

Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding

Re: Hardware DTS decoding