Re: [pulseaudio-discuss] [PATCH v3 00/11] Introduce memfd support
Hello! I've now merged and pushed patches 1 to 9 after some quick checks. When looking at patch 10 I thought that was part of the final enablement sequence (after all, it bumps the protocol so it's not as easy to revert as the rest of the patches, in case something is wrong), so I figured both 10 and 11 could be part of your next patch set. I added a trivial patch on top of your patch set that fixes two compiler warnings I saw. Thanks! // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Issues with HSP profile on Bluetooth Headset
So I compiled pulseaudio with: --enable-bluez5 \ --enable-bluez5-ofono-headset \ --disable-bluez5-native-headset \ --disable-hal-compat \ --disable-bluez4 Despite that, I'm still getting: W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to headset_head_unit: Not connected A2DP works as expected. HSP/HFP shows as unavailable. ofono is running (under systemd - compiled & installed from https://aur.archlinux.org/packages/ofono/). pactl list output for the headset card: Card #3 Name: bluez_card.A0_14_3D_6B_E6_7F Driver: module-bluez5-device.c Owner Module: 26 Properties: device.description = "Parrot ZIK 3.0 V3.01" device.string = "A0:14:3D:6B:E6:7F" device.api = "bluez" device.class = "sound" device.bus = "bluetooth" device.form_factor = "hands-free" bluez.path = "/org/bluez/hci0/dev_A0_14_3D_6B_E6_7F" bluez.class = "0x240408" bluez.alias = "Parrot ZIK 3.0 V3.01" device.icon_name = "audio-handsfree-bluetooth" device.intended_roles = "phone" Profiles: a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: yes) headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 20, available: no) off: Off (sinks: 0, sources: 0, priority: 0, available: yes) Active Profile: a2dp_sink Ports: handsfree-output: Handsfree (priority: 0, latency offset: 0 usec, available) Part of profile(s): a2dp_sink, headset_head_unit handsfree-input: Handsfree (priority: 0, latency offset: 0 usec, not available) Part of profile(s): headset_head_unit Have I missed something? J. Leclanche On Sun, Mar 27, 2016 at 11:58 AM, Tanu Kaskinen wrote: > On Sat, 2016-03-26 at 16:06 +0100, Georg Chini wrote: >> On 26.03.2016 11:19, Tanu Kaskinen wrote: >> > >> > On Sat, 2016-03-26 at 11:31 +0200, Jerome Leclanche wrote: >> > > >> > > Hi list >> > > >> > > I've been debugging all morning issues with the Parrot ZIK 3.0 (and >> > > its two previous model versions) not displaying HSP profile as >> > > available. >> > > >> >> > >> > > >> > > Here's a bug report on the topic: >> > > https://bugs.freedesktop.org/show_bug.cgi?id=93898 >> > > >> > > The bug report shows information about two devices, and now I noticed >> > > something that I hadn't noticed earlier: the working device supports >> > > both HSP and HFP, but the non-working device only supports HFP. The >> > > "native" backend in pulseaudio only supports HSP, so this explains why >> > > some headsets don't work. The assumption has been that all headsets >> > > would support both profiles anyway, but if there are headsets that >> > > don't have HSP, then it seems that we still don't support all headsets >> > > with BlueZ 5 (BlueZ 4 should still work fine, but nobody is using it >> > > anymore). The oFono backend is of no use for headset support, because >> > > it only supports the role where PulseAudio runs on the handsfree >> > > device, meaning that you can connect your laptop to your phone and >> > > pretend that the laptop is a headset. >> This might be different now. I have seen a few patches on the >> ofono side concerning headset support, so it may work meanwhile. > > Ok, that's good. It would be nice if someone could test and report back > if using headsets with the oFono backend works now (I should be able to > try that too, but last time I tried to set up oFono, nothing worked). > >> > > I don't know when this will be fixed. I'm not volunteering to implement >> > > the missing functionality. >> > > >> Wasn't there a discussion that pulseaudio should only support HSP >> and HFP should be covered by ofono? > > I don't remember everything that was discussed, but you are probably > right, since that's certainly the end result of things. However, when > the native backend was added, I'm sure the expectation was that > supporting only HSP would be good enough for desktop systems. Now if > there is a significant number of HFP-only headsets, the native backend > becomes nearly pointless, if supporting the full range of headsets > requires oFono anyway. > > -- > Tanu > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Splitting a 7.1 device into virtual 5.1 + 2.0 devices?
> > > > I'm using an ALC899 codec with 6x3.5mm jacks and so far, I've been > > using sink-remap [1], which worked fine, 5.1 sound being remixed to > > 2.0 as expected. > > > > However, there are two problems with this: > > - even though I select the Stereo sink as output in pavucontrol, the > > sound is also playing via my Surround sink > > - the two sinks have their volumes linked. > > So the setup is exactly as instructed in the Arch wiki? Two things seem > to be wrong in the instructions (I don't know how that could be - did > the author not test what he or she wrote to the wiki?): the "remix" > option should be "no" in both cases. Otherwise anything played to the > stereo sink will be upmixed to all channels of the 7.1 sink. > > The second thing is that if the stereo and 5.1 sinks are not supposed > to use overlapping channels, then the channel maps are wrong, because > both sinks use the front-left and front-right channels of the master > sink. The stereo sink should have "side-left,side-right" in the > "master_channel_map" parameter. > > > Apparently, I could set my card to 5.1 and the grey socket would be > > automatically treated as a 2.0 device, however the behavior is > > completely the same as my earlier setup, including the caveats > > described above > > > > I would like to split them in separate devices as follows: > > > > - two sinks visible, Stereo (for the 2.0 amplifier) and Surround (for > > my 5.1 headset with a built-in amplifier), physical 7.1 device hidden > > in pavucontol/KDE's plasma-pa widget > > Hiding the 7.1 sink is not currently possible. > > > - for the Stereo sink, I want the LFE to be mixed into the stereo > > channels when downmixing, but left untouched for stereo content (just > > like it did with PA6.0). Same for rear and center channels. > > This does not require any changes to anything. As long as remixing is > enabled in daemon.conf (like it is by default), playback streams with > LFE will be downmixed to have LFE in the left and right channels, and > if the playback stream doesn't have an LFE channel, then there's > nothing to do (leaving LFE "untouched for stereo content" doesn't make > sense to me, because there's nothing to leave untouched). The easy way is to use hdajackretask your grey line out as internal speaker, there will be headphone, 5.1 line out jacks and stereo speaker ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v3 00/11] Introduce memfd support
Hi, On Mon, Mar 28, 2016 at 03:55:43PM +0200, Sjoerd Simons wrote: > On Tue, 2016-03-22 at 11:24 +0500, Alexander E. Patrakov wrote: > > > > [readding the list] > > > > 22.03.2016 05:56, Ahmed S. Darwish пишет: > > > > > > On Mon, Mar 21, 2016 at 10:01:14AM +0100, David Henningsson wrote: > > > > > > Alexander mentioned the SteamOS case, where "they don't link > > > statically, but have a 'known-good' copy of the library packaged > > > and put into LD_LIBRARY_PATH, and it may be next to impossible to > > > explain to the users how to upgrade it." > > > > It is about the standalone Steam client, not SteamOS... > > > > > > > > I'm sure though that even if they have a 'known-good' copy, they > > > keep the daemon version in-sync with the library version? I can't > > > think of any sane reason not to do so.. > > > > So they don't. > > > > > > > > Anyway, if that case is indeed problematic, maybe we can lobby > > > them a bit to do a proper distribution of PA? If anyone has some > > > contacts, I'll be glad to open a communication channel.. > > > > > > > It is impossible. They connect to a distribution-provided daemon. > > So all we could reasonably do is to ask them to rely on the system- > > installed libpulse (including the 32-bit version). > > Steam OS only exposes a very very minimal amount of the "host" > libraries to games (essentially libc6, X11 and the GL stack iirc) > everything else comes from a static runtime which is also what the > games are tested against (which has an older libpulse). > Thanks a lot for sharing this.. was not exposed to Steam's distribution model before. OK, then I guess this proposal shall make everyone happy: http://article.gmane.org/gmane.comp.audio.pulseaudio.general/25628 regards, -- Darwish http://darwish.chasingpointers.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v3 00/11] Introduce memfd support
Hi :-) [ Adding Sjoerd Simons ] [ Sorry for the late replies ] On Thu, Mar 31, 2016 at 10:57:27AM +0200, David Henningsson wrote: > > On 2016-03-22 01:56, Ahmed S. Darwish wrote: > > On Mon, Mar 21, 2016 at 10:01:14AM +0100, David Henningsson wrote: > > > > > > On 2016-03-12 23:35, Ahmed S. Darwish wrote: > > > > Hello! > > > > > > > > The simplified memfd patch series ;-) > > > > > > Hi! > > > > > > Good work! > > > > > > I've read through the patch series and think they look pretty > > > much okay, and your amount of testing is exemplary. > > > > > > > Thanks a lot .. couldn't do it without everyone's help here :-) > > > > Also, regarding the testing, I really did not want to increase > > anyone's Launchpad bugfixing workload ;-) > > > > > Surely there are nitpicks here and there but at this point I > > > think maybe we're better off merging the patch series as it > > > is to get wider testing from developers using it in practice. > > > > > > > Great, I'll be around if there's anything in need of a fix. > > > > > My only concern or thought is about the global mempool. By > > > turning that into a memfd by default, we would potentially > > > slow down clients which support posix shm but not memfd. I'm > > > not sure if this is a problem in practice though - even an > > > old closed-source client would (hopefully?) bind to a new > > > libpulse library and thus gain memfd support that way, and I > > > hope nobody links libpulse statically. Thoughts? > > > > Alexander mentioned the SteamOS case, where "they don't link > > statically, but have a 'known-good' copy of the library > > packaged and put into LD_LIBRARY_PATH, and it may be next to > > impossible to explain to the users how to upgrade it." > > > > I'm sure though that even if they have a 'known-good' copy, > > they keep the daemon version in-sync with the library version? > > I can't think of any sane reason not to do so.. > > > > Anyway, if that case is indeed problematic, maybe we can lobby > > them a bit to do a proper distribution of PA? If anyone has > > some contacts, I'll be glad to open a communication channel.. > > Aaaand...there we stalled. I could use a second opinion on: > > 1) Whether to go ahead and merge, despite not promising to be > around much to test it > > 2) If that merge should include all 11 patches or not. > > Given the fact that the possible performance regression only > affects a) input data and b) only old copies of libpulse, I > think the chances are fairly small. > > One option could be to merge all patches as-is but on top of > that set "enable-memfd" to default to false for one release cycle; > to give Steam and others a chance to update. That will also give > pioneers some extra time for testing, and report bugs if there > are any. > There's a nice path that can satisfy all use-cases, including the ancient libpulse one.. Patch #1 to #10 won't hurt anyone's performance, including ancient clients, so let's merge those now. Patch #11 transforms the srbchannel mempool and the global mempool to memfds. I'll submit a modified version where: - The srbchannel mempool will be kept to use memfds by default. Patch #3 already transformed that pool to the per-client model, so if the client declares support only for posix SHM but not memfds (e.g. libpulse < 9.0), posix SHM will be used nicely. No performance hit here too. - The global mempool, since it's global by nature and cannot cater to each client's needs (thus the reverse to always-supported plain old data copy if memfds are non-existent on the client), will be kept to use posix SHM by default. The next patch series, which will then transforms the global mempool to a per-client model, will be able to personalize that mempool's SHM type according to different clients needs. Thus memfds can be used for it while not hurting older clients. Sounds good? regards, -- Darwish http://darwish.chasingpointers.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Splitting a 7.1 device into virtual 5.1 + 2.0 devices?
On Sun, 2016-03-27 at 14:35 +0200, 紅 蒼穹 wrote: > Hello, > > I'm using an ALC899 codec with 6x3.5mm jacks and so far, I've been > using sink-remap [1], which worked fine, 5.1 sound being remixed to > 2.0 as expected. > > However, there are two problems with this: > - even though I select the Stereo sink as output in pavucontrol, the > sound is also playing via my Surround sink > - the two sinks have their volumes linked. So the setup is exactly as instructed in the Arch wiki? Two things seem to be wrong in the instructions (I don't know how that could be - did the author not test what he or she wrote to the wiki?): the "remix" option should be "no" in both cases. Otherwise anything played to the stereo sink will be upmixed to all channels of the 7.1 sink. The second thing is that if the stereo and 5.1 sinks are not supposed to use overlapping channels, then the channel maps are wrong, because both sinks use the front-left and front-right channels of the master sink. The stereo sink should have "side-left,side-right" in the "master_channel_map" parameter. > Apparently, I could set my card to 5.1 and the grey socket would be > automatically treated as a 2.0 device, however the behavior is > completely the same as my earlier setup, including the caveats > described above > > I would like to split them in separate devices as follows: > > - two sinks visible, Stereo (for the 2.0 amplifier) and Surround (for > my 5.1 headset with a built-in amplifier), physical 7.1 device hidden > in pavucontol/KDE's plasma-pa widget Hiding the 7.1 sink is not currently possible. > - for the Stereo sink, I want the LFE to be mixed into the stereo > channels when downmixing, but left untouched for stereo content (just > like it did with PA6.0). Same for rear and center channels. This does not require any changes to anything. As long as remixing is enabled in daemon.conf (like it is by default), playback streams with LFE will be downmixed to have LFE in the left and right channels, and if the playback stream doesn't have an LFE channel, then there's nothing to do (leaving LFE "untouched for stereo content" doesn't make sense to me, because there's nothing to leave untouched). > - for the Surround sink, I want the LFE to use the subwoofer, as > standard PA7.0 behavior. As long as the 5.1 sink's lfe channel position is the same in both "channel_map" and "master_channel_map", that's what will happen. > - selecting one of the sinks should only play sound on that sink, not > both of them A playback stream can only play to only one sink anyway. I assume that your confusion arises from the upmixing that was done between the stereo sink and the master 7.1 sink due to the "remix=yes" parameter. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
