2016-09-22, 07:30
http://mirrors.kodi.tv/test-builds/andro...bi-v7a.apk dts, ac3,eac3. The latter via 2channel 4*samplerate, e.g. 192 kHz. Please report back about your headposition implementation.
(2016-09-21, 22:40)fritsch Wrote: To speedup things: http://jenkins.kodi.tv/job/Android-ARM/9262/ please test this.
Also tell me about the plan on how you inmplement GetHeadPosition for dts-hd / truehd - so that I can implement that. We open 2 channels, but send 8 channels 192 khz - while AE thinks we consume 8 channels, that we need to account for.
(2016-09-23, 07:23)mo123 Wrote: This is where HD Audio is working.
I asked about the headposition but still waiting for feedback, maybe you can see something that might help?
https://github.com/JamesLinEngineer/RKMC...q=head_pos
The changes in SPMC, MrMC might also help since it is more for Android devices, I dont know?
https://github.com/koying/SPMC/search?ut...q=head_pos
https://github.com/MrMC/mrmc/commits/master
(2016-09-24, 15:20)mo123 Wrote: Just some feedback
Kodi 17.0-BETA3 Git:20160922-88437be Log
http://pastebin.com/kUCMCHiw
DTS and DD work fine.
Stereo sound is out of sync. Wonder what is causing this?
LPCM 5.1 is playing as LPCM 2.0(This might be a firmware problem as I see there was a new patch recently made, will try to build firmware with it later on - https://github.com/rockchip-linux/kernel...ea1936ded1)
When playing a DTS-HD file the amp is seeing the input as DTS-HD but there's no output, so no sound.
Dolby True HD is not giving any input on the receiver so also no sound.
I see you made several new builds, will wait and also try to get test logs later on with the newest one.
(Auto frame rate switching is maybe also something that will help with audio/video in sync but that is a completely different topic and I'm not sure if someone will work on that for Android at the moment. I already have the code to make it work on my devices, but I will open a new thread for that. The problem is lots of Android devices handle it differently and I don't know if there is a universal way to make it more compatible on Android?)
Quote:First, to be sure we are on the same page, we are speaking about the following API's:
- Current display mode: https://developer.android.com/reference/...#getMode()
- List of available modes: https://developer.android.com/reference/...tedModes()
- Set current mode: https://developer.android.com/reference/...playModeId
Next, we have to split the problem in 2:
1) The "Physical size" of Display.Mode, and what it represents
2) The refresh rate
1) "Physical size"
The API is actually unclear on what it means. Is it the "HDMI" size or the "Framebuffer" size?
For Amazon Fire TV 4K, it's simple, because they are able to switch their framebuffer size on-the-fly, so the FB size always equals the HDMI size.
Shield has the same issue as AML, and always return the FB size.
I'd suggest that AML returns the available HDMI resolutions. That will allow Kodi to switch resolution by itself, which has a number of benefits.
On the Kodi size, we'll have to make sure to get the proper FB size "somehow", to prevent rendering unecessarily in 4K.
2) Refresh rate
Shield "cheats" in that, as I said, it always returns the FB size (1080p) but attaches the available refresh rates of the current HDMI resolution.
There is probably some FW magic that translates a "fake" 1080p30 mode to 2160p30 if the Shield is running in 4K.
If AML goes with the previous suggestion of returning the actual HDMI modes, that is a non-issue.
We indeed expect fractional refresh rates to appear on the list, as we have some logic to properly switch to, e.g., 23.976 or 24 depending on the video.
We also use that value for A/V sync, so if Kodi thinks the display is running at 24p while it's really in 23.976, it'll lead to issues.
(2016-09-25, 12:57)fritsch Wrote: For what it's worth: Please test the upcoming amlugly build.
For other aml users: you can test that too.