Re: [pulseaudio-discuss] Pulseaudio system wide mode design
On Thu, 2019-10-17 at 12:56 +0200, Pali Rohár wrote: > Hello, > > there are repeated problems related to fact that pulseaudio is running > under user session and every user spawns own pulseaudio process. > > Only one process can have exclusive access to specific ALSA card. > > Also only one process can create connection to bluetooth A2DP device. > > Looking at pulseaudio design, which should abstract audio device and > sound cards which are "shared" resources, it looks for me that it is > something which should be managed by (central) point. And not by many, > for every user one. > > So what are the main problems which prevent usage of pulseaudio in > system-wide mode. When in system would be running only instance of > pulseaudio and all users would connect to that one instance? > > I know only problem related to security, that any process which has > access to pulseaudio socket can control audio settings of all other > processes connected to pulseaudio. And also can load or unload any > pulseaudio module. > > But this can be easily fixable by implementing access control, e.g. > users in pulseaudio-admin group would be able to control everything like > before (including module loading) and users in pulseaudio-access group > would be able to see and modify only streams which they created and > would not be able to see other strings (or modify other properties). > And also would not be able to load/unload modules. > > Is there anything else which prevents moving pulseaudio into proper > system wide mode? You say that "this can be easily [fixed] by implementing access control". I would agree, except with the "easily" part. There was an effort to implement access control for supporting sandboxed applications (primarily Flatpak), but that stalled due to lack of reviewers... Wim Taymans was the last one working on it, but he's now building PipeWire (I don't know if there's a cause and effect going on here...). Implementing an access control system isn't that simple. A comment on some of your specific suggestions: if users can only control the streams they created, that sounds very limiting. Users should be able to configure quite freely the hardware that is assigned to the seat that the user is logged in to (surely they should at least be able to control the volume!). And completely disabling module loading isn't ideal either: users should be able to load null sinks or network sinks as they wish, for example. There is need for per-user settings, which I think the system server could very well manage, but all that stuff needs implementation work. I personally think you're probably right that a system daemon would be better than a user daemon, but I have the impression that I'm in the minority here. PipeWire chose the per-user model too, and when I suggested that maybe the system daemon model would be better for the same reasons you mentioned, that didn't get much support. People seem to think that duplicating user management in the audio server when the operating system already does it is ugly and complicated. Improving the system mode in PulseAudio would be welcome (for example, it would be easy to make hotplugging USB and bluetooth cards work even with --disable-module-loading), but if you try to change the design in major ways by adding an access control system, there are no guarantees that the effort will get any further than the last time that was attempted. Maybe it would be better to advocate the system mode to the PipeWire project? It's supposed to some day replace PulseAudio anyway, and it already has a lot of the access control infrastructure, since secure access for sandboxed applications is built in from the beginning. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
Regression would mean that some devices can't connect anymore : this won't happen if a workaround is provided, and this workaround won't be used often. Most (99% ?) of the devices will work correctly with my patch (many of them in XQ mode, and some in legacy mode because they will fall back to legacy bitpool during negociation) The remaining (1% ?) : will need a simple boolean swicth in one of the PA config files to restrict negociation to legacy bitpool (a module option ? or daemon.conf ?). I think it's really "simple", efficient, and not dependent of any upcoming Bluez feature. "The complex solution is always the best until one find a simpler one" Just my 2 cents JP 17.10.2019, 15:14, "Pali Rohár" : > On Thursday 17 October 2019 16:11:26 Tanu Kaskinen wrote: >> On Thu, 2019-10-17 at 14:55 +0200, Pali Rohár wrote: >> > On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote: >> > > On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote: >> > > > Automatic SBC profile is not going to be changed. It is there to >> support >> > > > all devices without any tweaks. ValdikSS already did more tests and >> > > > there are devices which do not work with higher SBC bitpool. So >> > > > increasing max value of bitpool in Automatic SBC profile would lead to >> > > > broken support for these devices and therefore regressions. >> > > > >> > > > As Automatic SBC profile is the only one available for systems where >> > > > codec switching is not supported, it would mean complete regression as >> > > > these devices completely stops working on those systems. >> > > > >> > > > Upgrading either pulseaudio or bluez must not lead to problem that >> some >> > > > bluetooth devices stop working (if they worked before upgrade). >> > > > >> > > > So no, there would not be any changes in Automatic SBC profile. This >> one >> > > > should stay untouched, to make it always working with all existing >> > > > devices without any regression. >> > > >> > > I wasn't aware that advertising the XQ settings during negotiation >> > > breaks some devices. I guess this means that JP Guillaume's SBC XQ >> > > patch can't be accepted, assuming that we value avoiding regressions >> > > more than the improved quality for most headsets? >> > >> > In this patch series I'm reworking and proposing also XQ profiles at >> > separate endpoints. So in case XQ is broken for paricular device, with >> > codec switching API, user would be able to switch back to automatic SBC >> > profile (on different SEP) which should stay as it is in current >> > version, which is working with all devices. >> >> Yes, but what about JP Guillaume's patch, which is a simple way of >> achieving XQ support before your patches have been accepted? I planned >> to review it first (because he asked), but now it looks like that may >> not be a good idea (I don't want regressions). > > With that "simple way" patch there would be regressions for "broken" > devices. That is the reason why codec switching from bluez side is > needed and having separate SEPs for XQ. So Automatic profile (current > one) could be freezed and would be used like before for all devices. > >> > > Here's that patch: >> > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 >> > > > > -- > Pali Rohár > pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
The SRC (PA) does not announce XQ bitpool. It takes the max bitpool value announce by the SNK (the BT device) and then decide if XQ is possible, or not, depending on the value announced by the SNK and its ability to do dual channel (also announced by the SNK during negociation).As stated in the README of my patch : in case the device can't do XQ : PA falls back to legacy bitpool. JP14:52, 17 octobre 2019, "Tanu Kaskinen" :On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote: Automatic SBC profile is not going to be changed. It is there to support all devices without any tweaks. ValdikSS already did more tests and there are devices which do not work with higher SBC bitpool. So increasing max value of bitpool in Automatic SBC profile would lead to broken support for these devices and therefore regressions. As Automatic SBC profile is the only one available for systems where codec switching is not supported, it would mean complete regression as these devices completely stops working on those systems. Upgrading either pulseaudio or bluez must not lead to problem that some bluetooth devices stop working (if they worked before upgrade). So no, there would not be any changes in Automatic SBC profile. This one should stay untouched, to make it always working with all existing devices without any regression.I wasn't aware that advertising the XQ settings during negotiationbreaks some devices. I guess this means that JP Guillaume's SBC XQpatch can't be accepted, assuming that we value avoiding regressionsmore than the improved quality for most headsets?Here's that patch: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177-- Tanuhttps://www.patreon.com/tanukhttps://liberapay.com/tanuk-- Sent from Yandex.Mail for mobile___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Thursday 17 October 2019 16:11:26 Tanu Kaskinen wrote: > On Thu, 2019-10-17 at 14:55 +0200, Pali Rohár wrote: > > On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote: > > > On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote: > > > > Automatic SBC profile is not going to be changed. It is there to support > > > > all devices without any tweaks. ValdikSS already did more tests and > > > > there are devices which do not work with higher SBC bitpool. So > > > > increasing max value of bitpool in Automatic SBC profile would lead to > > > > broken support for these devices and therefore regressions. > > > > > > > > As Automatic SBC profile is the only one available for systems where > > > > codec switching is not supported, it would mean complete regression as > > > > these devices completely stops working on those systems. > > > > > > > > Upgrading either pulseaudio or bluez must not lead to problem that some > > > > bluetooth devices stop working (if they worked before upgrade). > > > > > > > > So no, there would not be any changes in Automatic SBC profile. This one > > > > should stay untouched, to make it always working with all existing > > > > devices without any regression. > > > > > > I wasn't aware that advertising the XQ settings during negotiation > > > breaks some devices. I guess this means that JP Guillaume's SBC XQ > > > patch can't be accepted, assuming that we value avoiding regressions > > > more than the improved quality for most headsets? > > > > In this patch series I'm reworking and proposing also XQ profiles at > > separate endpoints. So in case XQ is broken for paricular device, with > > codec switching API, user would be able to switch back to automatic SBC > > profile (on different SEP) which should stay as it is in current > > version, which is working with all devices. > > Yes, but what about JP Guillaume's patch, which is a simple way of > achieving XQ support before your patches have been accepted? I planned > to review it first (because he asked), but now it looks like that may > not be a good idea (I don't want regressions). With that "simple way" patch there would be regressions for "broken" devices. That is the reason why codec switching from bluez side is needed and having separate SEPs for XQ. So Automatic profile (current one) could be freezed and would be used like before for all devices. > > > Here's that patch: > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 > > > > -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Thu, 2019-10-17 at 14:55 +0200, Pali Rohár wrote: > On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote: > > On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote: > > > Automatic SBC profile is not going to be changed. It is there to support > > > all devices without any tweaks. ValdikSS already did more tests and > > > there are devices which do not work with higher SBC bitpool. So > > > increasing max value of bitpool in Automatic SBC profile would lead to > > > broken support for these devices and therefore regressions. > > > > > > As Automatic SBC profile is the only one available for systems where > > > codec switching is not supported, it would mean complete regression as > > > these devices completely stops working on those systems. > > > > > > Upgrading either pulseaudio or bluez must not lead to problem that some > > > bluetooth devices stop working (if they worked before upgrade). > > > > > > So no, there would not be any changes in Automatic SBC profile. This one > > > should stay untouched, to make it always working with all existing > > > devices without any regression. > > > > I wasn't aware that advertising the XQ settings during negotiation > > breaks some devices. I guess this means that JP Guillaume's SBC XQ > > patch can't be accepted, assuming that we value avoiding regressions > > more than the improved quality for most headsets? > > In this patch series I'm reworking and proposing also XQ profiles at > separate endpoints. So in case XQ is broken for paricular device, with > codec switching API, user would be able to switch back to automatic SBC > profile (on different SEP) which should stay as it is in current > version, which is working with all devices. Yes, but what about JP Guillaume's patch, which is a simple way of achieving XQ support before your patches have been accepted? I planned to review it first (because he asked), but now it looks like that may not be a good idea (I don't want regressions). > > Here's that patch: > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 > > -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote: > On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote: > > Automatic SBC profile is not going to be changed. It is there to support > > all devices without any tweaks. ValdikSS already did more tests and > > there are devices which do not work with higher SBC bitpool. So > > increasing max value of bitpool in Automatic SBC profile would lead to > > broken support for these devices and therefore regressions. > > > > As Automatic SBC profile is the only one available for systems where > > codec switching is not supported, it would mean complete regression as > > these devices completely stops working on those systems. > > > > Upgrading either pulseaudio or bluez must not lead to problem that some > > bluetooth devices stop working (if they worked before upgrade). > > > > So no, there would not be any changes in Automatic SBC profile. This one > > should stay untouched, to make it always working with all existing > > devices without any regression. > > I wasn't aware that advertising the XQ settings during negotiation > breaks some devices. I guess this means that JP Guillaume's SBC XQ > patch can't be accepted, assuming that we value avoiding regressions > more than the improved quality for most headsets? In this patch series I'm reworking and proposing also XQ profiles at separate endpoints. So in case XQ is broken for paricular device, with codec switching API, user would be able to switch back to automatic SBC profile (on different SEP) which should stay as it is in current version, which is working with all devices. > Here's that patch: > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 > -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote: > Automatic SBC profile is not going to be changed. It is there to support > all devices without any tweaks. ValdikSS already did more tests and > there are devices which do not work with higher SBC bitpool. So > increasing max value of bitpool in Automatic SBC profile would lead to > broken support for these devices and therefore regressions. > > As Automatic SBC profile is the only one available for systems where > codec switching is not supported, it would mean complete regression as > these devices completely stops working on those systems. > > Upgrading either pulseaudio or bluez must not lead to problem that some > bluetooth devices stop working (if they worked before upgrade). > > So no, there would not be any changes in Automatic SBC profile. This one > should stay untouched, to make it always working with all existing > devices without any regression. I wasn't aware that advertising the XQ settings during negotiation breaks some devices. I guess this means that JP Guillaume's SBC XQ patch can't be accepted, assuming that we value avoiding regressions more than the improved quality for most headsets? Here's that patch: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 00/10] Bluetooth A2DP codecs
On Thu, 2019-10-17 at 12:06 +0200, Pali Rohár wrote: > Hello! > > On Sunday 06 October 2019 19:58:32 Pali Rohár wrote: > > Changes in v13: > > * Do not use read smoother for A2DP sink when backchannel is in use > > * Use new bluez org.freedesktop.DBus.ObjectManager and RegisterApplication > > DBus APIs for codec switching > > * Add FastStream codec profile without microphone support > > * Correctly calculate and fill RTP sequence number in aptX-HD encoded frames > > > > Pali Rohár (10): > > bluetooth: Implement reading SO_TIMESTAMP for A2DP source > > bluetooth: Print SO_TIMESTAMP warning for SCO source only once > > bluetooth: Parse remote timestamp from A2DP RTP packets when available > > bluetooth: Set initial A2DP profile which bluez already activated > > May I ask for review at least for these first 4 patches? Sure, I'll put you in the queue of people who have requested me to review their patches. The queue so far: 1. Improvements to reconfiguration https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24 2. Adds SBC XQ negotiated at the best of capabilities of the BT device https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 3. alsa-ucm: Support Playback/CaptureVolume https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/32 4. [PATCH v13 00/10] Bluetooth A2DP codecs -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 00/10] Bluetooth A2DP codecs
Will test12:06, 17 octobre 2019, "Pali Rohár" :Hello!On Sunday 06 October 2019 19:58:32 Pali Rohár wrote: Changes in v13: * Do not use read smoother for A2DP sink when backchannel is in use * Use new bluez org.freedesktop.DBus.ObjectManager and RegisterApplication DBus APIs for codec switching * Add FastStream codec profile without microphone support * Correctly calculate and fill RTP sequence number in aptX-HD encoded frames Pali Rohár (10): bluetooth: Implement reading SO_TIMESTAMP for A2DP source bluetooth: Print SO_TIMESTAMP warning for SCO source only once bluetooth: Parse remote timestamp from A2DP RTP packets when available bluetooth: Set initial A2DP profile which bluez already activatedMay I ask for review at least for these first 4 patches?-- Pali Rohárpali.ro...@gmail.com___pulseaudio-discuss mailing listpulseaudio-discuss@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss-- Sent from Yandex.Mail for mobile___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Pulseaudio system wide mode design
Hello, there are repeated problems related to fact that pulseaudio is running under user session and every user spawns own pulseaudio process. Only one process can have exclusive access to specific ALSA card. Also only one process can create connection to bluetooth A2DP device. Looking at pulseaudio design, which should abstract audio device and sound cards which are "shared" resources, it looks for me that it is something which should be managed by (central) point. And not by many, for every user one. So what are the main problems which prevent usage of pulseaudio in system-wide mode. When in system would be running only instance of pulseaudio and all users would connect to that one instance? I know only problem related to security, that any process which has access to pulseaudio socket can control audio settings of all other processes connected to pulseaudio. And also can load or unload any pulseaudio module. But this can be easily fixable by implementing access control, e.g. users in pulseaudio-admin group would be able to control everything like before (including module loading) and users in pulseaudio-access group would be able to see and modify only streams which they created and would not be able to see other strings (or modify other properties). And also would not be able to load/unload modules. Is there anything else which prevents moving pulseaudio into proper system wide mode? -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 00/10] Bluetooth A2DP codecs
Hello! On Sunday 06 October 2019 19:58:32 Pali Rohár wrote: > Changes in v13: > * Do not use read smoother for A2DP sink when backchannel is in use > * Use new bluez org.freedesktop.DBus.ObjectManager and RegisterApplication > DBus APIs for codec switching > * Add FastStream codec profile without microphone support > * Correctly calculate and fill RTP sequence number in aptX-HD encoded frames > > Pali Rohár (10): > bluetooth: Implement reading SO_TIMESTAMP for A2DP source > bluetooth: Print SO_TIMESTAMP warning for SCO source only once > bluetooth: Parse remote timestamp from A2DP RTP packets when available > bluetooth: Set initial A2DP profile which bluez already activated May I ask for review at least for these first 4 patches? -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
