Optimal Settings for DTS downconvert on BD rip
#1
Hi all,

I wanted to see if anyone has been consistently successful with overlocking their Pi to consistently play full BD Rips while downconverting DTS to stereo over hdmi. I am running latest Openelec but haven't been successful with RaspBMC RC5 either.

Anyhow, I'm operating off a wired network and know that if I force to bitstream the DTS stream, playback is rock solid. Where I run into trouble with some buffering is when I switch that to down convert the DTS stream to 2.0 to my TV, I get stuttering on high bitrate scenes. I've been using a BD rip of Avatar to test and scenes up to 30 Mbps work fine. It's when they move above 30 Mbps that the stuttering starts every 5-10 seconds.

I guess what I'm asking is if anyone has determined the optimal overclock settings for DTS decode. I'm not sure how the software works and what parts of the pi the software is using to do the decode.

I'm currently running:

arm=1000
core=550
sdram=600

I know we can control individual parts of the gpu, but i'm not sure if that would help.

Anyone successful doing this with high rate bd rips? My bd rips are made using MakeMKV.

Thanks!!
Reply
#2
I think full BD rips will only work with DTS passthough.
We are working on licensing for GPU to decode the DTS audio which should also work, but DTS have said we need to pass compliance tests, but have been unresponsive when we've asked for the test files.
An ugly workaround is to convert the audio to stereo on a PC before trying to play. That may work and should only take a few minutes.
Reply
#3
I did quite a bit of experimenting with overclocking to get DTS to work for me in downmixed to stereo mode. Can´t promise it works for you.

In my experience arm, core and sdram needs to be bumped as high as possible, and you also need to reduce the hdmi fps setting in config.txt. Also if you reduce the size of xbmc cache in advancedsettings.xml it helps a bit.

<network>
<cachemembuffersize>5242880</cachemembuffersize>
</network>

If I remember correctly DTS downmix worked also with underclocked gpu settings so you are right that does not matter much. For a few days I needed to actually underclock gpu to avoid the sudden reboots when the chip used to much current. That was before I found the current_limit_override setting. In the end I overclocked also gpu, but I don´t remember why. Maybe I noticed some improvement with overclocked gpu, maybe not. I can not remember.

Of course my overclock settings voids warranty.
http://openelec.tv/forum/134-usage/36686...t=40#46292

I have my OS installed to a USB disk and only keep the kernel and bootfiles on the SD-card, but that should not matter for DTS playback, I did that for other reason.

If you find some other improvement that can be done, let me know.
Reply
#4
(2012-10-18, 20:30)Tompen Wrote: In my experience arm, core and sdram needs to be bumped as high as possible, and you also need to reduce the hdmi fps setting in config.txt. Also if you reduce the size of xbmc cache in advancedsettings.xml it helps a bit.
That's counterintuitive. As file reading (either through network or sdcard/usb) takes a significant percentage of arm's cpu, I'd predict the best behaviour would be to have a large cache and the file reading thread be low priority. Then when things are falling behind, the data is just drained from the cache and the cpu normally needed for file reading can help with shuffling data and audio decode.

Possibly a larger cache gets written to disk (it shouldn't be - there is enough free memory on the arm for > 10M of cache).
Possibly the file reading is too high priority, and so competes with shuffling data and audio decode (and a larger cache has more opportunity to compete).

It's interesting - useful if others see the same behaviour.

(2012-10-18, 20:30)Tompen Wrote: If I remember correctly DTS downmix worked also with underclocked gpu settings so you are right that does not matter much.
Yes, we can decode 1080p video with h264_freq at about 150M, so there is little to be gained from overclocking it.
Similarly the 3d hardware is almost always asleep when handling the GUI, so overclocking that has little effect.

The ARM is the bottleneck, so get that as high as possible. core_freq and sdram_freq help its cache and memory accesses which should also be as high as possible.
Reply
#5
In my experience, DTS downmix just *barely* works fine with OpenELEC (definitely not Raspbmc or XBian) using arm_freq=850 / gpu_freq=325 / sdram_freq=425 / force_turbo=1, provided nothing else is happening in the background like library updates or XBMC checking resolution/video lengths etc.

In my case I also tested using MakeMKV remuxes of Avatar and Watchmen (to test VC-1), both with DTS (1.5Mbps core, no HD) and streaming over NFS from a FreeNAS box. I'd imagine SMB etc. would be taking up quite a bit more CPU usage.

edit: I took popcornmix's advice, left the GPU clocks alone, and tried the equivalent of raspi-config's 'High' overclock (arm_freq 950 / core_freq 450 / sdram_freq 450 / over_voltage 6 / force_turbo 0) and that worked fine. According to top, XBMC CPU usage was 79-82% CPU usage when playing Avatar & decoding DTS.
Reply
#6
I'm seeing something I completely didn't expect, but good news.

I did try to raise the arm_freq as high as I could. I got it up to 1150mhz without a problem, steady etc with a core_freq=575 with overvoltage=8. Funny thing was is that it didn't seem to help the stuttering, in fact it seemed worse. Also using Avatar BD rip made with MakeMKV playing back the DTS core track as well.

So I tried something different, and dropped frequencies back to arm_freq=1000 core_freq=500 sdram_freq=600. Funny, the stuttering is all gone. Scenes that would choke at exactly the same frame before at high OC settings are playing through.

Downside is that scrolling in poster wrap in the movie library is definitely worse, where the posters render much slower than at the higher overclocks.

Going to adjust arm_freq and core_freq independently to see if I can find a sweet spot where playback is good and gui is good.

Running latest Openelec build r12253.
Reply

Logout Mark Read Team Forum Stats Members Help
Optimal Settings for DTS downconvert on BD rip2