Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 1 day ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 1 day, 20 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 4 hrs ago - more...
 |
|
2008-01-02
, 00:58
|
|
Posts: 98 |
Thanked: 189 times |
Joined on Jul 2007
@ San Antonio, TX
|
#42
|
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
Last edited by rm_you; 2008-01-02 at 16:38.
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
Code:
mplayer -ao alsa:device=bluetooth my.mp3
I will test that shortly...Edit 2: WOW. So, with the following ~/.mplayer/config
Code:
ao=alsa:device=bluetooth
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
Last edited by rm_you; 2008-01-02 at 16:38.
| The Following 6 Users Say Thank You to rm_you For This Useful Post: | ||
|
|
2008-01-02
, 13:56
|
|
Posts: 503 |
Thanked: 267 times |
Joined on Jul 2006
@ Helsinki
|
#43
|
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.
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)
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.
|
|
2008-01-02
, 16:24
|
|
Posts: 98 |
Thanked: 189 times |
Joined on Jul 2007
@ San Antonio, TX
|
#44
|
Originally Posted by Serge
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.
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)
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...
Last edited by rm_you; 2008-01-02 at 16:35.
|
|
2008-01-02
, 16:59
|
|
Posts: 503 |
Thanked: 267 times |
Joined on Jul 2006
@ Helsinki
|
#45
|
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.
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, ...)
|
|
2008-01-02
, 18:07
|
|
Posts: 98 |
Thanked: 189 times |
Joined on Jul 2007
@ San Antonio, TX
|
#46
|
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.
Last edited by rm_you; 2008-01-02 at 18:28.
Last edited by rm_you; 2008-01-02 at 18:28.
|
|
2008-01-02
, 18:24
|
|
Posts: 503 |
Thanked: 267 times |
Joined on Jul 2006
@ Helsinki
|
#47
|
Originally Posted by rm_you
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.
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.
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."
|
|
2008-01-02
, 18:29
|
|
Posts: 98 |
Thanked: 189 times |
Joined on Jul 2007
@ San Antonio, TX
|
#48
|
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.
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.
|
|
2008-01-03
, 15:34
|
|
Posts: 19 |
Thanked: 11 times |
Joined on Dec 2007
|
#49
|
Can we expect this ALSA Bluetooth patch in the next Maemo Mplayer build?
Thanks
Thanks
|
|
2008-01-05
, 00:05
|
|
Posts: 12 |
Thanked: 0 times |
Joined on Jan 2008
@ Helsinki
|
#50
|
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 "
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 "
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.