Holliefant
Member
- Joined
- Aug 18, 2008
- Messages
- 478
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.
how did you do that?but had to set the bit depth to 16 in order to not get ALSA errors.
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).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?
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.
im already working on itHmm, if that finally works well, it might make sense adding that to the official OS.
We could even add a small Settings GUI where you can set Bluetooth as default output, etc.
What do you guys think?
how did you do that?
i don't think so: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.
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 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.
That also looks very much like an unsupported sampling rate.The error I got from the games has also appeared on different systems:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631170
http://www.developerblogger.com/15_22272169/
pcm.dmixed {
type dmix
ipc_key 1024
slave {
type bluetooth
rate 44100
}
}
pcm.!default {
type plug
slave {
pcm "dmixed"
}
}
What do the parameters actually do (compared to the post on the first page of this thread) ? such as ipc key... ?
ALSA lib audio/pcm_bluetooth.c:1607audioservice_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 :
ALSA lib audio/pcm_bluetooth.c:1607: (audioservice_expect) BT_OPEN failed :
pcm.sl2 {
type bluetooth
rate 44100
}
pcm.!default {
type rate
slave sl2
}