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...

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.

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

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

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

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?

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.

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

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.

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?