Re: A2DP works, help me test it?
 

Hehe...I believe I ordered the exact same one as you did on eBay. About $28 with shipping from HK? :)

I should get mine at the end of the work or early next week and I will see how it works when paired with my BlueAnt X5i BT Stereo headphones. I really would like to see what these headphones are REALLY capable of. I'm getting sick of the HS/HF Profiles (although I can stand it when watching a movie on my N800, but music sucks)

Maybe by 2010 we will have full A2DP support for the IT's. :eek:

Re: A2DP works, help me test it?
 

Well, I did get mplayer building, so now I will start hacking on it a bit more... Increasing the alsa buffer size seems to have helped a lot with the skipping issues... IE, it no longer skips mplaying mp3s for me, as long as I be nice to it (no using the device, but that was the same in 2007). I am able to run top in another terminal without impacting playback, and it reports mplayer is using an average of about 55-60% CPU. Also, the output is a lot cleaner (much less resetting the audio device). Originally I was planning on increasing the buffer size manually in the code, but switching from CUNKSIZE based buffer size to BUFFERTIME based size, it took care of itself. Just a simple #define! :) The buffer size seems to cap at 25600, just slighting above the default value for a PC, so this is about the best gain we can get from this method. I guess I'll start investigating other options for further improvements...

-------

Here is the deb I'm using currently, with that fix. Tell me if you hear better performance as well!

http://cs.trinity.edu/~aharwell/mpla...l_bufftime.deb

Copy/paste-able instructions:
Also, they seem to play fine with libmad, so no real need to use ffmp3 AFAIK... which makes playing stuff as simple as That also means that with some slight modification of the mplayer config file, it should be possible to switch between normal audio and a2dp in Kagu by switching between osso and mplayer! :) I will test that shortly...

Edit 2: WOW. So, with the following ~/.mplayer/config
I can run Kagu and play a song, switch to mplayer output, and it *works* beautifully. I can even scroll through my albums and edit the playlist while it plays via a2dp, with no skipping (though it scrolls fairly slowly). I get one or two small "pops" per song, which don't appear to be related to CPU lag or alsa anything... I think it did the same thing in 2007, and it was just wireless interference.

Edit 3: I just tried playing video, because I was curious how badly it worked. They play perfectly even with a2dp audio! Please test this as well, if you can.
Note: For video playback, I have found it necessary to add
to my ~/.mplayer/config for correct A/V sync. That value will probably vary somewhere between 0-0.4 depending on other factors, like the video being played and possibly your specific hardware. Meaning, it may not be necessary at all for low quality video, but very high quality videos require something around 0.3. Setting the delay for each video individually is less than ideal, but considering this works at all, I am *not* about to complain! :P

Re: A2DP works, help me test it?
 

rm_you: Congratulations with the successful start hacking mplayer :)

Once you consider that your fixes are good enough for everyone to use, feel free to submit a patch and it will be included in the next build of mplayer.

Of course, an important requirement is not to introduce any regressions. Right now I don't quite like how ALSA behaves (playing sound using standard speakers). The sound is choppy and lots of the following messages show up in the console:
(Mis)interpreting these messages one can think that the buffer is too large :) It is interesting that tweaking/increasing buffer size helps with A2DP. Preferably, ALSA should work fine with both bluetooth headphones and the standard speaker. But as ALSA is unusable for standard speakers at the moment anyway, I don't mind tweaking and using it for bluetooth only first.

Re: A2DP works, help me test it?
 

Was that using my deb? Because I tested alsa playback using the standard audio device as well, and I never got anything like that. I'm testing it again right now, and there doesn't seem to be any skipping or messages of any kind. :( I wonder if there is something else going on at the same time on your system? top reports 6-8% CPU usage playing using alsa, so I don't know if that could even be it... :/

Edit: I took a closer look at what's going on... When I use -ao alsa:device=bluetooth it gets a buffersize of 25600, but when i just use -ao alsa for playing via speakers, it automagically gets a buffersize of 4096. I guess it would be good to know WHY. I'll look into it...

Re: A2DP works, help me test it?
 

I'm testing with: mplayer -ao alsa /home/user/MyDocs/.videos/Nokia_N810.avi

I did not use your .deb but tried the following patch (it should contain exactly your fix according to your description):
ALSA sound output works much better for sure when used to play audio only, but we need it to handle all the use cases properly.

Re: A2DP works, help me test it?
 

That is very odd... It chooses 4096 buffersize when using "-ao alsa" when it is playing both mp3 and video, but for some reason it works fine for mp3s and not for video. Since the buffer size is exactly the same for both, I would guess that is not the direct cause, but since the only change I made to cause that problem was to change the buffer size, the cause must at least be related. I will keep looking.

Re: A2DP works, help me test it?
 

I did not exactly say that your patch introduces a regression. ALSA does NOT work properly both with and without your patch for standard speakers when we try to play video. I had a hope that these problems might be related and could be resolved with a single fix.

Well, as I said earlier: "Preferably, ALSA should work fine with both bluetooth headphones and the standard speaker. But as ALSA is unusable for standard speakers at the moment anyway, I don't mind tweaking and using it for bluetooth only first." :)

Re: A2DP works, help me test it?
 

Ah, ok :) I just figured that out myself, and I was coming back here to post about it like "erm?" but I guess I just misunderstood. Well, that is a relief! :) I suppose since I am bored and working on ALSA stuff right now, I may as well look into that issue anyway.

Re: A2DP works, help me test it?
 

Can we expect this ALSA Bluetooth patch in the next Maemo Mplayer build?

Thanks

Re: A2DP works, help me test it?
 

Hi,
first of all thanks for trying to figure the N800 a2dp issue out, I think it's a needed feature and should not be postponed if it can be used to some extent.

Secondly, I'm new to all this hacking, but I got the a2dp working with a Sony HWS-BTA2W audio gateway. The sound still breaks up frequently like many others state. I'd like to try editing the ALSA buffer size. How can I do that?

Besides following this topic I also found this ALSA configuration guide on the Bluez Wiki


Would this part be related to buffer size?

"It is not necessary to create a virtual device as in alsa, configuration can be change via element properties:
a2dpsink

Element Properties:
name : The name of the object
flags: readable, writable
String. Default: null Current: "a2dpsink0"
preroll-queue-len : Number of buffers to queue during preroll
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0
sync : Sync on the clock
flags: readable, writable
Boolean. Default: true Current: true
max-lateness : Maximum number of nanoseconds that a buffer can be late before it is dropped (-1 unlimited)
flags: readable, writable
Integer64. Range: -1 - 9223372036854775807 Default: -1 Current: -1
qos : Generate Quality-of-Service events upstream
flags: readable, writable
Boolean. Default: false Current: false
device : Bluetooth remote device address
flags: readable, writable
String. Default: null Current: null "

Re: A2DP works, help me test it?
 

Yes, when rm_you decides on what patch should be applied to mplayer to get better A2DP support, it will be added to garage mplayer (I don't have a bluetooth headset to test it myself).

Re: A2DP works, help me test it?
 

I am waiting to hear from at least a couple more people on various different tablets to make sure "my patch" (the same thing you duplicated already in about 10 seconds, just a define/undefine) is effective in different scenarios / all tablets. I've been away for a few days, so I haven't found anything else yet, but I am still examining the code and experimenting.

Edit: I've done a lot of testing, and at this point it's fairly safe to say that the problem with alsa playback is not mplayer's fault. ALSA completely ignores any attempts to configure the default device using functions like "snd_pcm_hw_params_set_period_size_near", etc. My initial thought is that this is the result of a "feature" designed to keep the values inside certain hardware boundaries... If that is the case, possibly the boundaries are being detected wrong by ALSA? This is pure conjecture at the moment, but I will be checking out ALSA in the morning to see what I can find out.

Re: A2DP works, help me test it?
 

I did install the deb you posted on my 810 and a2dp playback seems a bit better. I can play to my headset using Kagu but still get a few skips/pauses in playback. Still also get skips when just playing through xterm/mplayer. But, seems better than the maemo 24 build.

Question for you RM. Why is your build twice the size of the Maemo build (5.x mb vs 2.x mb)? Is you build compiled in debug mode? If so perhaps a prod build may yield slightly better performance.
Thanks.

Re: A2DP works, help me test it?
 

Thanks for the effort guys. I tried all the tweaks and got the Sony HWS-BTA2W to work *somehow* with the N800 OS 2008. It still had dropouts every 2-15 seconds without any other processes running.

I consider this way too bad for actual use though, so I'm still going to take my Sony audio gateway back to the store.

I'll keep my eyes on this topic though, so please inform of progress with the ALSA buffer and/or possible bluetooth DSP use to take stress of the CPU. I don't know much about Linux, but working with PC audio studio systems I know that the problem sounds a lot like the the CPU not being able to flush such a short buffer or that the size of the buffer is unpredictable.

(Setup used:)

N800 running OS 2008 (RX-34_2008SE_2.2007.50-2_PR_COMBINED_MR0_ARM.bin)
Kagu
Mplayer
Bluez

Re: A2DP works, help me test it?
 

I can't seem to get bluez to install. I am using the application manager, and it just says "unable to install." Any help?

Re: A2DP works, help me test it?
 

I'm not quite sure what you're seeing?
mplayer_1.0rc1-maemo.24.n8x0_armel_original.deb 2344588
mplayer_1.0rc1-maemo.24.n8x0_armel_rm_you.deb 2342138
My deb appears to be 2450 bytes smaller than the original.

Another thought: It was mentioned at least once in this thread that redirecting the output of mplayer to a file increased the usability. Can you try doing that? Just do:
... or something like that.

Re: A2DP works, help me test it?
 

Paired with Motorola S9 here. Tablet connects as the handsfree before my MotoROKR Z6m Sellphone modem captures it. The Z6m simultaneously connects to the stereo headsets AD2P, which I couldn't believe. If something plays on the N800/OS2008, it plays in the left earphone they way the phone calls are supposed to come in. If I play an MP3 on the phone, the phone plays music in stereo through the headset.

This is not bad, just reversed! If I can get the phone to connect to the handsfree profile and the N800/OS2008 to connect to the stereo profile, when its in range and the phone MP3 stereo to pair when it's not or off, I will be one happy camper!

If you're looking for LOUD from a BT tablet headset, it's called MotoROKR S9 and Radio Shack, of all places, recently had them on sale for $79! If you turn up the tablet volume controls and the volume on the headset, in just one earphone so far, the sound is PAINFULLY LOUD!...(c;

Thank you Linux experts for all your help and wonderful software....
The key to making the Nokia BT keyboard to pair is NOT to RESTORE from OS2007!

Re: A2DP works, help me test it?
 

I dont have my N810 at the moment but I see you are correct regarding the deb sizes. I thought Applicaiton Manager reported 5.x mb for Mplayer. Also, I used the below msglevel to silence mplayer.

-msglevel all=-1

I assume this would yield the same results as redirecting to /dev/null.

Re: A2DP works, help me test it?
 

You're probably right in that you won't see output to the screen, but I can't say with 100% certainty that the same stuff is going on in the background. It's a longshot anyway, but if you have a minute next time you are with your tablet (you aren't ALWAYS? :P) then just give some sort of redirection a try. Admittedly, I wouldn't hope for much...

Re: A2DP works, help me test it?
 

As far as CPU utilization, I suspect it's due to cache misses. A pxa270 with identical size cache and association size 32 runs the encoding at about 4% of the cpu; however the 2420, with its 4 associations and similar speed needs around 50%. There is a section of code that moves memory around on every pass so we'll target that first.

There was interest from some people at the university that partners with INdT to put the codec on the dsp, but it was far from official.

Re: A2DP works, help me test it?
 

Could anyone test A2DP with oprofile and identify/confirm what exactly loads cpu so high? It is quite easy to setup oprofile in OS2008 by following the instructions from http://maemo.org/development/tools/doc/oprofile

Re: A2DP works, help me test it?
 

The code is written with inline functions all over the place so without making a debug build you'll just see a lot of utilization in sbc_encode iirc.

Re: A2DP works, help me test it?
 

Just benchmarked sbcenc from bluez-utils-3.24 on N800:
Considering that the duration of test.snd file was 226 seconds, estimated cpu load should be ~11% which is a lot lower than 50%. Maybe something else is eating cpu cycles (not sbc codec) or your sbc build was compiled with suboptimal gcc options?

Oprofile shows the following statistics (with '-fno-inline' compilation option added).
This sbc encoder contains a lot of 32x32->64 integer multiplications which are not very fast. Probably it would be better to use floating point sbc encoder on N8x0 (version from bluez-utils-2.25)? Right now it is twice slower:
Coincidentally, I did some experiments with ARM VFP optimizations just a few days ago, and the results are very promising: http://lists.mplayerhq.hu/pipermail/...ry/040250.html :)

Performance of vector_fmul function can become ~13x faster with assembly optimizations. And function 'sbc_analyze_eight' from sbc encoder contains a lot of very similar code which could also use VFP optimizations.

Re: A2DP works, help me test it?
 

It's great to see people who know what they're talking about working on this. I'm afraid that I waded in to this whole thing, then realized that I was out of my depth. :o At this point, to me at least, it looks like there is something strange about ALSA included with 2008OS. I guess my big question to solve before I give up and call it good enough is: Could a problem with buffers in the ALSA libs on the system be causing mplayer (or xmms) to waste lots of CPU time when outputting to A2DP?

Re: A2DP works, help me test it?
 

Or get them here for $38:

http://www.dealextreme.com/details.dx/sku.2354

Re: A2DP works, help me test it?
 

I just got my Sony DR-BT30Q headphones through from Play.com (only 12.99 ukp delivered) and after some initial problems creating the .asoundrc file, I got mplayer outputting choppy stereo audio, so I'm happy for the moment..

Re: A2DP works, help me test it?
 

OK, I've been hacking on this more. Don't think I've given up or something. I have madplay and aplay compiled and I've been testing them. Piping from madplay to aplay uses about 50% CPU. aplay playing a .wav takes up 20%-30% and no matter what aplay (which claims to set the period size) still can't change the period size from 128. :mad: I'm going to try something else to track this down. Stay tuned...

Re: A2DP works, help me test it?
 

Appreciate your work on this, I'm a noob as far as the N800 goes (and Linux in general) but I'll help with testing in any way I can. I have the Kyocera wireless headphones. Looking forward to the one-click install package.

Thanks again!

Re: A2DP works, help me test it?
 

Yeah, I think we would all love a .deb. (I'm not really lazy, I'm just a little ignorant in the ways of programming/Linux in general) I know, I should try and learn something...

Re: A2DP works, help me test it?
 

I've resisted doing a .deb until the situation is a little better, but looking at things now that might take a while. I'll consider doing a beta .deb soon with the understanding that it is *VERY BETA*.

-John

Re: A2DP works, help me test it?
 

Was that using the default Mplayer in the repository, or was that from the .deb i linked in one of my previous posts? I really thought the deb I posted had fixed the choppiness, for the most part...

Re: A2DP works, help me test it?
 

That was with the default mplayer, I have since installed your .deb and tested with Kagu, it's better than before, but still not ideal..
Trouble is, I just don't like Kagu.. I shouldn't be so fussy...
I'll try it some more and let you know how I get on.

Re: A2DP works, help me test it?
 

I updated the first post with info on the .deb I've put together to somewhat automate the A2DP install process. Feedback welcome. Please remember to follow instructions carefully!. Big thanks to rm_you for the modified mplayer that makes this *actually work.* Thanks also to Serge and Ed_ for mplayer on the N8x0 devices. And of course thanks to anyone above who gave feedback. I appreciate it!

-John

Re: A2DP works, help me test it?
 

Thanks, keep up the good work hopefully there will be further improvements as time goes by

Re: A2DP works, help me test it?
 

I don't know if anyone has noticed this, but I saw near-flawless playback for ~5 seconds until the device sat unused for a bit and then it would break up predictably, coming in and out of breakups (this is using a WiREVO S300 and the unpatched version of mplayer). I was reading the maemo devs list and there was some discussion on clocks and overclocking which got me thinking since they posted a way to check the current clock speed (cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq). I saw a very interesting thing happening when playing back music with kagu/mplayer: the clock speed would stick at 400 MHz for the first unbroken part of the playback and then begin oscillating from 330, 266, and lower clock speeds, at which point the breakups would occur.
It appears that user activity such as touching the screen or using the dpad will force the clock to 400 MHz and then it will start using lower clock frequencies once the device has a while to "calm down". It makes sense and apparently A2DP decoding has a small enough tolerance to lower speeds to prevent it from working at anything but 400 MHz when the buffer is too small. As long as I tapped the screen to scroll up and down within kagu every 3 seconds or so it would stay at 400 MHz and breakups were much, much fewer. There currently is no way besides a kernel patch to lock the clock speed at a particular value (Although playing something through the speakers will force it to a particular clock speed to avoid breakups, ironically). I believe we could get very solid playback if we could just avoid the lowest clock speed (165 MHz) and use the patched version of mplayer. The breakups for the patched version usually occurred around a period of time where the clock was at 165 MHz more than a few seconds.

Just a FYI-
Larry

Re: A2DP works, help me test it?
 

ok gang i just tried kagu and mplayer using a2dp with the oss player running in the background and a2dp plays almost perfectly. if we can keep the cpu clock up this will achieve smooth play. ideas?

Re: A2DP works, help me test it?
 

I can't see this being a kernel space thing so there must be a app somewhere determining what speed the kernal should run at.

Re: A2DP works, help me test it?
 

It looks like it uses cpufreq. To lock it at max speed just do this as root:
To get the current setup back just do:
I was sure that Nokia would have made it more difficult. :) That being said I had a chance to take a nice long walk today and with nothing else running but kagu, I had no skipping whatsoever. Are people seeing skipping with rm_you's mplayer when not doing anything else?

-John

Re: A2DP works, help me test it?
 

Yes, I still see skipping with the patched deb. It is better than the main x24 deb. I will try the performance setting tonight.
Thanks.

Re: A2DP works, help me test it?
 

followed portions of this thread and here is where I am at. I paired no problem with my N800 (OS2008) using my Kyocera bluetooth headphones. The issue I have is that sound quality is complete crap. On my Blackjack 2 the headphones sound great! On the N800 it sounds like I'm listening to them through a 6ft length of PVC pipe...all muffled and very low volume...any clues?