MPV/MPG123 Buffer Stuttering Audio #748
Comments
Very likely it is; although blueez-alsa v3.1.0 is now 4 years old and I do not remember clearly that far back. If you really need an answer to this question then you must search through the issues for Given that you are using a distribution package, your first course of action should be to raise an issue with that distribution so that the package managers are made aware. They can then decide whether to upgrade to a more recent commit, or to produce their own patch to the old code. |
|
You're on the ball too, and I already did search for mpv/mpg123 issues within the github.com bluez-alsa closed/open/etc issues. I pretty much found nothing, along with searching google.com. Regardless, this bug is surely now well documented! :-) And, already did make a post on the non-official Void Linux reddit.com site, posting bluez-alsa version was significantly out-dated. (Didn't get much feedback, if any at all.) However, like I stated, I'm guessing those packaging ran into packaging problems, as I could almost drop-in (compile via Void Linux xbps-src packaging) bluez-alsa-4.0 version (not being the latest version), but ran into further dbus problems possibly not easily/readily resolved. When things get finicky rather than simplified (eg. dbus complexity), people readily loose interest! Go ahead close this bug, and I'll post/follow-up once either I install a recent version, or more likely Void Linux pushes a newer version... if I'm still alive. Guessing, most using bluetooth will likely just use pulseaudio, while those not depending on bluetooth devices will just use ALSA. Usually when packages get stable, or the build scripts become stable, nice just having drop-in and compile/install packages/build scripts. Also makes debugging or falling back to earlier versions from sources extremely easier. |
|
If you have bluez-5.78 then definitively you should go for latest bluez-alsa (master) or at least 4.3.1.
If you have some problems with D-Bus, it's most likely due to incorrect configuration file or config file being not installed at all. The easiest way to go forward is to uninstall distribution version of bluez-alsa, get fresh copy of master, configure it (without any additional options, for start) and install it (just like in the https://github.com/arkq/bluez-alsa/blob/master/INSTALL.md guide). If that will succeed, then you can try to enable some additional features. After installation you should have something like: $ cat /usr/share/dbus-1/system.d/org.bluealsa.conf
<!-- This configuration file specifies the required security policies
for BlueALSA core daemon to work. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- ../system.conf have denied everything, so we just punch some holes -->
<policy user="root">
<allow own_prefix="org.bluealsa"/>
<allow send_destination="org.bluealsa"/>
</policy>
<policy group="audio">
<allow send_destination="org.bluealsa"/>
</policy>
</busconfig>Then make sure that your user is added to the I'm not sure what hardware you are using, but just in case double check that Bluetooth on your system (source, sink, or both) does not perform any scans: $ bluetoothctl show |grep Discovering
Discovering: no |
|
I have most of the previously mentioned already. Void Linux seems to be installing the dbus file into /etc/dbus-1/system.d/bluealsa.conf, where all the other /etc/dbus-1/ files are. (The file is mostly identical except for user root, likely an older bluez-alsa included version.) I just have a really tough time overall understand the entire dbus system, with udev already taxing my thinking skills. Discovery is showing no, user already within the audio group. Think we're getting side-tracked with this stuttering bug, posting software packaging bug(s) atop of the stuttering bug. Granted, good info trying to display how easily upgrading is, just no free time here for playing, why I moved from Gentoo (source-based) Linux distribution to a binary (Void Linux) distribution. When I get a little free time and remember to, I'll retry rolling/compiling another (current stable version) bluez-alsa Void Linux package; for experimenting where the hang-up/delay is with the Void Linux package upgrading of bluez-alsa package, aside from click-n-play users being distracted by preferring pulse-audio, etc. |
Not at all. The case is that since you are using old version of bluez-alsa, I'm not going to investigate the issue unless I'm sure that this bug still appears in the current master branch. This project is privately funded (by my and other active developers, which is @borine, spare time - and time is money) with warranty "rules" defined by MIT license: the software is provided "as is", without warranty of any kind. Anyway, as spare time allows, we are trying to answer questions and fix bugs which are discovered by others. Sometimes, we are even developing new features which are asked by others!
And to be honest that's what we are encouraging regular users to do - use PulseAudio (or PipeWire nowadays). These projects have much more funds, so community around them is a better choice to solve Linux general Bluetooth issues/questions. However, bluez-alsa should work for most cases and for users who have some ALSA knowledge and know what they want - UNIX-like Bluetooth integration with ALSA without sound server (this part is crucial) - bluez-alsa might be a perfect choice. So, saying all this, I'm really encouraging you to try bluez-alsa current master. Prior-knowlege of D-Bus is really not required here. If master branch does not work, simply post logs from |
|
The "configure project with --enable-debug" was another item I needed for proper debugging! I usually only briefly scan "configure --help", probably like most other packagers! |
|
After compiling 4.3.1 release, manually entering a "/usr/share/dbus-1/system.d/org.bluealsa.conf", keep getting an error: $ aplay -D bluealsa:DEV=FF:XX:XX:XX:XX:XX,PROFILE=a2dp,SRV=org.bluealsa /tmp/test.wav $ ~/src/bluez-alsa/bluez-alsa-4.3.1.mine/utils/aplay/bluealsa-aplay -l $ ~/src/bluez-alsa/bluez-alsa-4.3.1.mine/utils/aplay/bluealsa-aplay -L My only guess is, bluez-alsa package needs to be fully installed within /usr, with the original bluez-alsa package being uninstalled, as well as just stopping the service/daemon. After uninstalling the distribution bluez-alsa package, installing (make install), still get an error: $ aplay -D bluealsa:DEV=FF:XX:XX:XX:XX:XX,PROFILE=a2dp /tmp/test.wav src/bluealsa -p a2dp-source |
It seems that the ALSA configuration was not installed properly. Or it was... Check whether you have directory $ ls -l /etc/alsa/conf.d
...
lrwxrwxrwx 1 root root 44 Jan 1 2020 20-bluealsa.conf -> /usr/share/alsa/alsa.conf.d/20-bluealsa.conf |
|
Now that I likely had the tarball manually built and possibly working, decided returning to making the packaging script for Void Linux. Now get the following error: bluealsa -p a2dp-sink /usr/share/dbus-1/system.d/ Tried restarting just dbus service, then restarted the entire computer... Looking at prior bug/issues, recompiled with "--user" configure options: configure_args="--enable-aac --enable-aptx --with-libopenaptx Also presuming the "-p a2dp-sink" executable option is correct, with not needing the "-p a2dp-source" executable option. Worked around that with changing the user to the Void Linux preferred/suppoed "_bluez_alsa" user from version bluez-alsa-3.1.0_1 package. And the bluealsa daemon is now starting. I'm doing so manually via root command line: chpst -u _bluez_alsa:audio bluealsa -p a2dp-sink However, trying to connect using bluetoothctl: [JBL Charge 5]# Failed to connect: org.bluez.Error.Failed br-connection-profile-unavailable Figured I was using the incorrect bluealsa profile (-p a2dp-sink), so switched to a2dp-source. Restarted the bluealsa server: Then bluetoothctl for connecting to the JBL speaker and voila... finally hearing Mozart 01._Allegro.wav! However, when trying to use blu |
|
Just tried the following without using "--devbuffer 120" after powering cycling the JBL bluetooth speakers, subsequently automatically reconnecting to the bluetooth server, and I hear no stuttering after the speakers are reconnected. Or so far with initial testing. mpg123 -a bluealsa:SRV=org.bluealsa,PROFILE=a2dp https://live.ideastream.org/wksu3.128.mp3 So this stuttering bug is likely isolated to older versions such as bluez-alsa-3.1.0_1, the version listed within the current Void Linux distribution package repositories. |
Have been having long time problems with stuttering bluetooth audio after the bluetooth device/client has been power cycled on/off. Upon the bluetooth (automatically) reconnecting to the bluetooth server and playing audio using mpg123/mpv, audio then becomes stuttered/pops.
$ xbps-query -s bluez
[] bluez-5.78_1 Bluetooth tools and daemons
[] bluez-alsa-3.1.0_1 Bluetooth Audio ALSA Backend
[] bluez-deprecated-5.78_1 Bluetooth tools and daemons - deprecated tools
[] libbluetooth-5.78_1 Library to use the Bluez Linux Bluetooth Stack
Having some time for debugging finally after many years and happening upon some debug incantations whereas seemingly little easy debugging instructions (eg. aplay -D bluealsa:SRV=org.bluealsa,DEV=XX:XX:XX:XX:XX:XX,PROFILE=a2dp some.wav, and with mpg123/mpv using "-a"), I found the likely reason(s) for the playback stuttering when using mpv -v:
[ao/alsa] buffersize: 4410 samples
[ao/alsa] period size: 1102 samples
[ao/alsa] device buffer: 4410 samples.
[ao/alsa] using soft-buffer of 22050 samples.
And happened upon a working instance fluke when mpv happened to playback fine or without stuttering:
[ao/alsa] buffersize: 4800 samples
[ao/alsa] period size: 1200 samples
[ao/alsa] device buffer: 4800 samples.
[ao/alsa] using soft-buffer of 24000 samples.
Now setting mpv "--alsa-buffer-time=0 -v" mpv plays with no stutter too!
ao/alsa] buffersize: 16384 samples
[ao/alsa] period size: 4096 samples
[ao/alsa] device buffer: 16384 samples.
[ao/alsa] using soft-buffer of 22050 samples.
Mpg123 was also affect by playback stuttering and popping, and "--devbuffer 30" or "--devbuffer 60" significantly improves playback without stuttering however for intermittent popping and seemingly "--devbuffer 120" seems about right with no apparent popping noises.
So, long story short, is this a known bug fixed within later versions of ALSA Bluez, or likely not fixed? I have already tried compiling a recent version of bluez-alsa Void Linux package, so far 4.0 compiled but encountered subsequent dbus bugs, and likely as to why Void Linux developers elected not upgrading, likely due to incompatibility issues with the current Void operating system and/or possibly fluctuating compile/install routine.
Surprised nobody has written any really good debugging/troubleshooting webpages for Linux bluetooth.
The text was updated successfully, but these errors were encountered: