Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

omx audio_decoder hangs on EmptyThisBuffer() in kernel when 2 omx audio_render used #134

Closed
stupid-boy opened this issue Jan 9, 2013 · 7 comments

Comments

@stupid-boy
Copy link

more info in this thread:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=31&t=27908

@popcornmix
Copy link
Contributor

Can you provide a simple test app that causes the hang?
It may be easier to debug using something based on hello_audio, or command line omxplayer.

@stupid-boy
Copy link
Author

no, just XBMC code, currently flooded with logs.
week ago i have free time and was able to work n this/extract code/produce 'simple' app, now i am back to work.

@stupid-boy
Copy link
Author

Bellow are stack traces of 2 of threads when EmptyThisBuffer() hangs. Remaining threads are not related to libopenmaxil.so. Hope this will help any way. If i can collect some more info, please tell me.

Thread 20 (Thread 0xab90c440 (LWP 2669)):
#0 0xb6473700 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1 0xb6fc1ae0 in ilcs_execute_function_ex () from /opt/vc/lib/libopenmaxil.so
#2 0xb6fc2588 in ilcs_pass_buffer () from /opt/vc/lib/libopenmaxil.so
#3 0x00678478 in COMXCoreComponent::EmptyThisBuffer (this=0xac416170, omx_buffer=0x17811e0) at OMXCore.cpp:448
#4 0x012648d4 in COMXAudio::AddPackets (this=0xac413a70, data=0xab90d010, len=24576, dts=32000, pts=32000) at OMXAudio.cpp:1062
#5 0x0126e574 in OMXPlayerAudio::Decode (this=0xac4136e0, pkt=0x1b0b658, bDropPacket=false) at OMXPlayerAudio.cpp:392
#6 0x0126ec2c in OMXPlayerAudio::Process (this=0xac4136e0) at OMXPlayerAudio.cpp:505
#7 0x0127cd24 in CThread::Action (this=0xac4136e0) at Thread.cpp:218
#8 0x0127c91c in CThread::staticThread (data=0xac4136e0) at Thread.cpp:128
#9 0xb646cbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#10 0xb4a33758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#11 0xb4a33758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 19 (Thread 0xac1c8440 (LWP 2668)):
#0 0xb6473700 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1 0xb6fc1ae0 in ilcs_execute_function_ex () from /opt/vc/lib/libopenmaxil.so
#2 0xb6fc2320 in ilcs_execute_function () from /opt/vc/lib/libopenmaxil.so
#3 0xb6fc299c in vcil_out_get () from /opt/vc/lib/libopenmaxil.so
#4 0x0f442e80 in ?? ()
#5 0x0f442e80 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

EDIT:
I pushed my XBMC code. Can be found here: https://github.com/stupid-boy/xbmc/commits/RPI_both_audio

@tthef
Copy link

tthef commented Jan 20, 2013

I suspect this might be the same/similar problem as this gst-omx issue, http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=19606 (that discussion has a reference to an earlier firmware that is supposed to work, but unfortunately, the commit hash no longer exists in the repo).

@stupid-boy
Copy link
Author

fixed at commit from Feb 07.
thanks a lot!

@popcornmix
Copy link
Contributor

Yes, apologies for this not working. Using hdmi and analogue together is quite rare, so I hadn't realised the GPU was one DMA channel short.
I found it with an aplay to analogue, and an omxplayer to hdmi, but I thought it might fix your issue.

@stupid-boy
Copy link
Author

no problem.
everything is fine when it finish fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants