XBMC on Boxeebox
#1
Hello,

I thought you might be interested to know that I'm working on this at http://github.com/quarnster/boxeebox-xbmc

Teaser: https://docs.google.com/file/d/0B_M2ovmb...sp=sharing
#2
Nice!
#3
Is the video hardware acceleration working as well?
#4
No video or audio hw-accel yet, just got the ui (via EGL/GLESv2) up and running this morning Smile

HW acceleration for Audio and Video is next on my list.
#5
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 ?
#6
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.
#7
If this is not a joke.. this is seriously wonderful! I really hope that you succeed.
#8
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
#9
you will likely find that you have to rewrite the audio driver substantially. audiorenderers is dead, long live ae sinks..
#10
If you need help in testing - just say it Smile
#11
Quarnster, is it frodo 12.2 or gotham you're using? And do you have any plans to create an official pull request?
#12
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.
#13
I'm having this odd pattern with audio where it's like it's playing for 1 second then there's silence for 1 second and then this repeats. It still exists if I disable all modifications save for the custom AESink. If I launch up the music player, the addons/visualization.glspectrum/opengl_spectrum.vis visualization is spinning at a constant framerate without hickups, but the bar heights follow the same pattern as the audio where they change height for 1 second and then are still for one second.

Any idea what might be wrong?

I've tried various buffer sizes and keeping the pipe both ~full and ~half full, but the result is still the same.

If you want to have a peek at the sink code, it's hardcoded for AE_FMT_S16LE stereo at 48000hz for now and located in:
https://github.com/quarnster/boxeebox-xb...telSMD.cpp
https://github.com/quarnster/boxeebox-xb...IntelSMD.h
#14
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.

Image

"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#."
#15
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?

Logout Mark Read Team Forum Stats Members Help
XBMC on Boxeebox1