Bluetooth headset status?


Ok I will try that, but then i´ll have to set the Bluetooth audio as default? There is no way to switch between the outputs in gmu, as far as I know?
 
One thing I could imagine would be missing support for certain sample rates on the BT audio device, so some applications will fail because they are unable to open the device with their desired sample rate. If that is the case, it should be possible to fix that by setting up an ALSA dmix configuration with a resampler in front of the device and then configuring the dmix device to be the default.

I could see this being it. I just got Audacious running with my BT Audio setup, but had to set the bit depth to 16 in order to not get ALSA errors.
 
kay, found the -mmmx flag in the makefile. never mind.

libSDL_gfx.so was there, but no libSDL_gfx.so.0 -> a softlink did the trick. i didn't pay attention to the pndrun.out.
now gmu starts fine. but it seems to ignore my bluetooth setup. it uses the internal speakers instead.
Socket is enabled in /etc/bluetooth/audio.conf.
[doublepost=1458573018,1458571686][/doublepost]
but had to set the bit depth to 16 in order to not get ALSA errors.
how did you do that?
 
Ok I will try that, but then i´ll have to set the Bluetooth audio as default? There is no way to switch between the outputs in gmu, as far as I know?
Yes, using the default device is the easiest way to do that. Instead you could also explicitly tell SDL (which Gmu uses for audio output) to use a specific device through environment variables, e.g. SDL_AUDIODRIVER="alsa" AUDIODEV="hw:1,0" (for BT audio it is not hw:1,0 of course but whatever name your bt audio device has).

kay, found the -mmmx flag in the makefile. never mind.

libSDL_gfx.so was there, but no libSDL_gfx.so.0 -> a softlink did the trick. i didn't pay attention to the pndrun.out.
now gmu starts fine. but it seems to ignore my bluetooth setup. it uses the internal speakers instead.
Socket is enabled in /etc/bluetooth/audio.conf.

If the device is ignored although it has been defined as default, Gmu is possibly unable to read the ~/.asoundrc config file (assuming you put your configuration there), so it does not know about the device and its configuration. If that's the case you could try to make the configuration global by using /etc/asound.conf instead and see if that works.
Interestingly the log file suggested that the configuration had been read since it encountered an error with the BT device.
 
Audacious provides it as an option in the audio preferences. Not sure how to implement system-wide.

Looks like wej was right. Maybe try to force to 44100 using dmix.

Or force rate to 44100 using a slave like Cestarian suggests here.
i don't think so:

in my environment, with my ALSA settings posted above, smplayer works with the exact same files without any issues.
obviously the bt device can function that way and the bitrate is not a show stopper here.

smplayer's settings don't offer anything special (at least that i would know about it) that would set it apart from everything else that uses ALSA.

anyways, i will try to downsample the device definition just to make sure.
 
i don't think so:

in my environment, with my ALSA settings posted above, smplayer works with the exact same files without any issues.
obviously the bt device can function that way and the bitrate is not a show stopper here.
Not necessarily. smplayer could possibly include an internal resampler that is used in case the audio device does not support the required sample rate.
I assume you meant sample rate, not bitrate. The bitrate does not matter at all in this case. The only two things that might cause an issue here are the sample rate and the sample resolution.
If the audio device supports only a fixed sample rate of lets say 48 kHz and you want to play an audio file with 44.1 kHz an application without an internal resampler would not be able to play the file on such an audio device. This is usually not an issue since most sound devices support all common sample rates, or the audio system is even able to resample itself, like ALSA with its dmix plugin. It is hard to tell whether this is the issue here without any additional information. As I said earlier, a log file of Gmu trying to play a file through a BT device could shed some light on the situation. Also, another thing worth trying would be to play an audio file with 48 kHz sample rate. If that works, this would be a clear indication that there is an issue with sampling rate support of the BT device.
 
Failed a bunch trying to get a dmix working. This was my most basic asound.conf:
Code:
pcm.dmixed {
    type dmix
    ipc_key 1024
    slave {
         type bluetooth
         rate 44100
    }
}

pcm.!default {
    type     plug
    slave {
          pcm      "dmixed"
    }
}

Note: do not use this config. It does not work. I only posted in case someone noticed how to fix.

This thread suggests dmix does not play nice with BT.

Maybe there's a way to set up a plugin that can just do rate conversion rather than mixing?
[doublepost=1458621094,1458611343][/doublepost]I should also mention my happy surprise at how long it took me to find a game on my system that failed due to the rate error after setting the default ALSA device to bluetooth. I hadn't tried in a while, and a lot more worked than I remember.

(These broke when trying to use the smidgen config from this post!!)

Worked: Drastic, the EX Emus, Bozon X, Sienna, Panplayer2, Audacious, Deadbeef

ALSA Error: Flappy Bird

Same ALSA Error as @HelenF : nxengine
 
Last edited:
ALSA lib audio/pcm_bluetooth.c:1607:(audioservice_expect) BT_OPEN failed : Das Argument ist ungültig(22)
This is what the log says.. I will try to get the real log up.. but I am at work right now :(

Ok this is what I found in Google, to be precise.
This part I did just memorize and search with google :D :
ALSA lib audio/pcm_bluetooth.c:1607: (audioservice_expect) BT_OPEN failed :
 
Last edited:
What do the parameters actually do (compared to the post on the first page of this thread) ? such as ipc key... ?

Not sure. The default pandora mix I based this off of used key 1234. Everyone else online was using 1024. I tried both, tried deleting it.

I found another few sites that concurred that dmix will not work with Bluetooth, so I'm not investigating that method further myself I think.

I havent read anything that says a rate converter should fail though, but I tried a bunch of those too... Will maybe post one later in case someone knows this stuff better.

ALSA lib audio/pcm_bluetooth.c:1607:(audioservice_expect) BT_OPEN failed : Das Argument ist ungültig(22)
This is what the log says.. I will try to get the real log up.. but I am at work right now :(

Ok this is what I found in Google, to be precise.
This part I did just memorize and search with google :D :
ALSA lib audio/pcm_bluetooth.c:1607: (audioservice_expect) BT_OPEN failed :

Yeah don't use the config I posted. I edited the post to make it clear, but that config does not work.

To get those games to work I modified the basic asound config (like eight bits) to call my Bluetooth device "pcm.!default"

EDIT:
So here is the other method I was trying. Simply using a "pcm.!default" with "type bluetooth" inside was working fine for me for stuff that didn't get the rate error (drastic, audacious, etc). But adding the following rate converter slave fails:

Code:
pcm.sl2 {
     type bluetooth
     rate 44100
}

pcm.!default {
    type  rate
    slave sl2
}

Not sure what is wrong. This config breaks everything, even if it worked before.
 
Last edited:
Haha good. I was worried I caused you to waste your time trying a config I knew was broken.
 
Back
Top