2011-04-22, 01:00
Hi bole5, is it possible for you to fix the AC3 passthrough issue? I'm asking since it's audio related too. thanks
2011-04-22, 01:01
ldi9999 Wrote:Hi bole5, is it possible for you to fix the AC3 passthrough issue? thanks
I believe thats a jailbreak issue, not an xbmc issue.
2011-04-22, 01:03
dtviewer Wrote:I believe thats a jailbreak issue, not an xbmc issue.
ok.
2011-04-22, 01:21
ldi9999 Wrote:I don't think he meant to ask for how to compile. He was most likely asking if he needs to compile.
Exactly I've download the source code this night and compiled it. is it still necessary apply the patch??
2011-04-22, 03:29
bole5 Wrote:After spending some time debugging the IOSAudioRenderer with the help of the new IOSAudioRingBuffer I think I finally fixed the problem with the video slowdown on FF/REW!
The result is a rock solid build (at least in my tests). I was not able to crash the ATV2 however I tried, but please give it a go and post about your experience
As usual I provided the full patch based on the latest trunk (20. April) and the binary.
The diff can be found on pastebin: http://pastebin.com/sTNUZHty.
This build should completely eliminate video slowdown and rebooting when doing a lot of FF/REW. Please follow the instructions below and report your results. The binary was build on Apr 20 2011 Git:20110419-28f5811. If you don't understand the instructions below, please don't even try this...
1. Download the compiled XBMC binary from: http://www.megaupload.com/?d=WW8PU73E
2. Copy the file XBMC using your scp client to the folder: /Applications/AppleTV.app/Appliances/XBMC.frappliance/
3. Restart the ATV2 by running: killall AppleTV in unix shell, or reboot your ATV2
Enjoy and don't forget to post your results in this tread
Nice, but I have a concern with IOSAudioRingBuffer and the reset function. It touches both read/write. A reset would most likely come from DVDPlayer and if audio codec is pulling from m_Buffer, you could get problems when reading if the thread switch happened at the wrong time. Also should not need the memset(m_Buffer,'\0',m_iSize) in reset. A reader will only read if there's something to read and then m_Buffer has valid contents.
CSliceQueue is really what you want to use, it's lockless and threadsafe. It does look complicated but it has to be to cover all the holes.
2011-04-22, 13:53
i5Js Wrote:Exactly I've download the source code this night and compiled it. is it still necessary apply the patch??
Yes, the patch is not included in the source code.
2011-04-22, 16:22
davilla Wrote:Nice, but I have a concern with IOSAudioRingBuffer and the reset function. It touches both read/write. A reset would most likely come from DVDPlayer and if audio codec is pulling from m_Buffer, you could get problems when reading if the thread switch happened at the wrong time. Also should not need the memset(m_Buffer,'\0',m_iSize) in reset. A reader will only read if there's something to read and then m_Buffer has valid contents.
CSliceQueue is really what you want to use, it's lockless and threadsafe. It does look complicated but it has to be to cover all the holes.
Thanks for taking your time for looking into this. Initially, I thought of using CSliceQueue but concluded that it adds a lot of overhead for our simple use case. In addition, the CSliceQueue is defined in the CoreAudioRenderer (together with CAtomicAllocator which it also requires) so using it requires changes to the CoreAudioRenderer too.
The IOSAudioRingBuffer is much simpler and it was created specifically for the needs of the IOSAudioRenderer (includes convenient GetReadSize() and GetWriteSize() methods).
You rightly pointed out that the Render() method is not thread safe, but I didn't worry too much about it since the Render() is only called on Flush(), which is only called on Stop(). The Flush() also sets the pause flag to true which prevents the OnRender() to read from buffer.
In order to mitigate the effects of the Reset() I removed the memset(), changed the ordering of variables that are reset and added comments in the code.
I just wanted to solve the problems with the ATV2 restarting and video slowdown before the new AudioEngine is finished. My understanding is that the AE is soon to come out and we are just waiting for the appropriate IOSAudioSink, so any additional work on the current renderer is a waste of everyone's time (IMO).
Would you prefer to embed the IOSAudioRingBuffer to IOSAudioRenderer? If you still think we should keep the old av_fifo buffer, please apply only the changes to the OnRender (remove call to Pause()) and that might suffice...
I uploaded the latest patch with changes discussed above to pastie: http://pastebin.com/rtUPfaSC
In the example of this buffer you showed yet again that you are really a great developer not wanting to accept a solution before carefully analyzing it and challenging all possible problem areas. This project is a great success thanks to that attitude and I am so glad I'm using the XBMC on my HTPC & ATV2.
Keep up the good work!
2011-04-22, 17:23
Well I want to Thank everyone who contributes...I use xbmc almost daily and couldnt imagine my theater without it.
2011-04-25, 18:54
Applied the patch. Looks like the issue is fixed. Great work!
2011-04-26, 20:49
ldi9999 Wrote:Applied the patch. Looks like the issue is fixed. Great work!
Thanks for your feedback.
2011-04-27, 03:44
Finally. My ATv is back to 4.2 speed and I have AirPlay. Now if they can just fix the passthrough!!
Thanks a ton!
Thanks a ton!
