Posts: 31,445
Joined: Jan 2011
Posts: 703
Joined: May 2009
Reputation:
2
erhnam
Team-XBMC Live Developer
Posts: 703
Is the video hardware acceleration working as well?
Posts: 1,245
Joined: Oct 2009
Reputation:
28
Jönke
Posting Freak
Posts: 1,245
Nice ! I dont have a Boxee box but it is only 108 $ in Sweden right now. So do you really think you can get up and running with xbmc 100% if you manage to add hw accel ?
Posts: 16
Joined: Aug 2013
Reputation:
2
I haven't really used XBMC besides for the modified version installed on the boxee box, so I don't know exactly what running 100% of XBMC entails. Point being that we're at the mercy of what the hardware is capable of when it comes to the feature set possible to enable.
The best known hack we have today for the boxee box enables us to hijack the init process before the boxee app is launched, so launching XBMC instead of the boxee app is indeed possible and I intend to make a binary distribution with install scripts to make the installation process as easy as possible once I get the hw accel fully working.
Posts: 6
Joined: Oct 2012
Reputation:
0
If this is not a joke.. this is seriously wonderful! I really hope that you succeed.
Posts: 478
Joined: Jun 2008
Reputation:
0
well done mate, im very certain there will be a lot of upset boxee owners about that would love the great work you are doing atm.
Dam0
Posts: 12,706
Joined: Nov 2003
Reputation:
129
spiff
Team-Kodi Member
Posts: 12,706
you will likely find that you have to rewrite the audio driver substantially. audiorenderers is dead, long live ae sinks..
Posts: 703
Joined: May 2009
Reputation:
2
erhnam
Team-XBMC Live Developer
Posts: 703
Quarnster, is it frodo 12.2 or gotham you're using? And do you have any plans to create an official pull request?
Posts: 16
Joined: Aug 2013
Reputation:
2
12.2, but once I've gotten that to work I absolutely intend to sync up to the latest development version, clean up the code and iterate as needed to get the code into the official repo.
Posts: 4,549
Joined: Dec 2007
Reputation:
17
topfs2
Team-Kodi Developer
Posts: 4,549
Awesome work!
Looking at the code I just have a few guesses
1 its not because you enable audio input? Not sure why it would cause it but that was something I stumbled on reading the code. L216.
2 Your GetDelay function is wrong afaict, which should make dvdplayer get iffy. It should, afaik, return the time it would take for a sample to be played that I add _now_, so its the time of whats left in the sink and how long that takes to play
3 You seem to be using chunksize the same as buffer length, i.e. there is only ever one chunk in the buffer. If SMD behaves as pulse audio, and this is low enough, it will cause the sink to underrun, thus pausing. What you need to do is have a buffer in the sink which is X times larger than the chunk size. And that the buffer size is larger than the minimum (underrun protection) of what the sink needs.
Hope this helps you in any way.
Cheers,
Tobias
If you have problems please read
this before posting
Always read the
XBMC online-manual,
FAQ and
search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the
forum rules.
For troubleshooting and bug reporting please make sure you
read this first.
"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Posts: 16
Joined: Aug 2013
Reputation:
2
Cheers Tobias.
1. Input in this instance is not audio capture, but rather just an input port to which you can write your audio data for playback.
2. Unfortunately this made no difference to the pattern.
3. Yes, there's a big mixture of terminology between the SMD api, XBMC and, I'm guessing, the previous "SMD AudioRenderer" being ported over from the DirectSound renderer due to having the exact same names m_dwChunkSize and m_dwBufferLen that is seen in the DirectSound sink.
The SMD component doesn't have a chunk concept AFAIK, just buffers which you queue up with the max queue length of 16 buffers to process before it starts blocking. A debug printf to query the queue status and whether we are blocking waiting to allocate a buffer or to add that buffer into the queue reveals that the current queue length is between 13 and 16 buffers to process, and having to block for a bit every third call or so.
If the chunksize and buffersize was different in the previous Boxee "AudioRenderer" code, it would just still allocate an SMD buffer of buffersize, but only fill it with chunksize bytes of data, presumably to achieve closer to realtime feedback for ui navigation sounds.
But anyway, if we think of the smd buffer size as the chunk size, and the queue length as the buffer size we have in theory 16x underrun protection due to the queue being 16 "chunks" long, no?
There still are "CSoftAEStream::GetFrame - Underrun" messages in the log though.
Any other ideas to try?