maemo.org - Talk - A2DP works, help me test it?

maemo.org - Talk (https://talk.maemo.org/index.php)

- OS2008 / Maemo 4 / Chinook - Diablo (https://talk.maemo.org/forumdisplay.php?f=29)

- - A2DP works, help me test it? (https://talk.maemo.org/showthread.php?t=13468)

Re: A2DP works, help me test it?

Quote:

Originally Posted by ascherjim (Post 118617)

As a follow-up to my above-quoted posting, I have received my miniature mp3 A2dp dongle, and it works perfectly on all my mp3 players (especially including the N800). None of the initial start-up static I'd previously encountered using Milhouse's ingenious hack with Kagu. This dongle, which only cost about $20 plus shipping, and is available all over eBay, plugs right into the audio jack and is quite inconspicuous. Until we get an integrated a2dp facility again for the N800 -- and even possibly beyond -- this dongle will get much use. The only limitation to its use is that you must have Bluetooth headphones that pair with the "0000" code -- as my Motorola does.

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:

Code:

wget http://cs.trinity.edu/~aharwell/mplayer_1.0rc1-maemo.24.n8x0_armel_bufftime.deb

apt-get remove mplayer

apt-get install libmad0 libogg0 libtheora0

dpkg -i mplayer_1.0rc1-maemo.24.n8x0_armel_bufftime.deb

Also, they seem to play fine with libmad, so no real need to use ffmp3 AFAIK... which makes playing stuff as simple as

Code:

mplayer -ao alsa:device=bluetooth my.mp3

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

Code:

ao=alsa:device=bluetooth

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

Code:

delay=0.2

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:

Code:

alsa_dsp_transfer(): Requested too much data transfer (playing only 2048)

(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?

Quote:

Originally Posted by Serge (Post 119275)

The sound is choppy and lots of the following messages show up in the console:

Code:

alsa_dsp_transfer(): Requested too much data transfer (playing only 2048)

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):

Code:

Index: libao2/ao_alsa.c

===================================================================

--- libao2/ao_alsa.c        (revision 303)

+++ libao2/ao_alsa.c        (working copy)

@@ -70,8 +70,8 @@



 #define ALSA_DEVICE_SIZE 256



-#undef BUFFERTIME

-#define SET_CHUNKSIZE

+#define BUFFERTIME

+#undef SET_CHUNKSIZE



 static void alsa_error_handler(const char *file, int line, const char *function,

                                int err, const char *format, ...)

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?

Quote:

Originally Posted by rm_you (Post 119408)

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 "