Bluetooth headset status?

ekianjo · Mar 22, 2016

I get a couple of issues with Audacious: it hangs sometimes when moving automatically to the following track (rare but occurs...) and more important when I read the end of the playlist it hangs systematically and I have to kill the application. Anyone else getting the same issue with BT audio ?

One more thing / no matter the player, I guess bluetooth is too late to catch up with the music when starting a track, and the first few seconds are missing. Is there anything that's possible to prevent that effect ?

directive0 · Mar 22, 2016

Wait, edgex are you advising those of us who added the snippet of code you posted earlier to replace it with the section you just posted up there now?

Eight Bit · Mar 22, 2016

@ekianjo That's weird, for me it's actually mad responsive and way better than my ipad for instance which speeds up the first 3 seconds of the music to catch up. I have no loss at the start of tracks at all and they all start instantly, and neither does it crash at the end of any playlist, at least not that I have noticed yet. I made a quick video to show how fast it responds.

edgex004 · Mar 22, 2016

directive0 said:
Wait, edgex are you advising those of us who added the snippet of code you posted earlier to replace it with the section you just posted up there now?

None of the snippets I posted should be used. They do not work. I was hoping someone might have an idea as to what might be wrong with them.

directive0 · Mar 22, 2016

But... they DO work. I used it and it was fine?

I clearly missed the bulk of this conversation.

edgex004 · Mar 22, 2016

directive0 said:
But... they DO work. I used it and it was fine?

I clearly missed the bulk of this conversation.

Can you post your whole file?

What I posted was the entirety of my file. If you just added mine to the end, perhaps you have another device in your file that your Pandora is falling back on.

KickAss · Mar 22, 2016

Eight Bit said:
Oh nice, Do I understand correctly that you're working on a system wide bluetooth audio solution KickAss?

thats right.

im trying to provide proper alsa config files for different use cases (system wide bt - as far as thats possible - vs hw only output) and an easy way to switch 'em.
basically i got bt working with most of the applications i use. im still struggeling with the rest, gmu being but one example. alsa and its docs give me a hard time

edgex004 · Mar 23, 2016

KickAss said:
thats right.
im trying to provide proper alsa config files for different use cases (system wide bt - as far as thats possible - vs hw only output) and an easy way to switch 'em.
basically i got bt working with most of the applications i use. im still struggeling with the rest, gmu being but one example. alsa and its docs give me a hard time

I'm thinking this might be the best way to go, if in fact the sample rate is the problem:

pcm.name {
type rate # Rate PCM
slave STR # Slave name
# or
slave { # Slave definition
pcm STR # Slave PCM name
# or
pcm { } # Slave PCM definition
rate INT # Slave rate
[format STR] # Slave format
}
converter STR # optional
# or
converter [ STR1 STR2 ... ] # optional
# Converter type, default is taken from
# defaults.pcm.rate_converter
}

Adhering to the above as closely as possible, a default device that performs rate conversion of bluetooth should look something like this:

Code:

pcm.!default {
     type rate
     slave {
          pcm {
               type bluetooth
          }
     rate 44100
     }
}

Edit: Just tested. The above config works exactly the same as:

Code:

pcm.!default {
    type bluetooth
}

The programs that work are the same (deadbeef, audacious, etc)

The programs that error out continue to give the same error (flappy bird, nxengine, etc)
[doublepost=1458695034,1458678168][/doublepost]Still not sure why some programs are failing.

The last conversion snippet I posted does indeed seem to work as intended. It seems to be performing a rate conversion prior to sending the sound to BT audio.

If I replace 44100 in that snippet with something else, say 8000 or 96000, programs that used to work now fail with the following error:

From Drastic:

Code:

ALSA output: requested rate of 44100, got 44100.
ALSA output: requested buffer size of 8192, got 8192.
ALSA output: requested period size of 2048, got 2048.
ERROR: Audio failed to initialize HW params (Invalid argument)
ERROR: Audio failed to initialize SW params (Input/output error)
ALSA output: Using synchronous engine.

However, using a value that I know is valid, such as 44100, all the programs that worked before still work, and all the programs that are broken are still broken with the error @HelenF was getting.

Is it possible some applications perform the rate conversion, but others don't? Or is the error something else altogether? The error Drastic returns after forcing a bad rate conversion is different than the one from the other non-working programs.

The other possibility is that the sample rate conversion plugin is broken. It could be leaving the 44100 rates alone, and therefore those programs continue to work, but when they try to convert sample rates, we get an error.

More oddity is that both 44000, 44100, and 48000 rates all work the same.

ekianjo · Mar 23, 2016

Eight Bit said:
@ekianjo That's weird, for me it's actually mad responsive and way better than my ipad for instance which speeds up the first 3 seconds of the music to catch up. I have no loss at the start of tracks at all and they all start instantly, and neither does it crash at the end of any playlist, at least not that I have noticed yet. I made a quick video to show how fast it responds.

I can't check the video now but can you let me know the exact settings you put in Audacious ?

TrashyMG · Mar 23, 2016

Just gave Bluetooth audio a go after updating the OS today, just have to say it works quite well with Kodi so far.

edgex004 · Mar 23, 2016

I'm wondering if something like this would work.

Basically, since BT seems to work great with the majority of applications I've tried, I'm wondering if we can set up ALSA to have the default output be both hw and bluetooth.

Maybe then if apps that don't work with BT fail to initialize BT sound, they will continue to work, but just fall back on hw output. At the moment, some of the applications just crash when they can't initialize the ALSA device.

I feel like this would be the most seamless solution for turning on a "default to BT" option.

TrashyMG · Mar 23, 2016

Perhaps a Toggle on the tray menu wouldn't be a bad idea.

ekianjo · Mar 23, 2016

TrashyMG said:
Perhaps a Toggle on the tray menu wouldn't be a bad idea.

I was thinking along the same line. This should be in the same tray menu as where you activate/deactivate wifi and bluetooth and so on. It would fit well there.

Eight Bit · Mar 23, 2016

ekianjo said:
I can't check the video now but can you let me know the exact settings you put in Audacious ?

I don't think I set something special except that I switched off the winamp skin and switched on softvol. Bitdepth is at 16, buffer size 500ms
I did find that bluetooth works better when wi-fi is off.

KickAss · Mar 24, 2016

Eight Bit said:
I don't think I set something special except that I switched off the winamp skin and switched on softvol. Bitdepth is at 16, buffer size 500ms
I did find that bluetooth works better when wi-fi is off.

that's right. using bluetooth and the onboard wifi simultaneously == no joy.

but bluetooth + usb wifi == superduper.

ekianjo · Mar 24, 2016

KickAss said:
but bluetooth + usb wifi == superduper.

oh that's good to know!

KickAss · Mar 25, 2016

ALSA is giving me a terrible headache,
but i found a config which works quite well!

at first i thought: wait, maybe switching files isn't necessary at all. ALSA tries hard to figure out what kind of setup you are trying to use and to provide some sort of fallback if something fails. unfortunately bluetooth doesn't play well with that design.

what do we want to achieve with our pandora setup:
* enable bt audio output and make it easily available (as in setting it as pcm.!default - so everything that's pushing audio through ALSA will use our bt device).
* let the user switch between hardware output and bluetooth output
* with as little required configuration work as possible

unfortunately i can't make ALSA recognize the bt headset as a "real" device. thus my initial plan to use alsamixer to switch from hw to the bt device failed

but i managed to get a softvol control in and route the bt traffic to it, so its possible to control the bt volume in alsamixer now.

so yeah, i guess in our case it's best and prolly most convenient to provide config files for bt audio and hw audio and just switch em depending on what the user wants to use.
the good news is:
ALSA is quite smart, in it's default setting it parses several spots for available config files. you may have read about:

Code:

/etc/asound.conf
AND
~/.asoundrc

both of them are equal in terms of validity for ALSA.
this means that we can config our setup entirely on user level (which makes switching files through scripts a lot easier).
so i do suggest to use ~/.asoundrc only. it works great for me.

i will refine what i did so far, test it a little more, write a tutorial on how to set things up properly and write a tool to switch config files on demand.
i do hope you still got a little patience, cuz im actually really busy

UPDATE:
switching output on the fly works as expected. the script is almost done.

UPDATE #2:
the script is done and works (well, its really simple...). it can, should you want to do that, easily be added to the menubar toggles (as mentioned earlier).
i gotta go to work now. will upload the files and basic explanation tomorrow. extensive tutorial later.

ABOUT GMU:
it still ignores the bt device, which is weird, because a simple mplayer call without any further options (ergo using pcm.!default) gives crystal bluetooth audio.

Eight Bit · Mar 25, 2016

Really good job m8! Looking forward to it!

ptitSeb · Mar 26, 2016

Don't forget that for "~/.asoundrc", the "HOME" is all the time redifined in a PND to point to the appdata folder and not the real home in NAND folder... Maybe that's why your settings are ignore in GMU?

KickAss · Mar 26, 2016

ptitSeb said:
Don't forget that for "~/.asoundrc", the "HOME" is all the time redifined in a PND to point to the appdata folder and not the real home in NAND folder... Maybe that's why your settings are ignore in GMU?

ALSA parses the config files on it's own, out of the scope of any PND.

i'd like to investigate how gmu invokes mplayer to play the files. because plain mplayer works the way it should.
[doublepost=1458985018,1458981560][/doublepost]okay, back from work, so here are the files (the switch script - audioswitch.sh is in the attached .zip file).
this is for those who would like to testdrive things. i will write a proper tutorial later. need to sleep first. so here we go:

.asoundrc_bt:

Code:

# This is the bluetooth enabled ALSA config file.
# It is meant to set the main audio output to bluetooth.
# Please set device's MAC Address correctly or try autodetection.
#
# Try Alsa's BT autodetection
#@hooks [
#    {
#        func load
#        files [
#            "/usr/share/alsa/bluetooth.conf"
#        ]
#        errors false
#    }
#]

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

pcm.btheadset {
    type bluetooth
    device "XX:XX:XX:XX:XX:XX"
    rate "44100"
    profile "auto"
}

pcm.bluetooth {
    type plug
    slave {
        pcm btheadset
    }
}

ctl.bluetooth {
    type plug
    slave {
        pcm btheadset
    }
}

pcm.btsoftvol {
    type softvol
    slave.pcm "bluetooth"
    control.name "Master"
    control.card 0
}

ctl.btsoftvol {
    type softvol
    slave.pcm "bluetooth"
    control.name "Master"
    control.card 0
}

.asoundrc_hw:

Code:

# This is the hardware enabled ALSA config file.
# It is meant to set audio output to hardware (built in speakers).

pcm.dmixed {
    type dmix
    ipc_key 1234
    slave {
         pcm "hw:0"
         buffer_size 8192
         period_size 2048
         #periods 128
         period_time 0
         buffer_time 0
         rate 44100
    }
}


pcm.softvol {
    type softvol
    slave {
          pcm      "dmixed"
    }
    control {
          name     "Master"
          card 0
    }
}

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

pcm.dsp0 {
    type plug
    slave {
          pcm "hw:0"
    }
}

ctl.dsp0 {
    type plug
    slave.pcm "hw:0"
}

ctl.mixer0 {
    type plug
    slave.pcm "hw:0"
}

audioswitch.sh is pretty much selfexplanatory. try the --help flag

chmod +x if it wont run.
put the .asoundrc files in ~/alsafiles OR adjust ALSAFILES_PATH in the script to your liking.
backup your existing ~/.asoundrc AND /etc/asound.conf AND then delete them.
try alsamixer to control your bluetooth volume (AFTER you started playing audio via bt).

i tested this a lot on slackware 14.1.
didn't have time to test it on zaxxon. but it should work, i guess.

please enjoy and give proper feedback.

an extensive tutorial (including bt device pairing, proper setup of config files etc.) will follow soon.

Bluetooth headset status?

Hardcore Member

Very Active Member

Hardcore Member

Advanced Member

Very Active Member

Advanced Member

Very Active Member

Advanced Member

Hardcore Member

Sarcasm Dispenser

Advanced Member

Sarcasm Dispenser

Hardcore Member

Hardcore Member

Very Active Member

Hardcore Member

Very Active Member

Hardcore Member

Serial Porter

Very Active Member

Attachments

Similar threads