Music Player Daemon and bluealsa sink about bluez-alsa

[kuikka]

If the application is doing select() or poll() manually it has to call snd_pcm_poll_descriptors_revents() after poll/select to give alsa the chance to serve the socket(s).

That is, unless it is using some of the API that does that internally already, such as snd_pcm_wait().

[kuikka]

Well, turns out there is more. snd_pcm_writei() will perform the wait unless the audio device is in non-blocking mode, which is the case with MPD, is likely the cause here.

[skidoo23]

MPDs input plugin opens ALSA caputure device with SND_PCM_STREAM_CAPTURE, SND_PCM_NONBLOCK options. Using snd_pcm_readi with bluealsa results most of the time in -EAGAIN. Using snd_pcm_readi with Onboard or USB capture device returns positive values only.

[arkq]

Hi, sorry for such a late response, I've been really busy lately...

It seems, that this issue is caused by the MPD ALSA input plugin implementation. I've reproduced this issue, however it seems that the bluealsa_poll_revents() function is not called at all - and it HAS TO be! Not calling this function (essentially snd_pcm_poll_descriptors_revents()) might cause the effect we can see - poll will not block any more.

Unfortunately I find the alsa documentation ambiguous on whether snd_pcm_poll_descriptors_revents() is meant to be mandatory so it is arguable whether this is a bug in bluealsa or mpd.

If one is using poll/select in the code, then the call to the snd_pcm_poll_descriptors_revents() is mandatory. It might work with other ALSA input devices, because it is more likely, that other input devices do not perform anything fancy inside the descriptors_revents() callback - and bluealsa does...

EDIT:
I've reproduced this bug with the MPD v0.19.21 - I was not able to compile current master snapshot due to this bug.

[arkq]

Issue moved to #174