bluez-alsa and mpd 0.21.x don't play well together; cpu pegged

[TheOldPresbyope]

Please read [https://github.com/MusicPlayerDaemon/MPD/issues/432]

It describes a situation we've run into using bluez-alsa with MPD on Raspberry Pis to direct audio to BT speakers. This combination worked fine with MPD up through v0.20.20. Performance was good and CPU consumption on Rasperry Pis was satisfactorily low.

With MPD v0.21.x, real-time scheduling has been introduced. The real-time rtio thread consumes 100 percent of a cpu core streaming to Bluetooth through bluez-alsa and can drag Raspbian to its knees.

As you will see down thread in the referenced issue, after I ran a test devised by the MPD maintainer he concluded that the problem lay not in MPD but either in bluez-alsa, in the (possibly different) interpretations you and he have of alsa-lib API documentation, or in the API documentation itself.

I'd like to help resolve this issue but it's beyond my technical grasp. At best I can run tests and report results.

[TheOldPresbyope]

This is just a friendly nudge.

Did the brief exchange last month with the MPD maintainer lead anywhere? I'm willing to ask the alsa-lib maintainers for clarification but I don't know how to pose the question and I wouldn't know how to interpret the response.

[arkq]

Did the brief exchange last month with the MPD maintainer lead anywhere?

I'm afraid, that it did not lead "us" anywhere. Quoting from MaxKellermann:

bluez-alsa's implementation makes assumptions on the number and order of poll descriptors - it assumes it will get the exact same buffer which was previously passed to snd_pcm_poll_descriptors(). But the alsa-lib API documentation does not document that applications must do that, therefore I must assume that bluez-alsa's assumption is wrong and this is a bug in bluez-alsa.

He is right, I was not able to find any documentation regarding passed buffers (persistence of it). However, it makes more sense to pass the same buffer to the consecutive calls, than passing different buffer of different size. Let say, that we can pass buffer of any size and ordering to the snd_pcm_poll_descriptors_revents(), so we can pass buffer of few MB at let this function (underlying implementation) to sniff for correct file descriptor - that's insane. Bluez-alsa's implementation is based on the alsa-plugins repository, and every PCM plug-in in this repository check whether the size of the buffer matches exactly (where bluez-alsa allows bigger buffer, but does not use it) the requirements - values returned by the snd_pcm_poll_descriptors_count() - which is explicitly stated by the documentation. It uses the word "should" not "shall"/"must" so there is some room for interpretation (is it?) :D.

The poll desctiptor array should have the size returned by ::snd_pcm_poll_descriptors_count() function.

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga742e8705f6992fd0e36efc868e574f01 There is no info about preserving the ordering, though. BUT, the official implementation of the AAF PCM plug-in does assume, that the order is preserved: http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=aaf/pcm_aaf.c;h=cc7dbe385b974c7e824713578996cc6823312a13;hb=HEAD#l1226 http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=aaf/pcm_aaf.c;h=cc7dbe385b974c7e824713578996cc6823312a13;hb=HEAD#l1250 So, I'm also not willing to change my implementation, which I assume is correct... stalemate :)

[TheOldPresbyope]

Thanks for clarifying the situation.

[moodeaudio]

@arkq,

Stalemate is not good :-(

Per MPD dev's last response if a clarification is obtained from ALSA dev there is a possibility for resolving the issue. MusicPlayerDaemon/MPD#432 (comment)

I'll be happy to ask ALSA team but I don't have any experience with the API and so my conversation might not go anywhere.

I know it's a pain but perhaps you could ask them?

-Tim

[borine]

I've made a fairly simple change to MPD in my fork here:
https://github.com/borine/MPD/tree/alsa-revents
Its in the branch "alsa-revents" which is linked above. This works fine for playback into my bluetooth speaker, but more work is required for capture from my android phone. You need to export LIBASOUND_THREAD_SAFE=0 before starting mpd, otherwise mpd will hang and require kill -9 to terminate. You also need the latest bluealsa code (from commit 97ef828 onwards)
I'd be interested to know if this works for anyone else.

[borine]

@TheOldPresbyope @moodeaudio
I think I've fixed the issue with bluealsa audio capture with MPD. In my testing bluealsa can now be used for both capture and playback with MPD - on an rpi zero W either input or output but not both; on an intel laptop I can do both at the same time. If either of you have time to test my MPD patch from the link above that would be really useful. As we know the MPD maintainer believes the issue to be a bug in bluealsa, not MPD, so is unlikely to accept my patch without strong evidence that it:
a) will not break any other alsa devices (the code affects MPD's alsa interface in general, and is not specific to bluealsa), and
b) there is a genuine demand for it among a worthwhile proportion of MPD's user base.
It would also really help if we could find some other devices (either hardware or alsa IOPLUG extensions) apart from bluealsa that have issues with MPD that are fixed by my patch. So far bluealsa is the only device I have found that uses multiple pollfds in its event interface, which is the root cause of the issue with MPD. @arkq have you come across any examples when developing bluealsa? I think I saw you mention the pulse plugin in a previous exchange about MPD, but when i looked at the current code that plugin uses only a single pollfd.

[TheOldPresbyope]

@borine

Sorry I didn't respond yesterday. Last night I built the current bluez-alsa master and your alsa-revents branch of MPD. My goal was to test them in the moOde audio player, a project maintained by its BDFL @moodeaudio. In my sleepy state I borked something in merging in the new code but will revisit this evening.

moOde audio player runs on Raspbian/RPis. I'd love to help build the case to present to the MPD maintainer but I don't have other examples of breakage.

Note that the MPD maintainer has several times invoked the documentation of the ALSA API as the arbiter. I'm not competent to address the ALSA developers. Do you feel you can make a case to them that the documentation needs to be clarified?

PS - mille grazie for doing this work.

[borine]

A quick update on finding supporting evidence - a quick grep of the alsa repository shows that the following source files from the alsa-lib reposittory explicitly check the size of the pfd array and the order of the array elements passed to snd_pcm_poll_decsriptors_revents(), returning an error if the checks fail:
alsa-lib/src/hwdep/hwdep.c: snd_pcm_hw_poll_revents()
alsa-lib/src/pcm/pcm_hw.c: snd_pcm_hw_poll_revents()

and the following source file from the alsa-plugins repository does not check the pollfd array, but does fail if the elements are in the wrong sequence:
alsa-plugins/aaf/pcm_aaf.c (which @arkq already mentioned in this thread)

What is really needed now is one or more examples of actual devices which trigger these tests and result in failure with MPD. Let's hope someone reading this may be able to report one!

[arkq]

So far bluealsa is the only device I have found that uses multiple pollfds in its event interface, which is the root cause of the issue with MPD. @arkq have you come across any examples when developing bluealsa? I think I saw you mention the pulse plugin in a previous exchange about MPD, but when i looked at the current code that plugin uses only a single pollfd.

@borine No, to be honest I've never come across any application/PCM which has similar issue due to using multiple number of FDs. The only example which has slipped through my fingers is the AAF plugin. However, it was added to the repo on 2018-10-24, so it has been developed pretty recently - one can not say that the "incorrect" usage of the snd_pcm_poll_descriptors_revents() implementation is due to code being old...

I'll be happy to ask ALSA team but I don't have any experience with the API and so my conversation might not go anywhere.
I know it's a pain but perhaps you could ask them?

@moodeaudio I've got rather bad experience of asking alsa-lib developers about anything. I've proposed few patches for ioplug, but no one has ever looked at it - there were not questions but solutions to few issues in the codebase. Few months later one of the addressed issues has been fixed, one half-fixed, but introduced other quirks, and other left untouched. Maybe someone with bigger authority might break through the alsa-lib firewall :D

[moodeaudio]

@arkq, I completely understand your position wrt the alsa-lib project. I've read similar reports of other dev's having great difficulty dealing with alsa-lib proj.

If I understand @borine's evidence of how alsa-lib sources are coded to handle the particular condition we are experiencing I would think that MPD maintainer would seriously consider a PR even though the ALSA documentation may not be golden.

[TheOldPresbyope]

@borine

Can confirm that your alsa-revents branch of MPD combined with current master of bluez-alsa drives my BT speaker from moOde Audio Player on a RPi 3B+. Set LIBASOUND_THREAD_SAFE=0 in /etc/default/mpd. CPU usage is nominal, ca 3%.

$ mpd -V|head
Music Player Daemon 0.21.6 (v0.21.5-12-ga6a8dcbd9)

Once paired and connected, also properly receives BT audio stream from my Nexus phone, but vanilla MPD 0.20.20 and 0.21.5 worked with bluez-alsa in that configuration too.

Much thanks.

[borine]

@TheOldPresbyope

Can confirm that your alsa-revents branch of MPD combined with current master of bluez-alsa drives my BT speaker from moOde Audio Player on a RPi 3B+. Set LIBASOUND_THREAD_SAFE=0 in /etc/default/mpd. CPU usage is nominal, ca 3%.

OK, thanks for testing. I've run it continuously for 3 days on both an rpi zero-w and an intel box. I had one crash of mpd on the rpi, but haven't been able to reproduce it. Other than that it works well not only with bluealsa, but also an IQAudio DAC and an intel HDA chipset.

Once paired and connected, also properly receives BT audio stream from my Nexus phone, but vanilla MPD 0.20.20 and 0.21.5 worked with bluez-alsa in that configuration too.

Hmm, I'm surprised that MPD 0.21.5 works at all with buealsa - it makes the same call to snd_pcm_poll_descriptors_revents() that fails with playback when capturing also. That call was introduced in MPD 0.21.2.
In any case, you should find that audio capture uses much less CPU with the latest MPD master branch than any release from the 0.21.x branch since the default sampling rate has been changed to 48kHz - I wrote that change as part of my efforts to get bluealsa and MPD playing nicely together.
@moodeaudio -
do you produce an "experimental" or "development" release of moode? And if so could I persuade to to try out a release with mpd built from my alsa-revents branch? That way we could get a lot of test mileage completed in a relatively short time, hopefully with constructive feedback. As I have not been able to reproduce the one failure I had, I'm a bit nervous of raising a PR on the upstream sources in case there is a hidden gotcha in there.

[moodeaudio]

Sure, here's link to moOde 5 beta :-)
http://moodeaudio.org/forum/showthread.php?tid=1183

[borine]

@moodeaudio thanks.
I've just found a possible lock-up in my MPD code when used with bluealsa, but haven't yet decided whether it's best addressed in bluealsa or MPD. It's related to my previous patch to bluealsa to handle the alsa sw params start_threshold case properly. After dropping a stream, MPD can wait indefinitely in a call to epoll() because bluealsa does not generate an event if snd_pcm_avail_update() returns 0.

I can reproduce this lock-up reliably today just by doing "mpc next" while listening to a playlist. MPD stops the current song but never starts the next one. Not sure how I came to miss this earlier.

Anyway, I need a little to to determine whether this is a defect in bluealsa or MPD, (or both).

I'll make a new commit when I have a fix ready.

[TheOldPresbyope]

@borine

Hmm, I'm surprised that MPD 0.21.5 works at all with buealsa - it makes the same call to snd_pcm_poll_descriptors_revents() that fails with playback when capturing also. That call was introduced in MPD 0.21.2.

I just checked to be sure I wasn't mis-remembering. With moOde r50c (the beta referred to above) running MPD 0.21.5 I'm getting Bluetooth audio streaming in from my Nexus phone and playing through the onboard audio. Nominal CPU usage.

[borine]

@TheOldPresbyope
... and you are sure that moode is using mpd for bluetooth capture? maybe it uses bluealsa-aplay or some other ?

[borine]

@arkq
The alsa docs are as vague as ever when describing the expected behavior of poll() with a pcm handle that is in the SETUP state. I tested the hardware device, and with this poll() returns immediately and snd_poll_descriptors_revents() sets revents to POLLOUT | POLLERR and returns 0. So maybe bluealsa should do the same? If you agree I can prepare a PR

[TheOldPresbyope]

@borine

I'm not seeing the lock-up you report. moOde builds a playlist from my selections from sources. I can switch between tracks on the playlist. "mpc next" works. [on RPi3B+, Raspbian, moOde r50c]

[borine]

@TheOldPresbyope

I'm not seeing the lock-up you report. moOde builds a playlist from my selections from sources. I can switch between tracks on the playlist. "mpc next" works. [on RPi3B+, Raspbian, moOde r50c]

Ok, thanks, that's very useful feedback. I'll dig further to see what's happening on my system.

[TheOldPresbyope]

@TheOldPresbyope
... and you are sure that moode is using mpd for bluetooth capture? maybe it uses bluealsa-aplay or some other ?

My bad. You are correct of course. I forgot moOde selects bluealsa-aplay as its BT renderer. Sorry.

[borine]

So, why I didn't get lockups until today, and (I think) @TheOldPresbyope does not get them.
Bluealsa only accepts pcm streams sampled at 48kHz. If the application configures the alsa device with any other sample rate then by default alsa invokes its own internal resampler - meaning that the application is actually interacting with the resampler and not directly with bluealsa. If I play a song sampled at, say, 44.1 kHz then mpd and bluealsa sing along nicely. But if I play one sampled at 48kHz then MPD talks directly to the bluealsa interface and locks up when I do "next". Until now I was playing my CD rips, all 44.1kHz. Today I was playing mp3s sampled at 48kHz - lockup every time.
If I add:
auto_resample = "false"
to the audio_output block for the bluetooth speaker in mpd.conf then the alsa resampler is never used and every track locks up when skipping to "next".
This is a bug and needs to be fixed before my code can be released. My preferred fix is to change the bluealsa alsa pcm plugin to show the same behavior as the hardware plugin. It is also possible to modify MPD to cope with the different behavior, but then I fear the chances of getting any of my code accepted upstream will be very small (the odds are already against it).

[moodeaudio]

Below are the files that moOde 5 beta uses for bluealsa audio output. Maybe this config is causing issue?

In the file /etc/bluealsaaplay.conf the param AUDIODEV is set to plughw:0,0 or if Bluetooth speaker sharing is turned on in moOde Audio Config then its set to btaplay_dmix which invokes /usr/share/alsa/alsa.conf.d/20-bluealsa-dmix.conf. AFAIK plughw will automatically try to reformat the audio stream to be compatible with output device. IIRC it used to be set to hw:0,0 in some earlier version of moOde.

/etc/mpd.conf

audio_output {
type "alsa"
name "ALSA bluetooth"
device "btstream"
mixer_type "software"
auto_resample "no"
auto_channels "no"
auto_format "no"
buffer_time "500000"
period_time "256000000"
}

/etc/bluealsaaplay.conf

AUDIODEV=plughw:0,0

/usr/share/alsa/alsa.conf.d/20-bluealsa-dmix.conf

pcm.btstream {
type plug
slave.pcm {
type bluealsa
device "XX:XX:XX:XX:XX:XX"
profile "a2dp"
}
}

/usr/share/alsa/alsa.conf.d/20-bluealsa-dmix.conf

pcm.btaplay_dmix {
type plug
slave.pcm "plug_btaplay_dmix"
}

pcm.plug_btaplay_dmix {
type dmix
ipc_key 321456
slave {
pcm {
type hw
card 0
device 0
}
format "S16_LE"
rate 44100
}
}

[TheOldPresbyope]

@borine

Correct, I was playing 44.1KHz rips of CD in my successful test of "next". Can't say for sure about the web radio stations. I'll try repro'ing your auto_resample= "false" test tonight. My gut feel is that I will see the same result.

All this is making me acutely aware of how superficially I understand the MPD-ALSA-BluezAlsa wiring.

s an aside, I agree with your assessment regarding "preferred fix".

[borine]

@TheOldPresbyope
I see from @moodeaudio above that mpd in moode always accesses bluealsa though a plug interface and sets auto_resample to "no" (which is an alias for "false"), so it seems my analysis was not complete, and other factors are also involved.

s an aside, I agree with your assessment regarding "preferred fix".

I see that @arkq is very busy atm implementing a d-bus interface for bluealsa, so I've just gone ahead and prepared a PR that makes the changes I think are necessary in the alsa pcm plugin. It can sit in his in-box until he has enough free time to consider it.

In the meantime I'm happy that I have working builds of mpd and bluealsa that work well together (at least in my use cases) so I'll take a break from this effort for a while and just enjoy the music.

Thanks to all for helping me get this far.

[arkq]

@borine Sorry for not being very responsive, but indeed I'm busy (not with bluez-alsa alone, but in general) :) I'm watching this thread, though. If you've got any fixes please do not hesitate to make a PR.

I know that the PCM ALSA plug-in is buggy but unfortunately it is rather hard to implement it in a correct way - there is no test-suit for ALSA PCM... and the documentation is "in the alsa-lib code" mostly. In a long run there is a plan for a total ALSA PCM plug-in refactoring, but right now I don't know where the direction should be, so I'm very happy with any fixes to current implementation. It might be also beneficial to have PCM test cases in case of future changes, so the knowledge how the PCM should behave will not fade away. But it might be a rather tedious work... Once, I've tried to create a test for BT device disconnection - analogue of USB-based sound card eject. And the problem is, that without alsa-lib fixes this work is impossible - there are some bugs in the ioplug code that prevent correct implementation (that was my first "pleasure" with alsa-lib mailing list).

[moodeaudio]

Hi,

This issue has been fixed in bluez-alsa 2.0.0. It works perfectly with MPD 0.21.15 :-)

@TheOldPresbyope, I'd propose closing the issue.

[arkq]

I'm not sure how it has been fixed :D I have not made any changes related to file descriptor ordering. From my point of view with 2.0.0 it might be even worse than before, because the number of file descriptors is controlled by libdbus. So maybe it was fixed by mdp...?

[moodeaudio]

lol, I didn't see a specific mention of it in MPD change log so I assumed you made some changes in 2.0.0 that fixed it. We may never know what was causing the failure or how it's been somehow fixed but it's working now and hopefully will continue to do so going forward :-)

[borine]

Actually, the combination of bluealsa with mpd works "by accident", and has done so since bluealsa commit aab107c which removed the check on the size of the pfd array passed by mpd to bluealsa after a poll() event.
I say "by accident" because the the array passed is still not what bluealsa expects. So, for example, if the BT device is disconnected while playing, the bluealsa client will not detect this event, so it is not properly handled and mpd receives a SIGPIPE when it tries send audio data to a device that is no longer there. There may be other events that are not properly handled, it's hard to be sure by just reading the code but it does seem that all "essential" events are handled; so MPD does not fail, deadlock or thrash the CPU any more, it just occasionally emits confusing error messages.

[moodeaudio]

I see. Maybe best to leave the issue open.

I'll have to do more A/B testing to determine whether to stay on 1.3.1 and the two MPD's or go for 2.0.0 and MPD 0.21.y.

After a bit of testing this morning I'm seeing a delay of 30 secs between the time when an incoming bluetooth connection is established and the time when the udev rule fires that starts bluealsa-aplay I don't recall this delay being present on 1.3.1 but I'll test to be sure.

syslog

// connected
Nov  6 09:12:07 rp2 kernel: [ 4201.913260] input: 08:F6:9C:8F:6B:C5 as /devices/virtual/input/input1

// udev rule fires 30 secs later
// this rule restarts MPD and then starts BlueAlsa-Aplay
Nov  6 09:12:37 rp2 systemd[1]: Stopping Music Player Daemon...
Nov  6 09:12:37 rp2 systemd[1]: mpd.service: Succeeded.
Nov  6 09:12:37 rp2 systemd[1]: Stopped Music Player Daemon.
Nov  6 09:12:37 rp2 systemd[1]: Started Music Player Daemon.
Nov  6 09:12:37 rp2 systemd[1]: Started BlueAlsa-Aplay.

[arkq]

I don't know for what you need udev, but with 2.0.0 everything should be wired via DBus. You can start bluealsa-aplay before bluealsa :)

[moodeaudio]

I'll have to study that some more.

The udev rule detects the incoming client connection and then does a few things to switch playback from MPD to bluealsa-aplay.

Is there a way to detect the connection and run a script via d-bus?

[paul-1]

You would need a lightweight daemon watching dbus events. I use a small python script to handle this...... This is not for the current version of bluelasa, but this concept works nicely.
https://github.com/oweitman/squeezelite-bluetooth

[moodeaudio]

Testing suggests that its kernel 4.19.81 that causes the 30 sec delay issue and some other breakage. This happens with either 1.3.1 or 2.0.0 bluez-alsa.

Reverting to < kernel 4.19.81 and no issues with either 1.3.1 or 2.0.0 blues-alsa. Note that I only tested w/ 4.19.80 and 4.19.75.

[moodeaudio]

To add, I'm not necessarily ruling out an MPD issue. I've been testing with MPD 0.21.15 and one of the moOde devs suggested testing with the latest 0.21.16 release. I'll get to that tonight and report back.

[moodeaudio]

Same issue with 4.19.81 + MPD 0.21.16 + bluez-alsa 2.0.0. Note that I'm only able to do integration testing and not debugging of the kernel or other parts for his issue. Swapping is a kernel that's < 4.19.81 and no issues.

[borine]

Forget what I said about "confusing error messages" - turns out the "broken pipe" error message is normal behaviour for all applications when a BT device disconnects with bluealsa. So FWIW I think it is now safe to use the pcm plugin from bluealsa >= 2.0.0 in combination with mpd 0.21.x or 0.22.x (when released). Even though the interaction is not as designed, it is still predictable, stable, and reliable.

I haven't checked the ctl plugin yet, but expect to have rather more issues with mpd's unique alsa code there. If I get time later I'll set up a test with the mpd mixer_type set to "hardware" and see where that takes me.

[borine]

when using the "hardware" mixer_type mpd aborts with an assertion failure when the BT device is disconnected from bluealsa.

That failure is most definitely a bug in mpd, and I did raise a PR to fix it, but then withdrew it when I realised it only did half the job.

This is because the bluealsa ctl plugin also causes an assertion failure in libasound if the bluealsa daemon is stopped (you can see alsamixer fall over to demonstrate this one is not an mpd bug)

So my advice is to always use mpd's "software" mixer, never the (default) "hardware" mixer with bluealsa until both these assertion failures are fixed.

[roizcorp]

Guys, How long I should play music from MPD->BT until the quirks you describe happen? I have a working environment, but I need to check BlueAlsa version and perhaps update it into 2.0.0
Also I never got the chance to BT stream into MPD (if you will share how to do it I could test it as well)

[borine]

@roizcorp MPD's alsa interface has never been fully compatible with bluealsa. The two projects use fundamentally different interpretations of the alsa specification regarding the use of poll() to handle events. As each project has changed over time, so the effect of this incompatibility has changed. So the results you see will depend entirely on which versions of mpd and bluealsa you are trying to use together. Right now, the latest release of bluealsa (2.0.0 ), and all updates to the master branch since then, works well with the latest release of mpd (0.21.19) and also the mpd development branch (0.22.x) provided you use mpd's software mixer, not the "hardware" mixer. With these latest versions, you should be able to play music continuously with no time limit.

Also I never got the chance to BT stream into MPD (if you will share how to do it I could test it as well)

You would need put an alsa input definition into your mpd.conf file. Check out mpd's documentation for using its alsa input plugin. Mpd's alsa plugin code is much improved in the master branch (0.22.x) and is documented here: https://www.musicpd.org/doc/html/plugins.html#alsa
The current 0.21.19 release uses older code which had different defaults so you would have to get the documentation from the source code.

[edit] I've just remembered mpd 0.21.x does not have any config options for alsa input - they are introduced in the development 0.22.x branch. So for mpd 0.21.x you have to use the hard-coded default audio format, no need for mpd.conf entry. I don't have an install of 0.21.x available to test, but from memory an example using the mpc client program would be:

mpc add alsa://bluealsa:DEV=xx:xx:xx:xx:xx:xx,PROFILE=a2dp
mpc play

mpd 0.21.x will resample the stream to 44100:16:2.

[roizcorp]

Hi,
Thanks for the info
I've checked and currently I'm running bluealsa 1.4.0 with MPD 21.19 with no issues although it is not my main playing option (analog is the primary).
I will however upgrade bluealsa into 2.0.0 because i cannot help myself from upgrading any software
What are the perks for the newer release, I cannot find proper release notes

[arkq]

What are the perks for the newer release, I cannot find proper release notes

I'm a little bit lazy to create release notes... But the main change for >= 2.0.0 is the usage of D-Bus as an interface for BlueALSA server. This change alone should improve overall stability (especially during system startup). Also, there was a lot of work around phone audio (SCO profile), which should more or less work with the latest release (v2.1.0).

[roizcorp]

so basically refactoring...which is good

[roizcorp]

I must admit, I have not upgraded yet..I'm torn between the fact 1.4.0 works perfectly to my understanding and 2.0.0 is newer and cooler.
does 2.0.0 configs asoundrc automatically? cause this is a pain!

[roizcorp]

so I have 2 environment:

• Production: Bluealsa 1.4.0 MPD 0.21.19 - mpd is playing BT whenever is available and connected, only root user

• Staging: Bluealsa 2.1.0 MPD 0.21.19 - mpd is not recognizing bluealsa at all but I'm able to play very "chopy" sound with aplay -D bluealsa some.wav, additional normal user which runs mpd

[borine]

@arkq The fact is that bluealsa and mpd do work together now in both their latest release code current development code. So I recommend that this issue be closed as current comments are really completely different issues.
@roizcorp If you are having issues specifically with bluealsa 2.1.0 then I recommend that a new issue be opened giving details of your specific configuration. Whatever the underlying cause of your problem, you can be certain that ii is not a generic problem that is impacting all users of bluealsa with mpd (which the original problem that gave rise to this issue was). That way we make this discussion be more helpful to other users who may have similar issues to yours.

[roizcorp]

@borine do you build your MPD and Bluealsa directly from git i.e. the latest code available? I'm only intrested to use them both? can you share your mpd/bluealsa/alsa/asoundrc configuration so I could see what I'm doing wrong? for some reason MPD does not like the bluealsa output configuration which worked previously SRV=org.bluealsa...
many thanks

[borine]

can you share your mpd/bluealsa/alsa/asoundrc configuration

So here is my last post to this thread; a working example installation:

platform

Raspberry Pi 3B+, headless
Raspbian Lite 2020-02-13, fully updated

bluealsa

follow build instructions here:
https://github.com/Arkq/bluez-alsa/wiki/Installation-from-source

configure options:
--enable-debug --sysconfdir=/etc

create bluealsa system account and add to groups audio and bluetooth

sudo adduser --system --disabled-login --no-create-home --group bluealsa
sudo adduser bluealsa bluetooth
sudo adduser bluealsa audio

follow systemd instructions here:
https://github.com/Arkq/bluez-alsa/wiki/Systemd-integration

uncomment these entries in /etc/systemd/system/bluealsa.service

User=bluealsa
Group=audio
NoNewPrivileges=true

modify /etc/dbus-1/system.d/bluealsa.conf
as per the Note in above systemd instructions

enable the bluealsa service

sudo systemctl daemon-reload
sudo systemctl enable bluealsa.service

add user pi to bluetooth group and reload dbus config

sudo adduser pi bluetooth
sudo systemctl reload dbus.service

mpd

obtain latest sources:

git clone https://github.com/MusicPlayerDaemon/MPD.git --branch v0.21.x

(note: master branch can also be used if you prefer)

follow the instructions here:
https://www.musicpd.org/doc/html/user.html#compiling-from-source

create config file:

cp doc/mpdconf.example /usr/local/etc/mpd.conf

create mpd system account and add to group audio:

sudo adduser --system --disabled-login --no-create-home --group mpd
sudo adduser mpd audio

create mpd data storage structure:

sudo mkdir -p /var/lib/mpd/playlists
sudo mkdir -p /var/lib/mpd/music
sudo chown -R mpd:mpd /var/lib/mpd
sudo chmod -R 755 /var/lib/mpd

edit the following entries in /usr/local/etc/mpd.conf:

music_directory    "/var/lib/mpd/music"
playlist_directory "/var/lib/mpd/playlists"
db_file            "/var/lib/mpd/database"
log_file           "/var/lib/mpd/log"
pid_file           "/var/lib/mpd/pid"
state_file         "/var/lib/mpd/state"
sticker_file       "/var/lib/mpd/sticker.sql"
user	           "mpd"
group	           "audio"

create a new audio output entry in /usr/local/etc/mpd.conf

audio_output {
	type       "alsa"
	name       "Bluetooth"
	device     "bluealsa:DEV=xx:xx:xx:xx:xx:xx,PROFILE=a2dp"
	mixer_type "software"
}

enable the mpd socket unit:

sudo systemctl daemon-reload
sudo systemctl enable mpd.socket

Using the installation

make sure services are running

sudo systemctl start bluealsa.service
sudo systemctl start mpd.socket

pair and connect the bluetooth speaker using bluetoothctl
(instructions omitted)

add music files to /var/lib/mpd/music
(instructions omitted)

mpc update

play music

mpc findadd artist "Van Morrison"
mpc play

[roizcorp]

Thank you @borine , I'm using archlinuxarm over raspberry pi 4 (the first bluealsa env. is running over rpi1 !). Prior to your reply it did not work for me but the only things i did change (and are taken for your post) are the addition of the argument --sysconfdir=/etc and adding the bluealsa user to audio (different command on arch), MPD is installed from the repository normally and I'm running my own mpd.conf with the bluealsa output specification as mentioned (it was already set this way when it failed) but now it works!
I suggest to add those 2 ( --sysconfdir=/etc and adding the bluealsa user to the audio group) to the documentation
I cannot identify CPU throttling or anything, if you need me to check something give me a shout
Many thanks!

[borine]

one last final, final comment 😄
@roizcorp - thanks for your feedback. As a result I've made 2 changes:

• use of the audio group was only necessary because of the example systemd unit file in the wiki. I've now edited the wiki, so if that method is followed now audio group membership is not needed

• I've just submiited a PR that will remove the need for the --sysconfdir option to configure - if that is accepted then a default configure will do the right thing.

I think this issue can now, finally, be closed

[borine]

The original issue reported here was removed by a change to bluez-alsa code many months ago. Bluealsa PCMs are currently working well with MPD provided the latest releases (or development code) of both projects is used. There is stiil a bug in MPD which causes it to fail when a ctl element is removed, but that is not the fault of bluealsa (by design bluetooth mixer controls are removed when the corresponding bluetoth device disconnects). The ALSA API allows applications to test for and handle this event, but MPD does not do that. You can work around it by using MPD's internal software mixer to avoid use of the bluealsa volume control.

I'm closing this as many of the comments are no longer relevant to latest bluez-alsa and MPD code, Please open a new issue if you experience a problem using latest MPD with latest bluealsa.