Description of problem: Bluetooth headset connects just fine, but produces no audio whatsoever. When adjusting the configuration in sound settings, the following message appears in journalctl: gsd-media-keys[2246]: Unable to get default sink When attempting a test with sound in either speaker, the following message appears in journalctl: pipewire[2518]: 'CHECK_PORT(this, direction, port_id)' failed at ../spa/plugins/audiomixer/mixer-dsp.c:618 impl_node_port_set_io() pipewire-media-session[2518]: port 0x5638d7373310: set_io: Invalid argument pipewire[2401]: impl-core 0x55a1fd697710: error -22 for resource 8: port_set_io failed: Invalid argument pipewire[2401]: client-node 0x55a1fd92d7d0: error seq:3636 -22 (port_set_io failed: Invalid argument) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Connect bluetooth headset 2. Run journalctl 3. Adjust configuration or test audio sounds in either speaker. Actual results: No sound Expected results: Sound Additional info:
I see the same issue on Fedora 33 (manually installed pipewire), using version pipewire-0.3.24-4. It is reproducible quite consistently after a suspend/resume cycle. Reconnecting the headset doesn't help, but restarting pipewire ("systemctl --user restart pipewire") usually fixes it.
Having this same problem in Silverblue 34. I'm using Airpods Pro, they connect fine, but no audio comes out of them. I need to go to Bluetooth settings, disconnect and connect them again in order to receive sound.
perhaps related? https://bugzilla.redhat.com/show_bug.cgi?id=1945578
some of you guys said that reconnecting helps, when reconnecting, for me it switches to sbc profile (actually it just drops aac whatsoever)
(In reply to Stefano Cavallari from comment #1) > I see the same issue on Fedora 33 (manually installed pipewire), using > version pipewire-0.3.24-4. > It is reproducible quite consistently after a suspend/resume cycle. > Reconnecting the headset doesn't help, but restarting pipewire ("systemctl > --user restart pipewire") usually fixes it. Restarting pipewire worked for me, thanks! One clue I noticed this go around was that all programs that were open PRIOR to connected headphones could not be heard, but if I opened a new program that wasn't open before after the headphones were connected, I could hear output.
Hi, I can reproduce the same behaviour the caller is describing. In my case it happens after physically switching off a Bluetooth speaker with streams being sent to it and then connecting a Bluetooth headset. There's no audio on the headset even though the stream is correctly being sent to the device according to pavucontrol. There's no activity bar on the output device being shown, either. Logs: pipewire-media-session[955]: 'CHECK_PORT(this, direction, port_id)' failed at ../pipewire/spa/plugins/audiomixer/mixer-dsp.c:618 impl_node_port_set_io() pipewire-media-session[955]: 'CHECK_PORT(this, direction, port_id)' failed at ../pipewire/spa/plugins/audiomixer/mixer-dsp.c:618 impl_node_port_set_io() pipewire-media-session[955]: port 0x562d22dc8cb0: set_io: Invalid argument pipewire-media-session[955]: port 0x562d22dc8d38: set_io: Invalid argument pipewire[954]: impl-core 0x55ae7e3f5290: error -22 for resource 11: port_set_io failed: Invalid argument pipewire[954]: client-node 0x55ae806f1550: error seq:16739 -22 (port_set_io failed: Invalid argument) pipewire[954]: impl-core 0x55ae7e3f5290: error -22 for resource 11: port_set_io failed: Invalid argument pipewire[954]: client-node 0x55ae806f1550: error seq:16740 -22 (port_set_io failed: Invalid argument) Pipewire 0.3.24
Will give 0.3.25 a go, it ships some BT improvements: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/NEWS
Still happening with 0.3.25.
(In reply to Stefano Cavallari from comment #1) > I see the same issue on Fedora 33 (manually installed pipewire), using > version pipewire-0.3.24-4. > It is reproducible quite consistently after a suspend/resume cycle. > Reconnecting the headset doesn't help, but restarting pipewire ("systemctl > --user restart pipewire") usually fixes it. Restarting pipewire gives me a good ol' core dump: apr 16 20:58:41 fedora systemd-coredump[3910]: [🡕] Process 3889 (pipewire-media-) of user 1000 dumped core. Stack trace of thread 3889: #0 0x00007fa4b0f399d5 __GI_raise (libc.so.6 + 0x3d9d5) #1 0x00007fa4b0f228a4 __GI_abort (libc.so.6 + 0x268a4) #2 0x00007fa4af69cdaf interfaces_added (libspa-bluez5.so + 0x33daf) #3 0x00007fa4af69d2ae get_managed_objects_reply (libspa-bluez5.so + 0x342ae) #4 0x00007fa4b10dbbc6 complete_pending_call_and_unlock.lto_priv.0 (libdbus-1.so.3 + 0x14bc6) #5 0x00007fa4b10e0078 dbus_connection_dispatch (libdbus-1.so.3 + 0x19078) #6 0x00007fa4b11d754a dispatch_cb (libspa-dbus.so + 0x154a) #7 0x00007fa4b11e7eeb loop_iterate (libspa-support.so + 0x6eeb) #8 0x00007fa4b11625fb pw_main_loop_run (libpipewire-0.3.so.0 + 0x4a5fb) #9 0x00005651db8a5d48 main (pipewire-media-session + 0xed48) #10 0x00007fa4b0f241e2 __libc_start_main (libc.so.6 + 0x281e2) #11 0x00005651db8a644e _start (pipewire-media-session + 0xf44e) Stack trace of thread 3891: #0 0x00007fa4b0ffde9e epoll_wait (libc.so.6 + 0x101e9e) #1 0x00007fa4b11f1618 impl_pollfd_wait (libspa-support.so + 0x10618) #2 0x00007fa4b11e7e54 loop_iterate (libspa-support.so + 0x6e54) #3 0x00007fa4b1152027 do_loop (libpipewire-0.3.so.0 + 0x3a027) #4 0x00007fa4b0ec13f9 start_thread (libpthread.so.0 + 0x93f9) #5 0x00007fa4b0ffdb53 __clone (libc.so.6 + 0x101b53) Fedora release 33 (Thirty Three) #rpm -qa | grep "bluez\|bluetooth\|pipewire" pipewire0.2-libs-0.2.7-4.fc33.x86_64 gnome-bluetooth-libs-3.34.3-3.fc33.x86_64 gnome-bluetooth-3.34.3-3.fc33.x86_64 bluez-5.56-1.fc33.x86_64 bluez-libs-5.56-1.fc33.x86_64 bluez-obexd-5.56-1.fc33.x86_64 bluez-cups-5.56-1.fc33.x86_64 pipewire-libs-0.3.25-1.fc33.x86_64 pipewire-0.3.25-1.fc33.x86_64 pipewire-gstreamer-0.3.25-1.fc33.x86_64 pipewire-pulseaudio-0.3.25-1.fc33.x86_64 pipewire-utils-0.3.25-1.fc33.x86_64 pipewire-alsa-0.3.25-1.fc33.x86_64
I'm already in the final version of Fedora 34 Silverblue. It's still only working if I select in Sound settings the profile (A2DP Sink, codec SBC). In order to keep this permanent (as everytime I reconnect the headphones it goes back to aac by default), you can edit "/etc/pipewire/media-session.d/bluez-monitor.conf": The line that apppears as "#bluez5.codecs = [ sbc aac ldac aptx aptx_hd ]", change it to "bluez5.codecs = [ sbc ]". After that, restart pipewire with "systemctl --user restart pipewire.service". Now, after you reconnect the bluetooth headphones, it should come up SBC by default :)
FEDORA-2021-03756cf274 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-03756cf274
FEDORA-2021-03756cf274 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-03756cf274` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-03756cf274 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
So I just submitted another bug, but my problem is actually already fixed. Runnign the pw-cli command prompted to install pipewire-utils and another dependency (I missed what it was), but after that I was ok. More details: Connecting a Bluetooth speaker (Logitech UE BOOM3) to Fedora 34 didn't properly playback 100% with Youtube. testing other apps I got it to occasionally work with Audacious, but not luck on VLC. However, it seems fixed after installing the pipewire-utils and their dependencies (sorry I didn't catch the list - I think one other package). I found this when using pw-cli ls to try and debug, and all of the sudden the problem was solved. The pw-cli (pipewire-utils) dependency needed I would guess fixes the issue, but might be useful to include in the standard Fedora 34 unless I somehow missed it upgrading from 33 to 34.
(In reply to opnsrctechtrn from comment #13) > So I just submitted another bug, but my problem is actually already fixed. > Runnign the pw-cli command prompted to install pipewire-utils and another > dependency (I missed what it was), but after that I was ok. > > More details: > Connecting a Bluetooth speaker (Logitech UE BOOM3) to Fedora 34 didn't > properly playback 100% with Youtube. testing other apps I got it to > occasionally work with Audacious, but not luck on VLC. > > However, it seems fixed after installing the pipewire-utils and their > dependencies (sorry I didn't catch the list - I think one other package). I > found this when using pw-cli ls to try and debug, and all of the sudden the > problem was solved. > > The pw-cli (pipewire-utils) dependency needed I would guess fixes the issue, > but might be useful to include in the standard Fedora 34 unless I somehow > missed it upgrading from 33 to 34. Sorry to note i am on Fedora 34 Workstation, not silver blue. No manual restart of pipewire was done, but could have been during the install. I just know that it's been problem free for a few hours and a couple of reboots - seems more stable than Fedora 33 honestly - the connection and so on starts right up.
FEDORA-2021-03756cf274 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Hi, I have 0.3.26-4 version installed and still reproduce the same issue: $ rpm -qa | grep pipewire- pipewire-0.3.26-4.fc34.x86_64 ... pipewire-media-session[2214]: port 0x55a8ef8c9b70: set_io: Invalid argument pipewire-media-session[2214]: port 0x55a8ef8c9bf8: set_io: Invalid argument pipewire[2208]: impl-core 0x5641e39148f0: error -22 for resource 15: port_set_io failed: Invalid argument pipewire[2208]: client-node 0x5641e3b3f4c0: error seq:10243 -22 (port_set_io failed: Invalid argument) pipewire[2208]: impl-core 0x5641e39148f0: error -22 for resource 15: port_set_io failed: Invalid argument pipewire[2208]: client-node 0x5641e3b3f4c0: error seq:10244 -22 (port_set_io failed: Invalid argument)