Accepted yet?

[flatsiedatsie]

Have the awesome audio-mixing capabilities of this fork been accepted into the main BlueAlsa program yet? I tried to figure it out by looking at the pull requests there, but could not figure it out.

[borine]

The multi-client code has not been submitted as a PR yet. There was an earlier attempt many months (maybe years?) ago, but that had too many problems to I cancelled the request. I now use A2DP playback mixing with aptX regularly, so I know that is reasonably stable. but SCO mixing is largely untested and so is capture snooping. I am not planning to prepare a PR in the short-term, but hopefully it will happen one day. If you could try out either the multi-client branch or the main branch and give feedback here on which applications you have tried, which profiles and codecs etc, and any problems found then that might help speed up the initial testing and refinement so that readiness for submitting upstream might happen sooner.

[flatsiedatsie]

I haven't had any problems with it, using multiple bluetooth speakers. I don't know which codeds those used, but they all worked just fine.

[flatsiedatsie]

It seems that in the future the Raspberry Pi team will be forcing the use of audio servers:
raspberrypi/linux#4543 (comment)

[borine]

Raspberry Pi team will be forcing the use of audio server

I don't follow your reasoning. I think they are saying that the new firmware no longer performs mixing of IEC958 frames, so you cannot have multiple clients sending hdmi AC3 passthrough; and dmix cannot mix IEC958 either. But I don't see where they say that PCM streams are affected. I don't have a Pi4 to test with, but I assume that

application->[plug]->dmix->hw

should work with multiple clients sending PCM (ie S16_LE) and then the driver encodes the mixed PCM into IEC958? I think that how it works with other cards with hdmi or s/pdif outputs.

[borine]

Hmm, looking at the vc4-hdmi driver, it looks like it only accepts SND_PCM_FORMAT_IEC958_SUBFRAME data, so I was wrong about PCM. The RPi hdmi card requires plug to convert from linear PCM formats to IEC958 format, and of course dmix cannot sit in front of plug.

So in fact the application opening the hdmi device always has exclusive access to it, and that is why you would need a proxy such as pulseaudio or pipewire to mix streams from different applications. Unfortunately I don't have an HDMI device to test how other cards deal with this, so perhaps my understanding of HDMI has always been wrong (athough I'm pretty sure I have used dmix:hdmi or dmix:iec958 as device names successfully in the past, but never tried with RPi).

[flatsiedatsie]

I have no idea what you're saying :-) But it sounds in line with what I read.

Does this mean that the multi-client idea becomes less likely to work in future Raspberry OS versions? Will a pipewire or pulse audio solution become inevitable?

@arkq

[arkq]

@flatsiedatsie bluez-alsa is somehow not effected by that. It is a standalone solution for bridging Bluetooth and ALSA. Upstream version lacks mixing capability, but @borine fork has it. If you are searching for a solution which allows ALSA applications to stream audio to Bluetooth, this will still work, I think.

[borine]

For users that require HDMI output from multiple processes on the RPi with vc4-kms-v3d driver (ie certainly RPi4 and zero 2, possibly earlier models too) then pulseaudio or pipewire now seem essential, so it would make no sense for them to use bluealsa.

For users with dedicated sound cards on a RPi (like me) this change makes no difference, and I will continue to use my own fork of bluealsa, so my mixing code will be maintained.

One downside for bluealsa is with bluealsa-aplay which requires dmix to support multiple client connections. I have no idea how common it is for bluealsa-aplay to be used with HDMI outputs on a RPi, but I suspect it is rare.

BTW I've looked at the intel HDA HDMI driver code, and that does support linear PCM formats in addition to the digital IEC958 format, so it seems my original understanding was correct and it is the RPi driver which is really letting the RPi down here.

[flatsiedatsie]

@arkq Yes, I'm already using it, to great delight. I was just wondering whether this news hampers any future development of BlueAlsa towards such a built-in mixing direction.

so it would make no sense for them to use bluealsa.

I don't quite understand. I have parallel audio processes (music + voice control command response). Sometimes I want this to be played over the device speakers (hdmi), but sometimes when I have people over I want to switch to a louder bluetooth speaker. Would using vc4-kms-v3d + sound server mean it is no longer possible to route audio to (Blue)alsa as an output?

[borine]

so it would make no sense for them to use bluealsa.

I mean, if the system is running pulseaudio or pipewire, then the best way to use Bluetooth audio is to use the respective Bluetooth modules of those services. It is technically feasible to use bluealsa for bluetooth and also have pulseaudio or pipewire running at the same time, but the sheer waste of system resources and compromises in function and performance of the whole audio system make it most unlikely that it would ever be a "sensible" choice.

If that kind of frankenstein system interests you, take a look at the bluealsa wiki article https://github.com/Arkq/bluez-alsa/wiki/PulseAudio-integration which documents some experiments I did on this subject,

[flatsiedatsie]

Ah, I see. Thank you. I did not know pulseaudio came with its own options for bluetooth audio output.