Huge delay about bluez-alsa

[arkq]

Delay issue... yeap, definitely sounds like bluealsa :D

The big number you've seen in the PCM plugin (if you're talking about this line) is to counteract delay, not to cause it. There is a lot of "components" which contribute to the final audio delay. However, not all of them are taken into account right now. So, the audio might be out of sync sometimes. However, this delay should not be bigger than 1 second or so. If you are experiencing bigger delay it is caused by a bug in a synchronization logic within bluealsa server and I'm aware of that.... Unfortunately, right now I don't know how to fix it. To be more specific, the problem is with ALSA software PCM API or my understanding how it works (which is more likely). I need a "signal" which will indicate, that the audio will start and then it will be delivered without any delay, until another signal arrives - audio stop. Right now I'm using pcm_io_start callback as a start signal, however, audio is (or it seems it is) delayed afterwards....

device doesn't get exposed in any of the usual ALSA Apis like /proc/asound/cards

Bluealsa ALSA interface is based on a software plugin, which is a part of asound library. The /proc/asound directory is a part of kernel ALSA module.

[dagf2101]

I also have a Huge delay bug right now, more something like 25 seconds.

If I open bluealsa device via my app in c++ (alsa-lib) and set every normal values I would set for regular playback, I get this huge delay.

aplay -D seem to work fine and has only small delay.

Any idea ?

[arkq]

25 secs is kinda odd... How does your PCM configuration look like (what I mean is HW params and SW params)? The delay should be no more than 0.5s (in most cases).

[dagf2101]

I managed to fix it using the init code taken from aplay directly. Now I will find the exact parameter that caused it and let you know. Something must have a wrong default init value compared to the regular playback device. Le 28 avr. 2017 3:42 AM, "Arkadiusz Bokowy" <[email protected]> a écrit : 25 secs is kinda odd... How does your PCM configuration look like (what I mean is HW params and SW params)? The delay should be no more than 0.5s (in most cases). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASUorPzwnt1aa8-DIaBOJiohj-I5GmTtks5r0ZhMgaJpZM4LMX2F> .

[dagf2101]

Ok the missing part was a snd_pcm_hw_params_set_buffer_size_near.
For some reason the sound card was only requiring snd_pcm_hw_params_set_period_size_near to work, no snd_pcm_hw_params_set_buffer_size_near was needed.

[dagf2101]

Hello, I am experiencing the 500-1000ms delay here, I guess it is normal but we need to lower it to something like 250ms.

In my app I am always sending audio so I may not need to support multiple start/stop it this can help.

You have a suggestion where I should start to look in the code ?

[arkq]

@dagf2101, it should be possible, however it depends on your usage case.

First of all make sure that your app uses small PCM buffer (or start threshold is small). You might also reduce BT socket buffer. E.g. add something like this:

size_t size = 2 * t->mtu_write;
setsockopt(t->bt_fd, SOL_SOCKET, SO_SNDBUF, &size, sizeof(size))

in here: https://github.com/Arkq/bluez-alsa/blob/b0a8a136ad073549b038635e26f3caa3608330c8/src/transport.c#L694

I've been testing something similar, however the outcome is not "stable", so this change is not in the master yet.

[arkq]

A LOT of has changed in bluez-alsa project since 2017. It seems that the issue is not as severe as it was. I'm closing this issue then. For a reference please see these comments: #454 (comment) #454 (comment)

If somehow this problem still occurs please create a new issue.