Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PipeWire: Bluetooth Support Status Update

collabora.com

Post reply on HN
Print view View original

81–90 of 101 posts

Re: PipeWire: Bluetooth Support Status Update

#81

Post by torginus »

christophilus wrote: post #27
spacemanmatt wrote: post #15

Since I switched to pipewire I've had the best Linux audio end-user experience with BlueTooth devices, ever.

I have found my vanilla Fedora install to have a better Bluetooth experience than my Mac did. That’s quite a feat.

In my experience, Bluetooth on the Mac is not great (especially if you aren't willing to exist solely in Apple-land).

Windows, with the right BT card/drivers (usually anything Intel) is the best, with Linux a close second, but some of the other vendors have very sketchy Bluetooth support.

Re: PipeWire: Bluetooth Support Status Update

#82

Post by throwaway82652 »

snvzz wrote: post #64
throwaway82652 wrote: post #55

Earlier quoted context omitted.

>Can someone explain to me what pipewire's goal is? to be a better pulseaudio? Yes, and also the goal is to support video in addition to audio. >if so, in what way is it trying to be better? Well in addition to supporting video, it also supports jack clients without needing to run a separate server. There are a few other things like better security policies, but those are the major ones. >also, how's the codebase qua…

>Pulseaudio's code is fine No, it isn't. Pulseaudio is based on a push model, which is completely broken. Pipewire uses a pull model, like BeOS/Haiku and jack. It is suitable for pro audio, which pulseaudio could never hope to support.

>No, it isn't. Pulseaudio is based on a push model, which is completely broken.

These two statements are both very wrong. The push model is absolutely not broken, it's actually better for media players, networked sound and other non-pro-audio applications because it uses less power and can do more efficient buffering strategies. You're right that it's not good for pro-audio and other latency-sensitive applications, but pulseaudio was not designed to do that on purpose because jack already filled that niche. The pull model has to wake up every application every quantum on a strict deadline to do processing. In some situations pulseaudio should still be able to provide the smallest power usage compared to pipewire, even just continuing to use the pulseaudio API to do buffering on top of pipewire should be a benefit for applications that want it.

Even if it was broken (it's not), that would be an aspect of the design, not the code itself. The code itself is structured in mostly the same way as pipewire.

Re: PipeWire: Bluetooth Support Status Update

#83

Post by stragies »

ncmncm wrote: post #49
waplot wrote: post #43

Can someone explain to me what pipewire's goal is? to be a better pulseaudio? if so, in what way is it trying to be better? also, how's the codebase quality? from what i heard, pulse's codebase is a mess, so if it can improve in that sense, i guess that's a win (?) why does it do video? is trying to do media capture like OBS or be a compositor like wayland? if so why bother? those solutions exist already... maybe it…

Pipewire is driven by the need to handle synchronized media from multiple sources delivered to multiple sinks in real time with minimal, constant latency. The reference problem is cars, which often have a dash cam, back-up cam, dash video display, instrument panel display, bluetooth phone connection, radio receiver, satellite receiver, audio amplifier, dash microphone, backseat video display with audio, seatbelt alar…

So, a glue layer for

* (LAN-)devices, most a source/sink/control for various Audio/Video streams.

* Those devices (can) share/use any HW (Microphones/Speakers/V4L-devices) available

* programs producing/consuming sound/video, to be "exported" as individual sinks/sources

* Eventing support to dynamically change media routing

Your stated "reference problem" (Car AV) is (imho) not the most user-"relatable" scenario (after all, who has "hackable car"), a more common scenario I'd see:

* In several of the rooms of the dwelling there are

* Devices large/small with several connection types

  * LAN (PCs, TVs, AV-HW, MediaPlayers, ...) with protocols including e.g.

    * Well-known programs (VLC, KODI) with their "own" protocol

    * UPNP/DLNA/AirPlay/Miracast/PulseAudio/RTSP/...

    * SIP/WebRTC devices/clients (Doorbells, VoIP-Phones, VideoConf)

    * Devices with Vendor-specific protocols. e.g LG WebOS

  * USB connection to one of the above (WebCam, Android-devices, phones)

  * Wifi-P2P (Some of LAN devices have this too, for e.g. screencasting)

  * Bluetooth BTLE/Classic (devices can be stationary/mobile/transient)
I would like to enable these usecases: * Send [emulated] [second] screen from PC to any Display surface

* View any desktop/UI/program/device on any other display surface

* Control all the above from PCs/Phones/Tablets, or Events (Doorbell -> Camera PiP @TV)

* Route any audio/video source to my speech-recognition/video-conf/VoIP Software

* Use Android device [connected to USB[ of another Device]] as 8+ devices: Camera F/R, Screen I/O, Audio I/O Headphone/Speaker/BT Microphone/App-Output

* Use "hook"-scripts for eventing/device control (TV might need some command to switch to HDMI3)

I realize most of the above can be probably be done using some GST/FFMPEG glue scripts/code and some systemd dependencies, but I'm haven't found quickly relatable examples of: * "Run this command/config to add an ffpmeg commandline as virtual camera"

* "Use this config to represent your TV as another display output device"

* "Run this command On DevA to launch a GUI-binary on DevB, and make this "stream" available as VideoSource in Browser@DevA"

* "Use the Webcam on DevA, bluetooth headsets via DevB for input, TV1 as VideoOutput, AudioOut on AVR, runnings VideoConf on DevC"

* "Do this to implement access-control" (Bob can see Input "foo", but Alice can't)

Re: PipeWire: Bluetooth Support Status Update

#84

Post by ncmncm »

stragies wrote: post #83
ncmncm wrote: post #49

Earlier quoted context omitted.

Pipewire is driven by the need to handle synchronized media from multiple sources delivered to multiple sinks in real time with minimal, constant latency. The reference problem is cars, which often have a dash cam, back-up cam, dash video display, instrument panel display, bluetooth phone connection, radio receiver, satellite receiver, audio amplifier, dash microphone, backseat video display with audio, seatbelt alar…

So, a glue layer for * (LAN-)devices, most a source/sink/control for various Audio/Video streams. * Those devices (can) share/use any HW (Microphones/Speakers/V4L-devices) available * programs producing/consuming sound/video, to be "exported" as individual sinks/sources * Eventing support to dynamically change media routing Your stated "reference problem" (Car AV) is (imho) not the most user-"relatable" scenario (aft…

Cars are a hard but representative problem, with intrinsic advantages:

  - Multiple data flows
  - Limited available attention
  - Need for "just works"
  - Need for trivial override
  - Funding available
  - Strong demand for solution

Re: PipeWire: Bluetooth Support Status Update

#85

Post by taifleh »

emilyst wrote: post #66
snvzz wrote: post #61

Earlier quoted context omitted.

I used pavucontrol to simply tell it to not do it. Once is enough. In the sound cards list, just set to disabled.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound. For a headless system, it's useless.

you can actually use pavucontrol for remote PA servers that have native-protocol-tcp running

$ PULSE_SERVER=192.168.1.21 pavucontrol

Re: PipeWire: Bluetooth Support Status Update

#86

Post by stavros »

WhatIsDukkha wrote: post #63
stavros wrote: post #57

Earlier quoted context omitted.

How did you switch? I'd be interested in trying this on Ubuntu.

Should be pretty close - https://wiki.debian.org/PipeWire

Apparently this is already running on my Ubuntu 21.10, I wonder if they switched over from the default. I've had no problems with BT at all, it just works. I wonder if that's why.

Re: PipeWire: Bluetooth Support Status Update

#87

Post by oynqr »

hsbauauvhabzb wrote: post #71

I’m really interested in pipewire for use with AirPods, I really want to be able to leverage wireless comms for voice. Does the current state support AirPods well? Sorry if that’s obvious but I’m under the impression the AirPod codecs are slightly different to non apple headphones.

Airpods should work fine, probably defaulting to AAC.

Re: PipeWire: Bluetooth Support Status Update

#88

Post by emilyst »

kam wrote: post #67
emilyst wrote: post #66

Earlier quoted context omitted.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound. For a headless system, it's useless.

`pactl` is the command line version

Also tried, also useless. The program producing the sound is being run by another user.

Re: PipeWire: Bluetooth Support Status Update

#89

Post by emilyst »

snvzz wrote: post #69
emilyst wrote: post #66

Earlier quoted context omitted.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound. For a headless system, it's useless.

>For a headless system, it's useless. DualSense is a game controller. In this context, headless is unlikely.

Depends on how you define headless, but the fact is, I'm rarely logged into it, and there's no mouse nor keyboard connected, nor any X server running.

Re: PipeWire: Bluetooth Support Status Update

#90

Post by noobermin »

kaba0 wrote: post #79
noobermin wrote: post #70

Earlier quoted context omitted.

Going to be very real, I do not really have more than an inkling of the "world" PW inherits or whatever, but this sounds like "trust us, this time it's okay." I might need a little more convincing this isn't just another attempt to recreate a "universal framework that covers everyone's use cases." (I won't like the obvious reference)

Nice of you to dismiss people’s (mostly a single one’s) free work.

I am not dismissing anyone's work. By this logic, the pipewire folks are dismissing ALSA and pulseaudio's work, which is equally absurd.
Post reply on HN