Bluez-Alsa

[greengeek]

apt-get gmplayer

It's

apt-get install gmplayer

But get peasymp3 instead. Its .asouncdrc file already has the lines for bluetooth setup. Mplayer is an automatic dependency of peasymp3.

Your post above shows a successful BT connection to the speaker. That's the hard part. Now you just need to insert its MAC address into the .asouncdrc file. Use a copy/paste.

Then you can run the built-in player.

Thanks. All steps now completed successfully, however I have the following issues:

Mplayer and peasymp3 only play to the inbuilt soundcard (i did not install gmplayer, just the peasy package). I tried to hash out the "default" lines which specified the inbuilt soundcard in .asoundrc but failed to hit the sweet spot. Couldnt get peasy to stream to the bt headphones.

By contrast the "Play" function in the bt4stretch gui did start playing to my BT headphones but the playback was intermittently extremely distorted - hard to describe but very choppy and almost as if two versions were playing at once at faster than normal speed. Between bursts of this strange behaviour the audio played correctly.

I will shelve this for the moment and come back to it when I have learned a bit more. I am about to post a thread with a howto for the Slacko 5.6 procedure as i have found a way to get that going really easily (not Bluez-Alsa, just an older bluez pet that seems working on Slacko 5.6)

[rcrsn51]

The bluez-alsa project exists because bluez5 dropped direct support for ALSA and expects you to use pulseaudio.

This is all discussed here.

The bluez-alsa technique will only play through a special setup like the mplayer in bt4stretch (AFAIK). It works by piping the mplayer output into a customized aplay (running a background process) that can see the BT device. So depending on your hardware and the current load on your computer, the results may not be satisfactory.

For example, if you only wanted to play MP3s, you could replace mplayer with a simpler audio player that might work better.

ALSA by itself cannot see the BT device. In this system, there is no ALSA device named "btheadset" that you can select.

The earlier versions of bluez had hooks into ALSA. Assuming that you could meet all the dependencies of the bluez package and you had a compatible ALSA, this might produce better quality audio output. There was a more direct path between the audio source and the BT output device.

[greengeek]

The bluez-alsa technique will only play through a special setup like the mplayer in bt4stretch (AFAIK). It works by piping the mplayer output into a customized aplay (running a background process) that can see the BT device. So depending on your hardware and the current load on your computer, the results may not be satisfactory.
...
ALSA by itself cannot see the BT device. In this system, there is no ALSA device named "btheadset" that you can select.

The earlier versions of bluez had hooks into ALSA. .

Interesting - thanks for that info. The bluez package i have been testing in Slacko 5.6 provides a .asoundrc file that includes the "btheadset" device and I did try that in my Stretch starter testing but without any understanding of what should/would work. (It didn't work of course).

I plan to come back to this for more testing as there is so much to learn about bluetooth (and alsa configuration) and also because streaming to a bt headset is only one possible function - I will probably need the bluez-alsa at some point to connect to bidirectional devices.

[rcrsn51]

By contrast the "Play" function in the bt4stretch gui did start playing to my BT headphones but the playback was intermittently extremely distorted - hard to describe but very choppy and almost as if two versions were playing at once at faster than normal speed. Between bursts of this strange behaviour the audio played correctly.

I wonder if running the bt4stretch processes at higher priority might solve this problem.

In /usr/local/bin/bt4stretch, change:

Code: Select all

line 15: nice -n -10 mplayer ...
line 193: nice -n -10 bluealsa &

[greengeek]

The bluez-alsa project exists because bluez5 dropped direct support for ALSA and expects you to use pulseaudio.

This is all discussed here.

Thanks for the link. I will quote part of it:

With this application (later named as BlueALSA), one can achieve the same goal as with PulseAudio, but with less dependencies and more bare-metal-like. BlueALSA registers all known Bluetooth audio profiles in Bluez, so in theory every Bluetooth device (with audio capabilities) can be connected. In order to access the audio stream, one has to connect to the ALSA PCM device called bluealsa. The device is based on the ALSA software PCM plugin.

I had not heard of bluealsa so that's on my list to google. This is a project I want to get my teeth into. Can't really explain why my brain processes pulseaudio as repulseaudio. I just don't want it. Nice to see alsa extended once more.

I will get back to testing stretch live and will try the priority mod in a few days. Most of today has been refining a package for Slacko 5.6 - almost done. I have blended bt4stretch with puppybt and thrown out some of the more advanced functionality that I don't need yet. Need to make a thread to get that off my chest then will come back to bluez-alsa.

[greengeek]

I wonder if running the bt4stretch processes at higher priority might solve this problem.

In /usr/local/bin/bt4stretch, change:

Code: Select all

line 15: nice -n -10 mplayer ...
line 193: nice -n -10 bluealsa &

I have made no progress so far using this mod. Sometimes the BT seems to connect but mostly not, and I have not heard any sound from my BT device in the last few tests with BT4stretch (Slacko connection with older bluez still works fine). I can't tell if the issue with BT is my lack of understanding or some variation in the order I am doing things. I am repeating the excercise a number of times in an effort to document the steps required to get the BT working so that I can repeat exactly what I am doing each time.

Should I move to the newer bt4stretch before continuing testing?

[rcrsn51]

Should I move to the newer bt4stretch before continuing testing?

If you want, but it is still using bluetoothctl as the connection app instead of the legacy tools that were in PuppyBT with bluez4.

I am not convinced that bluetoothctl is necessarily any better, but I couldn't get the legacy tools to work with bluez5.

[greengeek]

I wonder if running the bt4stretch processes at higher priority might solve this problem.

In /usr/local/bin/bt4stretch, change:

Code: Select all

line 15: nice -n -10 mplayer ...
line 193: nice -n -10 bluealsa &

Tested this mod again tonight and the BT connection seems perfect. This test was using a different BT device so not 100% a fair test but I will test again on the previous headset as soon as I get the chance.

BT seems problematic on devices that lack their own volume control. The BT stream seems to come through at FULL amplitude. Be prepared..

EDIT : still using the old version of bluez-alsa. Decided to make sure I was correctly repeating previous syntax before updating to the later version. I realised tonight that i was not heeding the HELP1 directive to #quit the control terminal before running player. Probably not an issue but i want to be sure I understand the previous issue in a repeatable way before upgrading.

Edit 2: The audio response from tonight's testing made me realise that the previous testing was on a set of earmuff headphones that are mono not stereo (earmuffs intended for receiving phone calls in an industrial environment). I need to get those earmuffs back for more testing.

[rcrsn51]

V1.2 creates a standard ALSA output device. You set it as the default in your .asoundrc. Then you can control it from the system tray volume applet.

Because v1.2 eliminates the pipelining, the "nice" commands may not be needed to get consistent output.

[rcrsn51]

Any update on tests of v1.2?

[greengeek]

Not yet sorry - i have to wait till i have several hours to myself otherwise my testing gets interrupted and i make no progress.

[greengeek]

I seem to be struggling uphill with this a bit - my last few attempts at testing I feel I have gone backwards somehow. Now i am unable to get a BT connection and during the initial run of bt4stretch i see a message telling me that no bluetooth adapter is found and that the daemon is not running.

Is it possible that the PPM (or whatever stretch uses) is corrupt and I'm downloading a bad package?

[rcrsn51]

The download is OK. I have tested this on various platforms and it works fine for me.

Maybe you need a clean install. Just delete your "changes" folder and start again.

[greengeek]

I don't have a changes folder (as far as I know) - I always select the "no save" option so that each boot gives me the same original environment.

(Just booting from CD each time - no HDD install)

I will keep trying.

[greengeek]

Much more successful tonight - I was able to connect to the headset that previously had "stuttering" issues, and it played perfectly using either carousel or mplayer.

I did try fredx's youtube-viewer but could not make it stream to the headset - it still came out of the laptop speakers.

However Palemoon streamed to the headset fine.

I suspect yesterdays problems with the "daemon not running" must have been some combination of the new bt4strectch version being downloaded by apt-get, but my install/usage method adding in the wrong asoundrc (or something similar)

Anyway, v 1.2 seems promising.

cheers!

EDIT : interestingly - the "stuttering" came back when I unpaired the first headset (the mono one) and tried to stream to a different BT device (a stereo one). I unpaired the first one, paired with the new one, then played via carousel. The sound starts in stuttery fashion for 8 seconds, then comes perfectly clear for 8 seconds, then goes stuttery again, and keeps cycling like that.

Might do some more tests with different devices when time permits.

I then tried streaming from Palemoon again, but no sound came through.

[rcrsn51]

Thanks for testing.

Regarding the stuttering: if you thought that the "nice" command helped in v1.1, you can try it at line 157 of v1.2.

Here are some troubleshooting tips if a device stops working:

1. In bluetoothctl, use the "info" command. It will confirm if a device is properly paired/connected.

2. Check two things in your .asoundrc file:
a. the correct MAC address is inserted
b. the "bluetooth" ALSA device is enabled at the bottom.

You don't need to unpair a device if switching to another one.

[greengeek]

You don't need to unpair a device if switching to another one.

I am still rather confused by the various steps required to link BT devices. For example, i don't understand the difference between "pairing" and "connecting" - according to the bt4stretch help file you have to manually "pair" to the MAC first, then go on to "connect" to the MAC (unless I have misunderstood, which is frequently the case )

Then there is the need to release the remote device before shutting down - is that "unpairing" or "unconnecting"?

I feel that once I have a clearer idea of the layers of the BT protocol I may experience more repeatability and reliability.

[rcrsn51]

I'm not either, except that bluetoothctl clearly needs both.

You only need to pair once, then bluetoothctl adds that info to its database and remembers it.

But you need to connect at each session. If you watch the device's indicator lights and listen to the beeps, you can tell when the connection is made properly.

At one time, I thought that disconnecting a device made it more amenable to connecting at the next session. But that may not be true.

Read here.

[greengeek]

Thanks, that info is useful. I definitely have one device which doesn't connect (or maybe I mean pair?) properly if it is not disconnected properly from previous devices. That device would not show in Linux at all until I disconnected it from my wife's phone (even though she had not connected to it for months). Even if she was out of the house and miles away (obviously not connected) the device stayed hidden.

Is there some way to use apt-get to download the bt4stretch and peasymp3 packages (rather than install) so that I can load the software when required (like a .pet)?

My wife is getting sick of the ethernet cable tracking across the floor.

[rcrsn51]

Is there some way to use apt-get to download the bt4stretch and peasymp3 packages (rather than install) so that I can load the software when required (like a .pet)?

Go into Fred's repo and download the packages. Then install them with Right-click/Install deb.

But you still need to be connected in order to get all the dependent packages.