opening discussion

[mk01]

@belese

so we can create alsa "only" package (not depending on pulse) providing function of BT Speakers and/or using remote BT speakers for sound output?

[belese]

yes that's it,
but i didn't test and implement(in upstart and package) the bt speakers for sound output.
but this code should handle it according to the author.

Also sound quality is not optimal (but same as with pulseaudio), it's due that bluez only implement sbc codec, and not aptx (closed source).

package (xbian-package-a2dp) use aplay to output sound to alsa,
this pgm send raw data on stdout,

xbmc can't read raw sound audio,
and i don't see advantage to read audio in xbmc player,
but in case thay are some, maybe it's possible to write it in a fifofile, and fly convert to wav.
but this will surely adding some latence. So aplay seems a good solution(few latence (less than pulseaudio), but probably too much for video and this is also due to sbc codec).

Later i can implement,

stop xbmc player when pairing
start tv/amp when pairing

and ,
i should review upstart script,
some logic are for my first attempt, and are not necessary here, they should probably be simplified,
here's a way in upstart to know when bluetooth has beens started? as it use init.d script to start?
i didn't find a clean solution,
or write upstart script for bluetooth, but it's a raspian package so for this, imagine we have to do a custom package for bluetooth-upstart instead of using raspian one?
this can be used combined with udev to start bluetooth only when dongle is plugged

Now i use a "workaround", just wait 15 sec before starting pairing agent.

[mk01]

@belese

if you are fine I will update the upstart staff (I had it almost done, just didn't finish because of the previous pulse issue with xbmc)

and it is as you say, quite elegant. give me today to finish it.

[mk01]

@belese

i corrected the access rights. just push what you have and I take over then to prevent git conflict.

[belese]

i'm fine for upstart! you know better than me.

maybe you can revert the push request i've done if needed
but on git now is my last development state. so nothing amazing :-)

[mk01]

@belese

not "better" - but why to make a double work.

[jochenrill]

Hi,
I tried this on cubox-i and it works great. The only "problem" is, that the service has to be stopped before trying to play anything on XBMC, since otherwise aplay will block the audio device (HDMI in my case) and XBMC will crash.
I tried to play the stream using the XBMC player to avoid the issue. For that I tried to convert the received bluetooth audio to wave on the fly. However, if the audio is first put into a FIFO and converted to wave from there, it will no longer be "live", since at the time I open the file from XBMC the song will already have played for a while (also a large file will be generated on the local file system).
Trying to do it the otherway around (piping the audio stream into avconvert for example and from there into a FIFO) does not work, since the audio header will be lost after a short while (pushed out of the FIFO) and XBMC will not recognize the file anymore.

Since you guys have already spend some time with this, do you have any good ideas how to play the stream directly through XBMC while maintaining its "live" character?

Thanks.

[belese]

Hi about playing in xbmc without latence,it probably need to be in xbmc code. I check a bit how airplay was implemented and probably follow the same way. Problem is i can read more or less c code but write it it's another think. One easy solution for this case is to stop the service a2dp when xbmc player start. But i've no cubox and since pi use omx player,i don't have this problem.

And what device did you use?it work quite well with my samsung s3 mini. But with a friend's mac or htc,sound is buggy. But i've now my devel and test machine nearly ready,i'll check log to see what happen but i suspect missing frame.

[jochenrill]

I already tried to stop the a2dp service on start of the xbmc player, however, by the time XBMC emits the signal for "player start" it is already to late. It seems that the allocation of the audio device happens before the player gets started.

It seems that the only good solution is to integrate it into XBMC directly.

I tried it on the S3 and the Xperia Z2 - both work well. However, I did not test it for a very log time.

[belese]

ok, you've already test a lot :-)

if it's integrate to xbmc, it will be probably a xbian patch for xbmc, but not a one that can be merge on main branch, as it should be multiplatform, and proper :-), and it's over my capabilities in C.

[belese]

i've just find this,
https://github.com/liamw9534/bt-manager
it looks quite complete and more felxible,
will take a look later.

and problem for the pi, is codec decode is cpu hungry for some kind of format