Raised the issue.
Now I have a strange stuttering video issue. Any chance the modifications we did regarding alsa caused it?
Not if you are using your default audio output (?HAT) and no BT devices are connected.
Can you give him bluealsa-aplay -l? (with the buds connected, I guess).
Sure, but donāt know how to rebuild with debug.
No. We would have to do that. bluealsa-aplay will work anyway.
Iāve connected the buds again to provide the blealsa-aplay -l
Afterwards, Iāve chosen Galaxy Buds+ from the Audio settings just to try one more time and it worked.
Ran the test and it works also:
osmc@osmc:~$ speaker-test -D galaxybuds -c 2 -p 1 -t wav -l 3
speaker-test 1.1.8
Playback device is galaxybuds
Stream parameters are 48000Hz, S16_LE, 2 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 4194304
Period size range from 480 to 4096
Requested period time 1 us
Periods = 4
was set period_size = 480
was set buffer_size = 1920
0 - Front Left
1 - Front Right
Time per period = 2.982257
0 - Front Left
1 - Front Right
Time per period = 3.009906
0 - Front Left
1 - Front Right
Time per period = 3.009312
Is there any chance your phone is grabbing the connection??
No, Iāve made sure the only phone in the house that is paired up with the buds has itās bluetooth turned off.
Plus, it can only be connected with one device, so I would not be able to connect to it if some other device grabbed the connection.
And after a reboot, the stuttering is gone, but I donāt have the sound on the buds anymoreā¦
osmc@osmc:~$ speaker-test -D galaxybuds -c 2 -p 1 -t wav -l 3
speaker-test 1.1.8
Playback device is galaxybuds
Stream parameters are 48000Hz, S16_LE, 2 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 4194304
Period size range from 480 to 4096
Requested period time 1 us
Periods = 4
Unable to set hw params for playback: Device or resource busy
Setting of hwparams failed: Device or resource busy
Iāve managed to figure it out.
So, if you get the buds out of their case and then connect them with rpi it wonāt work, but if I leave them in the case, enable bluetooth and then get them out, they will automatically connect to rpi and work.
Tried it 3 times and this is definitely the way to make them work.
They need to connect automatically, otherwise they wonāt work.
Interesting. But the other buds can be connected from either side?
Iāll try this now. First need to add them to the .asoundrc file.
Should I use the same logic as fir buds, e.g.:
pcm.enacfirefuture {
type plug
slave.pcm {
type bluealsa
device "00:00:90:B0:EF:77"
profile "a2dp"
}
hint { show on description "ENACFIRE Future"}
}
Yes, that should do it. Arkq is saying the automatic āuse the last connected deviceā should work just as well. Weāll do some more testing here.
You can revert to the way we do it now (and in the future) with
cd /etc/alsa/conf.d
sudo ln -s /usr/share/alsa/alsa.conf.d/21-bt-audio-osmc.conf 21-bt-audio-osmc.conf
and delete/rename .asoundrc. Iād love to know whether that works with the connect method you have found.
Tried it with ENACFIRE and additional entry in .asoundrc
Works both ways with them, automatic connection or manual.
Iāll revert back to the current way and test both headsets.
1 Like
Reverted back per your instructions.
I can connect to buds using the automatic way, it still doesnāt work if I connect manually.
Enacfire works fine either way.
The problem I have is that after I start watching something, video starts stuttering in less then a minute. Videos that have been playing well before are behaving like this.
Reboot didnāt help either.
If I get that, pausing and restarting the video fixes it.
It looks like the latest update resolved the issue.
Video playback is working now, no problems.
@grahamh thanks for all the help, this topic can be closed now unless you need me to do more testing.
1 Like