Active Topics

 


Reply
Thread Tools
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#151
Originally Posted by lbattraw View Post
I specifically avoided libdbus-1-2_0.61-osso13fix3, plugz-svn_20070608-1, and sbc-svn_20070608-1.

Thanks-
Larry
Those were never needed anyway, those files are for the older a2dpd which works worse than the current implementation anyway.
 

The Following User Says Thank You to qwerty12 For This Useful Post:
Posts: 209 | Thanked: 8 times | Joined on Nov 2005 @ Fishers, Indiana
#152
Originally Posted by qwerty12 View Post
Those were never needed anyway, those files are for the older a2dpd which works worse than the current implementation anyway.
Thanks for the info! There seems to be quite a bit of partial, inaccurate, or outdated information floating around. Incidentally I found out that it wasn't a problem with Kagu at all; apparently the DSP implementation doesn't appreciate low bit rates. The problem MP3s were at 64K bit (podcasts) and everything else seems to work great. Off to the garage page to report the bug...

Larry
 
Posts: 207 | Thanked: 31 times | Joined on Apr 2008
#153
Originally Posted by qwerty12 View Post
Meh, forget kernel, all the easy and more worthwhile stuff is done by dbus. Go on bitsmithy.net.

Looking at my headset-control may be useful too.
Thank's. Work fine. Only one problem: doesn't work when screen is locked.
 
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#154
Originally Posted by svs57 View Post
Thank's. Work fine. Only one problem: doesn't work when screen is locked.
Yeah , I saw that one too. I wonder if there is a remote control program for mplayer that doesn't rely on keypresses (in headset-control, I make it use dbus-send which is much more reliable than xte/keypresses and works when locked)
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#155
apparently the DSP implementation doesn't appreciate low bit rates. The problem MP3s were at 64K bit (podcasts) and everything else seems to work great. Off to the garage page to report the bug...
Please do report it. Does the software sbc encoder handle these files? There should be no difference between the two (DSP & ARM sw).
 
Benson's Avatar
Posts: 4,930 | Thanked: 2,272 times | Joined on Oct 2007
#156
I'd think sampling frequencies are more likely the trouble than bitrates... from what I understand, the MP3 gets decoded to PCM, and that gets SBC encoded, so there shouldn't be much possibility for interactions there. (Especially not implementation-specific interactions...)

@qwerty12:

Well, I ordered some A2DP, so I should be able to try this at some point... but not having tried it, I'll make a recommendation. Don't use mplayer for this, use mpd. (I know, that's my recommendation for everything, but I really mean it this time. ) Since mpd uses libao for output, you should be able to point it at the A2DP, and it's designed for remote control...

Also, if sample-rates are being a trouble, I know how to set up mpd to do its own rate conversion, thus working around that trouble for the moment. Not saying you can't do that with mplayer, but I don't know how.

But if you insist on mplayer... try slave mode? (And a FIFO, of course...) Then you can have some dumb front-end giving you whatever limited control you feel like hacking together, and have the headset dbus listener dump commands in the same FIFO; there's a race condition, naturally, but they shouldn't collide unless you try issuing commands at the same time with the UI and the buttons (and are lucky and/or exceeding good at synchronous manual button-presses).
 

The Following User Says Thank You to Benson For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#157
Originally Posted by Benson View Post
@qwerty12:

Well, I ordered some A2DP, so I should be able to try this at some point... but not having tried it, I'll make a recommendation. Don't use mplayer for this, use mpd. (I know, that's my recommendation for everything, but I really mean it this time. ) Since mpd uses libao for output, you should be able to point it at the A2DP, and it's designed for remote control...
Tried that and it would connect for a second and disconnect, and the error log was fun to look at :/

But mpd isn't my forte anyway
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#158
I'd think sampling frequencies are more likely the trouble than bitrates... from what I understand, the MP3 gets decoded to PCM, and that gets SBC encoded, so there shouldn't be much possibility for interactions there. (Especially not implementation-specific interactions...)
I think the sbc output sample rate is currently fixed by the Bluez code, it would make more sense to use the same sample rate as the input stream if possible. Something to look at anyway.
 
Posts: 209 | Thanked: 8 times | Joined on Nov 2005 @ Fishers, Indiana
#159
Originally Posted by lardman View Post
Please do report it. Does the software sbc encoder handle these files? There should be no difference between the two (DSP & ARM sw).
Silly question, but is using the software encoder instead of the DSP encode just a matter of changing the .mplayer/config file so it reads
afm=libmad instead of
afm=dspmp3 ?

If so, then yes, both implementations sound identical. I can still file a bug, I just need to confirm I'm testing the right things.

Larry
 
Benson's Avatar
Posts: 4,930 | Thanked: 2,272 times | Joined on Oct 2007
#160
No, that's changing the MP3 decoder, not the SBC encoder...

Not quite sure how to switch it easily (as I don't have it yet), but if you uninstall lardman's dsp-sbc package, that should do it (in classic bludgeon style).
 
Reply


 
Forum Jump


All times are GMT. The time now is 16:30.