[bole5]

@bole5 -> git 52e7dc99a7cbd507a5f751364c25b0ad0ecc5bb0

Your changes brought in to trunk, I also switched to mutex usage.

Using CSliceQueue would be best as it is lockless and does not require mutex or critical-sections.

External libraries can be thread-safe or not. depends. av_fifo was used as it is very fast.

git e4f365fa60b5a80c8cd62c7886fc9208e78b0238 is also interesting

Thank you davilla for bringing the changes into trunk so quickly.

Regarding the locks and the tread-safety, I've worked on a (hopefully) better solution that can be used as a replacement for av_fifo buffer. I called it IOSAudioRingBuffer. It implements the "Read/Write Counts" Circular Buffer (http://en.wikipedia.org/wiki/Circular_bu...ite_Counts). This buffer is very robust and safe to use in multithreaded environments without requiring any locks, and should bring improvements in stability and enable easier debugging of audio problems.

The full diff can be found on pastebin: http://pastebin.com/xZxyv626.

For the brave people out there who would like to test if this audio fix helps address their problems with stability and rebooting when doing a lot of FFWD/RWD you can 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 file from: http://www.megaupload.com/?d=5PIEOLQC
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

[dtviewer]

I tried the build bole5 just posted above and still have the ff/rew problem, though not nearly as bad as it was.

Before it would only take a couple jumps forward to cause the issue, now it seems to take many presses.
As others have posted, when this happens the video slows way down and sound disappears.

Im sure you can replicate the issue but if you need me to post logs let me know and I will.

BTW, i am running 4.2.1.

[popcornmix]

Still same issues for me. A few seeks and the video plays at 3.9fps.

Log

This log did exit okay. The first time I tried, exiting caused a reboot.

[dazex]

bole5:
In case you want to look into the issue further. This is the exact commit that fix the audio downsampling but introduced the ff/rew slowdown problem as a side-effect:

https://github.com/xbmc/atv2/commit/6ba8...e06da278ee

My build prior to that day's commit does not exhibit the slow down problem no matter how much I ff/rew. I tested it pretty extensively at the time.

The builds following those commit has issues. Though the issue have been mitigated somewhat with recent nightly builds.

Now, I just await the coreaudio fix that will eventually come and hope for the best.

[bole5]

I tried the build bole5 just posted above and still have the ff/rew problem, though not nearly as bad as it was.

Before it would only take a couple jumps forward to cause the issue, now it seems to take many presses.
As others have posted, when this happens the video slows way down and sound disappears.

If I make the IOSAudioRingBuffer log more (by uncommenting all CLog entries in Read() and Write() methods) it is obvious what exactly happens:

• When you press ff/rew really quickly (like double-clicking the mouse) the sound device will eventually stop/die
  
• This results in no more data being picked up from the IOSAudioRingBuffer by OnRender() method, while the data would still be written by AddPackets()
  
• This results in buffer being full
  
• When the buffer is full we start refusing new data in AddPackets(), which causes the video to slow down/stop
  

Now to the freezing problem: After the above sequence happens, if we wait too long and don't stop the video 10-15 seconds after the slow down, the ATV2 will freeze/reboot when we try to stop the video, which could indicate that there is a bug/memory leak somewhere in the video player framework...

The only "fix" for this is to exit the video quickly and get back to it again, which restarts the audio device.

We could eventually add a check to AddPackets() and try to restart the audio device when the buffer is full and the audio device is down. Davilla would be the most competent person to say if that could be done without creating other problems...

[popcornmix]

I agree with dazex. The last official build is rock solid with seeking.
I can double-click, triple-click, quadruple-click and all behaves perfectly.

I tested every daily build, and commented at the time that the gimli commit to support 2.0 audio introduced this problem. It has been present in every build since that point.

[dtviewer]

bole5:
In case you want to look into the issue further. This is the exact commit that fix the audio downsampling but introduced the ff/rew slowdown problem as a side-effect:

https://github.com/xbmc/atv2/commit/6ba8...e06da278ee

My build prior to that day's commit does not exhibit the slow down problem no matter how much I ff/rew. I tested it pretty extensively at the time.

The builds following those commit has issues. Though the issue have been mitigated somewhat with recent nightly builds.

Now, I just await the coreaudio fix that will eventually come and hope for the best.

I can attest to this also.

I had no issue with fast forward or rewind then either.

[bole5]

I can attest to this also.
I had no issue with fast forward or rewind then either.

bole5:
In case you want to look into the issue further. This is the exact commit that fix the audio downsampling but introduced the ff/rew slowdown problem as a side-effect...

I agree with you that the problem with FF/RWD started after the audio downsampling fix. The code of the IOSAudioRenderer evolved significantly after that fix, and overall stability was improved up to the point where the most users are happy.

With my latest patch I just wanted to improve the stability by removing the locks and the external buffer, which should help us debug the problem easier. I hope you can notice the improvement and are experiencing less freezes with my binary.

There is no point of spending too much time on fixing it much further as we are expecting the new Audio Engine to solve all our problems.
Thanks for testing/sharing your experience.

[dtviewer]

With my latest patch I just wanted to improve the stability by removing the locks and the external buffer, which should help us debug the problem easier. I hope you can notice the improvement and are experiencing less freezes with my binary..

Definately improved and thanks for the effort.

[bole5]

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

[i5Js]

I've just compiled the source code... have I do this too?

[dtviewer]

bole5....you are a genius!

Seems to work perfectly with multiple files I have tried so far, even files that did not work correctly with the last attempt!

Thank you!

[ldi9999]

Great. I experienced the same issue before. Will patch it tonight. Thanks!

[bole5]

I've just compiled the source code... have I do this too?

I am guessing you are asking how to apply the patch. Well if you don't have experience with that I would first try the binary, but if you want to patch yourself...

1. Copy the contents of the text I posted on http://pastebin.com/sTNUZHty to a new file called ios-audio.ring-buffer-2.patch
   
2. Go to the location where you cloned the git repository. It is most probably: $cd ~/xbmc
   
3. Run following command from that path: $patch -p1 < ios-audio.ring-buffer-2.patch
   
4. Rebuild your project
   

If it doesn't work for you, please use google and try to learn how to use patch command.

[ldi9999]

I am guessing you are asking how to apply the patch. Well if you don't have experience with that I would first try the binary, but if you want to patch yourself...

1. Copy the contents of the text I posted on http://pastebin.com/sTNUZHty to a new file called ios-audio.ring-buffer-2.patch
   
2. Go to the location where you cloned the git repository. It is most probably: $cd ~/xbmc
   
3. Run following command from that path: $patch -p1 < ios-audio.ring-buffer-2.patch
   
4. Rebuild your project
   

If it doesn't work for you, please use google and try to learn how to use patch command.

I don't think he meant to ask for how to compile. He was most likely asking if he needs to compile.