Discussion between Seamus and ukBaz

ukBaz

06:49

I like the idea you've done of starting the answer and using it to summarise the information you've found so far.
On point zero. "Is Bluetooth Crippled in the lite version...?" The Lite version raison d'être is to offer a very minimal image with only the most minimal of functionality. And there is Bluetooth functionality there. If you do `bluetoothctl show` I am sure thee will be reduced number of services/profiles offered.

Next up, heading 1: "Root privilege"
I've never got my head fully around Linux groups. My simplified view is that a user needs to be in certain groups to get access to certain functionality. Again, this is the lite version so a minimal set is given to the Pi user by default. On the full version below is the groups that the Pi user is in. You'll see there is no `bluetooth` group.
```
pi@raspberrypi:~ $ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio

Next up: *pulseaudio-module-bluetooth is massive*
Again, remember with the lite version you are starting with a very minimal setup. I suspect that there would be very minimal audio in a lite version of the OS so it doesn't surprise me that this brings in lots of dependencies. There appears to be a good page explaining what is going on with pulseaudio under the hood. I'll link to the Bluetooth piece. https://gavv.github.io/articles/pulseaudio-under-the-hood/#bluetooth-backend

ukBaz

07:45

I've been trying to find a block diagram that explains how all the different applications and services interact with each other. I haven't found anything so I'll try to summarise what I understand in a few words. From an audio point of view, BlueZ does very little. It makes a linux socket available for the a2dp service. Audio information presented to it on that socket gets encapsulated and sent over the air to the other device (speaker) that has been paired and connected to it. BlueZ is a pass through. If there is nothing at the socket side or the other end of the Bluetooth link, then Blue…

Seamus

09:07

@ukBaz It's not that difficult really. When you do ls -l, you might get this:

` -rw-r--r-- 1 pi pi 14 Aug 30 23:25 file.txt`

the permissions are listed first for owner, group & all, respectively

Then owner id & group id are listed - pi & pi in this case

In general permissions are read r, write w & execute x

Seamus

09:35

Oh hell... scratch all of that... editing and formatting here are different - didn't realize that. I was going to start over, but no way to delete!? Well - there's plenty online explaining permissions. Nevertheless, bluetooth is a group that apparently has execute permissions for bluetoothctl. No idea how this was done - but having done it - I know that it does work :)

ukBaz

11:42

Understood about the group being shown with ls -l and the permissions fields. What I don't understand is how adding user pi to group bluetooth solves anything when this doesn't appear to be the case for desktop. Anyway, I think it is a side show to getting an a2dp source up and running...

Seamus

18:03

You've just explained why I think this business with the bluetooth group is relevant. It points up the fact that bluetooth services on the Lite distro are crippled. Why? If you've installed the Desktop distro, you can run bluetoothctl without invoking any additional privileges, but if you've installed the Lite distro you cannot run bluetoothctl unless: 1) invoke sudo, or 2) add your user (pi in this case) to the group bluetooth. This question ("Why can't I run bluetoothctl") is a FAQ.

I'll guess the reason you don't see the group bluetooth listed for the user on your Desktop system is because it's done inside one of the binaries/executables associated with overall Bluetooth functionality. Perhaps this is of more interest to me because I don't want to take on the bloat of a Desktop distro just to get Bluetooth. Besides - where is that written: "If you want to use Bluetooth, you must run the Desktop system' ???

Anyway - I understand why you perceive this permissions business as a sideshow, and I am beginning to see the import of the A2DP profile in getting this to work. My hope is that this can be done on the Lite system without being forced to take on too much superfluous software in the process.

ukBaz

20:38

Thinking about this a little bit more, and what you are trying to do must be fairly similar to what someone creating an embedded Linux solutions would need to do. I did a search with the keywords embedded linux a2dp and it turned up the following post. No idea if it applies to the RPi Lite OS, but thought it was interesting enough to pass along: developer.toradex.com/knowledge-base/bluetooth-audio-linux

Seamus

20:51

I think that's a useful link - thank you. I had run across something similar on this site, and in this page that has less context.

Do you feel all of these have to do with a key missing ingredient: the A2DP profile for transmitting to an audio sink, and the software package that knows how to do that?

By that I mean, it seems the A2DP profile is just a line in a configuration file, but there must also be software that's able to package and stream the sound file to the speaker.

Whaddya' think?

ukBaz

My understanding is that you need either BlueAlsa or PulseAudio to offer the A2DP source functionality. I have not idea if BlueAlsa is in RPi Lite. I did an internet search to see if I could find the answer to the question and turned up this: sigmdel.ca/michel/ha/rpi/bluetooth_n_buster_01_en.html

Not sure I have confidence in every detail but they seem to have got it working on RPi Lite

Seamus

Another good resource - and more current than the one I found!

And here's something that you mentioned yesterday:

pi@raspberrypi4b:~ $ bluetoothctl show
Controller DC:A6:32:02:F0:97 (public)
Name: raspberrypi4b
Alias: raspberrypi4b
Class: 0x00000000
Powered: yes
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)

ukBaz

21:10

And here is the same command on the full OS:
```
pi@raspberrypi:~ $ bluetoothctl show
Controller B8:27:EB:22:57:E0 (public)
Name: raspberrypi
Alias: SeeMe
Class: 0x00480000
Powered: yes
Discoverable: no
Pairable: yes
UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: SIM Access (0000112d-0000-1000-8000-00805f9b34fb)

Seamus

I'll guess the Audio Source UUID is the important one for playing music?

ukBaz

Correct

Seamus

Class is also different... is that significant?

ukBaz

Not particularly for what you are focused on

Seamus

Just trying to divine the meaning of all the codes in these lists. It seems that the UUIDs that our systems have in common are the same. But Class is different.

ukBaz

21:19

Found the above diagram at: bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=457083

Seamus

Useful diagram methinks - you've obviously spent some time perusing all of this BT documentation. I've spent very little, expecting it to "just work". Sadly, that's not the case, but at least now I know!

ukBaz

Decoding the class value: ampedrftech.com/cod.htm

Used more when the device is being discovered (which you are not doing in being an Audio Source)

Seamus

But you are apparently... your class is 1) Capturing (Scanner, Microphone) & 2) Telephony (Cordless telephony, Modem, Headset service) ?? Really?

While my RPi is of class "Nothing" :)

I suppose the "Class" code sorts itself once the services are defined?

Seamus

21:40

I think the next step is to 1) declare my RPi as an "Audio Source" via a line in a config file (somewhere), and then 2) install software bluealsa or pulseaudio-module-bluetooth. Does that sound reasonable?

Seamus

This is interesting:

pi@raspberrypi4b:~ $ sudo systemctl status blue*
● bluetooth.target - Bluetooth
Loaded: loaded (/lib/systemd/system/bluetooth.target; static; vendor preset: enabled)
Active: active since Fri 2020-09-11 03:22:35 CDT; 1 day 13h ago
Docs: man:systemd.special(7)

Sep 11 03:22:35 raspberrypi4b systemd[1]: Reached target Bluetooth.

● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-09-11 03:22:35 CDT; 1 day 13h ago

The answer may be here...

Seamus

So odd that all of these little "roadblocks" are set up!

Seamus

22:19

And speaking of the class value: Still reading... found this depressing prognosis:

Buster lite
The setup shown herein sadly doesn’t work for Raspbian Buster lite. For unknown reasons, the device type audio (0x200414) is reset to 0x000000 after every reboot, which prevents the RPi from being recognized as audio sink. If someone has an idea regarding this, please let me know!

Source: knight-of-pi.org/…

Seamus

Of course this is not what I am trying to do at present, but it's something that would be very useful at some point!

Transcript for

Discussion between Seamus and ukBaz