Dmix supported?

[Nephiel]

I got bluealsa running, but it can only play audio from a single application at a time. The rest of the apps complain that the device is busy. Does bluez-alsa support the dmix plugin?

[arkq]

Unfortunately not. Dmix requires hardware PCM (hw). It is hardcoded in the plugin. Once, I've tried to tinker a little bit with the dmix code, however without any promising results. Anyway, I will try to make it work... someday :)

[hvhaugwitz]

Is there any progress with this issue?

[arkq]

Unfortunately, it's not as easy as I previously thought. Making a patch for dmix plugin might be impossible after all (it uses internal timer from audio card).

There is no roadmap for bluez-alsa, however this issue might be on my working bench in a month or two. I have to finish my struggle with the HFP support. So, stay tuned :).

[keyoffecka]

Just a thought about the dmix support. I think it's highly desirable to be able to use bluetooth headphones as normal headphones but without being physically connected to a computer. That is what makes bluetooth devices so attractive. But if they work worse (OK, significantly worse :-) ) or cannot be used the same way, then it just makes no sense.

One, I believe, pretty common case is using bluetooth headphones in meetings. Skype works only with PA, that was one of the reasons (among others) why many people were looking for alternative conferencing software like ZoomUs, TeamViewer, Google Hangouts and others. Google Hangouts themselves do not depend on a sound subsystem. You just need to use your favourite browser which doesn't need PA. Chromium was a solution for me, I built it without PA support and it worked (not fine, but it worked). Unfortunately Chromium starts several processes and this is where dmix becomes very important. It's even worse, because, as far as I understand, even though you start only one Google Hangout session, Chromium starts several processes where it plays sound and without dmix we've done. Randomly you may hear ring sounds and do not hear incoming voice or vice versa depending on what process gains a sound device first.

This works with PA, so BluezAlsa just cannot be an alternative solution here. To my mind, it may be crucial if there is a goal to make BluezAlsa a competitive software, a good alternative to PA.

I wish could help, but I am just a Java software developer. Not sure how I could be useful here, but if you think I could help, please let me know.

[arkq]

Hi @keyoffecka,

You are right, that dmix-like support is required for this project to be an alternative for PA.

After some investigation, I know that this mixer functionality has to be incorporated in the bluealsa code (not in the ALSA PCM plug-in). However, it is rather hard to develop few things simultaneously. Right now, I'm focused on playback as it is. When the playback functionality will be good enough (e.g. mSBC support will be merged in to the master branch), I will try to make parallel playback possible.

If someone wants to help, there is a short overview how I think this feature should be implemented:

It is required to make some middle layer between PCM FIFO and (source) IO thread. This layer has to read PCM samples from multiple FIFOs and mix them together, than feed it into the IO thread via e.g. internal PIPE. One might also look at the dmix code (in the ALSA repository) and see how it is implemented (mixing algorithm). Of course some other design might be good as well.

[bodiroga]

+1, would love to get this implemented someday!

Many thanks for your hard work @arkq, keep up with the good job!

[tfontoura]

+1 for dmix

[drumfreak]

+1000 for dmix... how do we combine multiple bluetooth speakers to play at the same time? I have searched high and low, and jackd is my next attempt.

[repk]

Here is a workaround for dmix.

How it works

The idea here is to use the snd-aloop module. This is a simple alsa module that creates a card with 2 hw devices, what goes in one device goes out the other. Because those are HW devices they can be slaves of a dmix pluging.

So the main idea is to do the following chain:
-> resample -> dmix -> Loopback,0 | snd-aloop kernel pipe | Loopback,1 -> alsaloop -> bluealsa ->

You need alsaloop that will polls Loopback,1 and write everything to bluealsa PCM. It's part of alsa-utils.

How to configure it

First load snd-aloop module
$ modprobe snd-aloop

Now with "aplay -l" you should see one new card called "Loopback" mine is card number 1.

Create the following ~/.asoundrc

$ cat ~/.asoundrc << EOF
pcm.!bluetooth {
        type plug
        slave.pcm {
                type bluealsa
                interface "hci0"
                device "AA:AA:AA:AA:AA:AA"
                profile "a2dp"
        }
}

defaults.pcm.card 1
defaults.pcm.device 0
EOF

With defaults.pcm.card being the Loopback card number.

I have taken a brief look at bluealsa. But, if I am correct here, bluealsa PCM's io_thread() seems to transfer frames by period_size chunk no matter what size has been transfered with snd_pcm_write*() functions. This is a problem with alsaloop if we want to have reasonable latency. To fix that you have to apply the following patch, and rebuild bluealsa (this is a quick kludge that has not been tested enough):

diff --git a/src/asound/bluealsa-pcm.c b/src/asound/bluealsa-pcm.c
index d12bb64..66486bf 100644
--- a/src/asound/bluealsa-pcm.c
+++ b/src/asound/bluealsa-pcm.c
@@ -139,7 +139,7 @@ static void *io_thread(void *arg) {
                snd_pcm_uframes_t io_buffer_size = io->buffer_size;
                snd_pcm_uframes_t io_hw_ptr = pcm->io_hw_ptr;
                snd_pcm_uframes_t io_hw_boundary = pcm->io_hw_boundary;
-               snd_pcm_uframes_t frames = io->period_size;
+               snd_pcm_uframes_t frames = io->appl_ptr - io_hw_ptr;
                char *buffer = areas->addr + (areas->first + areas->step * io_ptr) / 8;
                char *head = buffer;
                ssize_t ret;

Now run
alsaloop -C "hw:Loopback,1,0" -P "bluetooth" -t 50000
It should run forever, so you can daemonized alsaloop by adding -d argument to the previous command.

And now you should be able to play multiple streams through bluealsa.

The downsides are that this adds some extra latency and cpu consumption.

Keep in mind that I have only tested this very lightly, so you should expect some issues.

Some Random questions

I have some questions for @arkq.

Is there any reason that bluealsa is an alsa PCM io plugin besides being a deamon that polls a Loopback device for reading directly ?

Am I right saying that io_thread() forwards the io_ptr by period_size chunk no matter how snd_pcm_write*() is used ?

If so, can we fix it with a transfer() callback to synchronize the io_thread() each time snd_pcm_write*() is called ?

Thanks

[drumfreak]

Thank you!! This is what I was looking for. I’ll test it out!

[drumfreak]

@repk there was a code change since your patch, I'm not sure how this has any affect or not, but here's an updated diff:

diff --git a/src/asound/bluealsa-pcm.c b/src/asound/bluealsa-pcm.c
index d12bb64..7bbd789 100644
--- a/src/asound/bluealsa-pcm.c
+++ b/src/asound/bluealsa-pcm.c
@@ -139,7 +139,8 @@ static void *io_thread(void *arg) {
                snd_pcm_uframes_t io_buffer_size = io->buffer_size;
                snd_pcm_uframes_t io_hw_ptr = pcm->io_hw_ptr;
                snd_pcm_uframes_t io_hw_boundary = pcm->io_hw_boundary;
-               snd_pcm_uframes_t frames = io->period_size;
+               /* snd_pcm_uframes_t frames = io->period_size;*/
+               snd_pcm_uframes_t frames = io->appl_ptr - io_hw_ptr;
                char *buffer = areas->addr + (areas->first + areas->step * io_ptr) / 8;
                char *head = buffer;
                ssize_t ret;

As far as this goes, yes, I was able to get audio through alsaloop but it did have static.

@arkq - Thank you for this project.

My questions are:

1. What is bluealsa_aplay and why do some examples like the Volumio discussions launch this to run in the background? Am I suppose to use it for something? Does it mean anything in the alsa configurations? Is it possible to send audio TO these processes from alsa using a pcm plug, and why is it even needed when playing through alsa works without bluealsa_aplay running? --help shows nothing, there's no documentation, and I could only assume it's a wrapper for alsa's aplay? What is it for, what can we use it for?

2. In defining dmix PCM's, what does it take to get bluealsa working? Is it possible to use Loopback and send the music streams to the Loopback, then using a 'multi' or 'route' alsa plugin to send to multipe?

I am also trying to do this on on a headless raspberry pi with Stretch, but also at the same time, I am building a newer implementation of Bluealsa Bluetooth for Volumio that can route to mutiple groups of speakers.

3. How can I group bluetooth speakers to route from one input PCM?

Edit -- I am going to look at MPD or PULSE or some sort of other route for sending to groups of speakers, it seams like MPD is stock on Volumio so... since BlueAlsa is providing a PCM I can setup in ALSA, I'll head that route. The last I tried, bluealsa PCM is not compatible with DMIX, I wish it were, so I hope I could find a way to route it through Alsa without having to go to Jackd for other sounds not played through MPD.

Thanks!

[arkq]

@repk

Is there any reason that bluealsa is an alsa PCM io plugin besides being a deamon that polls a Loopback device for reading directly?

Hmm, I've based this design by following examples found in the alsa-plugins repository. I had no idea, that there is a loopback device for ALSA. I will have to read a little bit about this :) Thx for the tip.

Am I right saying that io_thread() forwards the io_ptr by period_size chunk no matter how snd_pcm_write*() is used ?

Yes, that's right because (as far as I know) transferring less then period_size does not make any sense (from the point of view of PCM ring buffer). I might be mistaken, though.

If so, can we fix it with a transfer() callback to synchronize the io_thread() each time snd_pcm_write*() is called ?

At first I was using transfer() callback, however at some point I was forced to write a separate thread for transferring data. The reason for this was that writing data to bluealsa PCM PIPE blocks - and transfer() callback shall not block. But right now (my knowledge abut ALSA has grown significantly) I think you might be right, that using transfer() callback for data synchronization might be a good idea.

@drumfreak

What is bluealsa_aplay?

This application is a helper which simplifies BT speaker configuration. It is used to read data from bluealsa server directly and then transfer it to the PCM device (just like aplay reads data from file and writes samples to PCM device). It also adds some extras which are not possible (or require a lot of hacks) with a arecord ... |aplay ... configuration.

In defining dmix PCM's, what does it take to get bluealsa working?

In its simple design, bluealsa should be a PCM device (or devices). Then, you can use any ALSA configuration you want (except dmix, which required PCM to be of hw type).

How can I group bluetooth speakers to route from one input PCM?

I've never done that. You will have to search this topic by yourself. I'm not a .asoundrc wizard :D

[drumfreak]

@arkq thanks! I actually just got this all working wonderfully using MPD. I went down the wrong rabbit hole and chose to try and do this with ALSA, which I may do later, but MPD which is where I'm trying to stream from and to the speaker group just happens to have multiple alsa definition feature so it'll stream out to the speakers. Just define a new one for each speaker, after setting up a basic asound.conf.

I also compiled straight from source without the patch from @repk above, I am unsure what that is about, so straight from source, streaming to multiple speakers from MPD just defining standard bluealsa pcm's.

Thanks again, I'll keep link back when I publish my project to git. It's working great!

[Queequag]

Did anyone succeed in using alsaloop? I got to the point where:

• playback through bluealsa (of course only one PCM stream at a time) without alsaloop works fine
• playback with alsaloop through my integrated laptop soundcard works fine
• playback with alsaloop through bluealsa opens the stream (I can see it in bluealsa logs and hear in my headphones, as they start to hiss a little when stream is opened), but there's no sound (despite mixer being set correctly, and another PCM stream, after stopping alsaloop, being able to play)

My headset is JBL E55BT.

Logs and important snippets (I redacted only address of my headphones):

$ grep -v '^#\|^$' .asoundrc
pcm.jbl
{
        type plug
        slave.pcm
        {
                type bluealsa
                interface hci0
                device XX:XX:XX:XX:XX:XX
                profile "a2dp"
        }
        hint
        {
                show on
                description "JBL E55BT"
        }
}
pcm.!default
{
        type plug
        slave.pcm "jbl"
}

$ aplay -l | grep Loopback
card 10: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
card 10: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]

$ aplay -D hw:10,0 /tmp/piano2.wav
Playing WAVE '/tmp/piano2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

$ alsaloop -C hw:10,1 -P jbl -t 50000
../../../src/asound/../shared/ctl-client.c:105: Connecting to socket: /var/run/bluealsa/hci0
../../../src/asound/../shared/ctl-client.c:219: Getting transport for XX:XX:XX:XX:XX:XX type 1
../../../src/asound/bluealsa-pcm.c:546: Setting constraints
../../../src/asound/bluealsa-pcm.c:294: Initializing HW
../../../src/asound/../shared/ctl-client.c:375: Requesting PCM open for XX:XX:XX:XX:XX:XX
../../../src/asound/bluealsa-pcm.c:317: FIFO buffer size: 4096
../../../src/asound/bluealsa-pcm.c:323: Selected HW buffer: 8 periods x 4800 bytes == 38400 bytes

And from bluealsa program itself:

/usr/bin/bluealsa: ../../src/ctl.c:638: Received new connection: 14
/usr/bin/bluealsa: ../../src/ctl.c:651: New client accepted: 14
/usr/bin/bluealsa: ../../src/ctl.c:675: +-+-
/usr/bin/bluealsa: ../../src/ctl.c:675: +-+-
/usr/bin/bluealsa: ../../src/ctl.c:353: PCM requested for XX:XX:XX:XX:XX:XX type 1 stream 0
/usr/bin/bluealsa: ../../src/transport.c:874: New transport: 20 (MTU: R:672 W:672)
/usr/bin/bluealsa: ../../src/bluez.c:1058: Signal: PropertiesChanged: org.bluez.MediaTransport1: State
/usr/bin/bluealsa: ../../src/transport.c:734: State transition: 0 -> 2
/usr/bin/bluealsa: ../../src/ctl.c:675: +-+-
[New Thread 0x7ffff1b57700 (LWP 3864)]
/usr/bin/bluealsa: ../../src/io.c:386: Starting IO loop: A2DP Source (SBC)
/usr/bin/bluealsa: ../../src/transport.c:122: Created new IO thread: A2DP: A2DP Source

/usr/bin/bluealsa: ../../src/io.c:90: FIFO endpoint has been closed: 15
/usr/bin/bluealsa: ../../src/transport.c:1027: Closing PCM: 15
/usr/bin/bluealsa: ../../src/transport.c:901: Releasing transport: A2DP Source (SBC)
/usr/bin/bluealsa: ../../src/ctl.c:605: Client closed connection: 14
/usr/bin/bluealsa: ../../src/transport.c:929: Closing BT: 20
/usr/bin/bluealsa: ../../src/transport.c:1069: Exiting IO thread
/usr/bin/bluealsa: ../../src/bluez.c:1058: Signal: PropertiesChanged: org.bluez.MediaTransport1: State
/usr/bin/bluealsa: ../../src/transport.c:734: State transition: 2 -> 0
/usr/bin/bluealsa: ../../src/ctl.c:675: +-+-
[Thread 0x7ffff1b57700 (LWP 3864) exited]

Edit: I figured out that playing a WAV file with sample rate 44100 Hz (directly on bluealsa device, without alsaloop) works, but trying to play file with sample rate 48000 Hz hangs.

$ aplay -D jbl piano-44100.wav
../../../src/asound/../shared/ctl-client.c:105: Connecting to socket: /var/run/bluealsa/hci0
../../../src/asound/../shared/ctl-client.c:219: Getting transport for XX:XX:XX:XX:XX:XX type 1
../../../src/asound/bluealsa-pcm.c:547: Setting constraints
Playing WAVE 'piano-44100.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
../../../src/asound/bluealsa-pcm.c:295: Initializing HW
../../../src/asound/../shared/ctl-client.c:375: Requesting PCM open for XX:XX:XX:XX:XX:XX
../../../src/asound/bluealsa-pcm.c:318: FIFO buffer size: 4096
../../../src/asound/bluealsa-pcm.c:324: Selected HW buffer: 6 periods x 16380 bytes <= 98284 bytes
../../../src/asound/bluealsa-pcm.c:339: Initializing SW
../../../src/asound/bluealsa-pcm.c:339: Initializing SW
../../../src/asound/bluealsa-pcm.c:339: Initializing SW
../../../src/asound/bluealsa-pcm.c:355: Prepared
../../../src/asound/bluealsa-pcm.c:339: Initializing SW
../../../src/asound/bluealsa-pcm.c:227: Starting
../../../src/asound/../shared/ctl-client.c:443: Requesting PCM resume for 30:C0:1B:A1:D2:7F
../../../src/asound/bluealsa-pcm.c:122: Starting IO loop

$ aplay -D jbl piano-48000.wav
../../../src/asound/../shared/ctl-client.c:105: Connecting to socket: /var/run/bluealsa/hci0
../../../src/asound/../shared/ctl-client.c:219: Getting transport for XX:XX:XX:XX:XX:XX type 1
../../../src/asound/bluealsa-pcm.c:547: Setting constraints
Playing WAVE 'piano-48000.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
../../../src/asound/bluealsa-pcm.c:295: Initializing HW
../../../src/asound/../shared/ctl-client.c:375: Requesting PCM open for XX:XX:XX:XX:XX:XX
../../../src/asound/bluealsa-pcm.c:318: FIFO buffer size: 4096
../../../src/asound/bluealsa-pcm.c:324: Selected HW buffer: 6 periods x 16380 bytes <= 98284 bytes
../../../src/asound/bluealsa-pcm.c:339: Initializing SW
../../../src/asound/bluealsa-pcm.c:339: Initializing SW
../../../src/asound/bluealsa-pcm.c:355: Prepared

Maybe this is relevant? Unfortunately, adding --rate=44100 to alsaloop didn't help...

Anyone?

[Queequag]

It seems that I was finally able to make dmix work. My setup is far from perfect (I wasn't able to avoid using soundserver, but ESD seems most clean from all of them... and a hack with esdcat is ugly, but there's no support for ESD in Alsa shipped with Debian), but works.

Audio path is: dmix -> loopback -> rate conversion -> esd -> bluealsa. I had to find and compile esound-0.2.41 from sources, as it seems it has been superseded by pulseaudio (which I don't want to use – for many reasons).

One big drawback is the sound latency – trying to watch online videos sucks as audio is out of sync with video. But I'm able to listen to music, at least that's good...

ESD configure command:

./configure --enable-alsa --disable-oss --disable-arts --disable-artstest --enable-local-sound --disable-ipv6

ESD run command:

esd -d jbl -unix -as 10

snd-aloop load line in /etc/modules:

snd-aloop index=10

Alsaloop run command:

alsaloop -C hw:10,1 -P esd -t 150000

And finally .asoundrc:

pcm.jbl
{
        type plug
        slave.pcm
        {
                type bluealsa
                interface hci0
                device XX:XX:XX:XX:XX:XX
                profile "a2dp"
        }

        hint
        {
                show on
                description "JBL E55BT"
        }
}

pcm.esdcat
{
        type file
        file "| /usr/local/bin/esdcat"
        slave.pcm null
        format raw
}

pcm.esdrate
{
        type plug
        slave
        {
                pcm esdcat
                rate 44100
                format S16_LE
                channels 2
        }
}

pcm.esd
{
        type plug
        slave.pcm esdrate
}

pcm.mix
{
        type dmix
        ipc_key 1986
        slave
        {
                pcm "hw:Loopback,0,0"
                period_time 0
                period_size 1024
                buffer_size 8192
                rate 44100
        }

        bindings
        {
                0 0
                1 1
        }
}

pcm.!default
{
        type plug
        slave.pcm mix
}

ctl.!default
{
        type bluealsa
        battery yes
}

[subjectxbj]

+dmix 👍

[subjectxbj]

I tried the alsaloop method. Here are the problem:

• Even using dmix, it still only support a single audio stream to be played:

alsaloop application running:

alsaloop -d -C hw:0,0 -P bluealsa:DEV=00:12:6F:66:98:B7 -t 50000 -S 5

The asound.conf:

pcm.a2dpsink {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:0,1"
        period_time 0
        period_size 1024
        buffer_size 4096
        rate 48000
    }
    bindings {
        0 0
        1 1
    }
}

sound card:

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: ipq8074sndcard [ipq8074_snd_card], device 0: I2S qca-i2s-codec-dai-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: ipq8074sndcard [ipq8074_snd_card], device 1: TDM qca-tdm-codec-dai-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

The test result. when execute the 1st aplay, I can hear sound from BT speaker, but when execute the 2nd aplay, it report error. Looks like 2nd aplay will open the slave device as well.

[alexa] / # aplay -D"a2dpsink" Roland-JV-2080-Spaced-Vox-C3-48000.wav &
[alexa] / # Playing WAVE 'Roland-JV-2080-Spaced-Vox-C3-48000.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

[alexa] / # aplay -D"a2dpsink" Roland-JV-2080-Spaced-Vox-C3-48000.wav
ALSA lib pcm_dmix.c:1156:(snd_pcm_dmix_open) unable to open slave
aplay: main:807: audio open error: Invalid argument

• There is a lot of XRUN using alsaloop. But it is quite smooth if just using bluealsa.

[repk]

aplay is complaining about an "Invalid argument" and not about "Device or resource busy". I am not sure here be maybe it is due to the fact that you do not use a soft resampler (type plug).

Could you try the following :
$ alsaloop -C "hw:Loopback,1,0" -P "bluealsa:DEV=00:12:6F:66:98:B7" -t 50000 -S 5
and

$ aplay -D "sysdefault:CARD=Loopback" Roland-JV-2080-Spaced-Vox-C3-48000.wav&
$ aplay -D "sysdefault:CARD=Loopback" Roland-JV-2080-Spaced-Vox-C3-48000.wav

Also please keep in mind that this solution is a workaround and will introduce huge delay. I personally use "alsaloop -C "hw:Loopback,1,0" -P "bluealsa" -U -l 1000 --period 200 -S 0". It's a bit cpu intensive but it works most of the time ok and make videos viewable.

[Queequag]

Regardless of whether alsaloop alone method works or not (I couldn't get it to work), there's one more problem with this method. When reconnecting headphones (I need to restart bluealsa for that, it's probably a bug in bluealsa) you need to exit applications that have open streams (including web browser).

My working setup (a terrible workaround, but at least usable) is having four terminal windows open on a separate workspace.

1. bluealsa
2. bluetoothctl (because sometimes bluealsa fails to connect and I have to issue connect command)
3. esd.sh script, which contains: sudo nice -19 su queequeg -c 'esd -d jbl -unix -as 10'
4. aloop.sh script, which contains: sudo nice -19 su queequeg -c 'alsaloop -C hw:10,1 -P esd -t 150000' > /dev/null

When connecting headphones:

1. I turn headphones on
2. I run bluealsa and wait for it to connect
3. If it fails to connect, I issue connect command in bluetoothctl
4. I manually reduce volume (it sets volume to maximum) with volume keys on keyboard (which call another script, which calls amixer -D bluealsa sset "JBL E55BT - A2DP" $volume)
5. I run esd.sh script
6. I run aloop.sh script
7. If aloop.sh terminates after a while (a second or so), which happens rarely, but it does, I need to Ctrl-C bluealsa and do steps from 2 to 7 again
8. If I hear a soft hiss for a while after running esd.sh, I know it will work now and I can go to youtube and play my favorite music (movies are unplayable due to the lag)

This is a terrible workaround (compare it to my Android phone, where I just turn headphones on, everything pairs automatically and I can play music almost instantly), but I don't think we have any better alternative for now. dmix support will be the greatest feature to be added to bluealsa.

The good thing is that once it works, it's quite stable. I never experienced disconnects. Sound hiccupped from time to time, but it stopped after wrapping esd and alsaloop in nice.

[Sergey82]

I have nothing to add, just wanted to say thanks to @arkq for the project and to @repk for the solution. Main guidelines + second patch worked. Did not try esd workaround.

[arkq]

Direct integration with dmix is not possible (and probably never will, due to alsa-lib design). However, thanks to @borine, one can use guide available on bluez-alsa wiki: https://github.com/Arkq/bluez-alsa/wiki/Using-bluealsa-with-dmix