pipewire-irc-logs.txt

* Now talking on #pipewire
* Topic for #pipewire is: PipeWire multimedia daemon. See https://pipewire.org. Latest version: 0.3.66. You must be registered with NickServ to speak (due to bot spam). Bridged to #pipewire:matrix.org
* Topic for #pipewire set by wtay!~wim@106.red-83-60-92.dynamicip.rima-tde.net (Thu Feb 16 03:43:26 2023)
<marler8997> Hello, I'm trying to finish up our pipewire usage for capturing a screencast session via the flatpak portal and am running into a few issues.
<marler8997> The first is how I should be handling the "node id" that the screencast portal gives me.  It looks like the "target id" parameter for connecting a stream is deprecated?  Is there a way to turn a pipewire node id into an "object serial" or "node name"?
<marler8997> The next is how to setup the stream.  I'm getting different results on different distros/implementations.  The question is whether I should be specifying a set of supported formats.  If I do but the actual format isn't in my list, then the stream just never connects and I get no error, so the application just looks like it's not working.  However, if I don't provide a set of formats, then one of my newer distros 
<marler8997> disconnects the stream immediately (maybe because I'm using the deprecated node id?)
* wtay has quit (Ping timeout: 480 seconds)
* rv1sr has quit ()
* rncbc has quit (Quit: byee!)
* plush (~oftc-webi@p50857465.dip0.t-ipconnect.de) has joined
* dviola has quit (Ping timeout: 480 seconds)
<plush> Hi, I am trying to debug a Bluetooth problem. I am building Bluetooth speaker. When playing audio from my Android phone, pipewire shows the a2dp_source as 100% volume. The volume slider on my phone does change the sound volume, but not this number. And if I move it more than ~halfway up, sound stutters and stops.
<rsc> pinkflames[m]: well, I had the hope that I could retire esound in favor of PipeWire maybe. But looks like not. And no, it's indeed not PipeWire's problem ;-)
* bengan has quit (Ping timeout: 480 seconds)
<plush> Digging into the code, it seems hw-volume (absolute volume) is not getting activated, even though I have it configured.
<plush> Any help with debugging this is very welcome!
<pinkflames[m]> marler8997: as luck would have it someone asked that just hours prior. I could be mistaken but, I think, the plan is for portal to return serial eventually. That's about all I can say, sorry.
* plush is now known as plush2
* plush (~Core7720@p200300f1c710f200c49b06d414ec8bbb.dip0.t-ipconnect.de) has joined
* plush2 has quit ()
<woobilicious[m]> Is there anyway to debug pipewire not setting realtime threads properly? after a recent update rtkit is managing many threads, but none of them are realtime. but it's not giving me any errors.
* Blendie has quit (Quit: Connection closed for inactivity)
* AdeptVeritatis has quit (Quit: Konversation terminated!)
<pinkflames[m]> woobilicious[m]: you can run a native client such as mpv --ao=pipewire with PIPEWIRE_DEBUG=D to maybe see if there's any errors
<pinkflames[m]> and likewise the daemon will also produce more output with that set in its environment
<pinkflames[m]> woobilicious[m]: also maybe check dmesg for RT throttle (not sure about capitalization) and that RTKit has not since then changed its opinion
* nedko has quit (Remote host closed the connection)
* nedko (~nedko@00027f34.user.oftc.net) has joined
* bengan (~quassel@ivan.widell.net) has joined
* bengan has quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
* bengan (~quassel@ivan.widell.net) has joined
* sam_ has quit (Ping timeout: 480 seconds)
* eroux (~eroux@0002c23f.user.oftc.net) has joined
<pinkflames[m]> woobilicious[m]: if you run with PIPEWIRE_DEBUG=2 it does print `[W][04335.079104] default      | [        thread.c:  101 impl_acquire_rt()] acquire_rt thread:0x7fbd927fc6c0 prio:-1 not implemented` but I think it's supposed to be more of an annoyance than an actual issue
* Liam_Galt has quit (Quit: ZNC 1.8.2 - https://znc.in)
* wtay (~wim@167.red-81-38-138.dynamicip.rima-tde.net) has joined
* ChanServ gives channel operator status to wtay
* eroc1990 has quit (Quit: The Lounge - https://thelounge.chat)
* Liam_Galt (~Liam_Galt@199.241.26.23) has joined
* Gilou (~weechat@0002bc29.user.oftc.net) has joined
* eroc1990 (~eroc1990@024-183-186-146.res.spectrum.com) has joined
* dviola (~diego@0002b89a.user.oftc.net) has joined
* ashafq has quit (Ping timeout: 480 seconds)
* Betal has quit (Quit: WeeChat 3.8)
* rv1sr (~rv1sr@0002da44.user.oftc.net) has joined
* doublemetres has quit (Quit: leaving)
<wyre> wtay, are here https://github.com/PipeWire/pipewire/tree/master/src/modules reimplementations for module-rtp-send and module-rtp-recv? 
<wyre> cause I can just see module-rtp-source and module-rtp-sink
<wtay> wyre, the pulseaudio modules are implemented here: https://github.com/PipeWire/pipewire/tree/master/src/modules/module-protocol-pulse/modules
<wtay> wyre, but as you can see, module-rtp-send load the native module-rtp-sink at some point: https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/modules/module-rtp-send.c#L75
<wyre> oh, I'm interested in checking this RTP over SAP implementation 
<wyre> not sure if SAP is always used when you use RTP, I'd say it's optional as it's experimental, ain't it? 
<wtay> in general? no SAP is not experimental
<wyre> wtay, well, here it says it is! https://www.rfc-editor.org/rfc/rfc2974
<wyre> can't see any other RFC which obsoletes it 🤔
<pinkflames[m]> There is also ROC which does use RTP internally (as one of the transport options) and it, IIRC, also advertises iOS and Android clients
<wtay> wyre, you should not believe everything you read on the internet
<wyre> wtay, well, I though RFC were something serious 😆
<wtay> wyre, they probably forgot to update the status after 23 years..
<pinkflames[m]> Slight correction the Android client is WIP, so I"m not sure how ready the code is
<pinkflames[m]> Sometimes experiments run for decades or centuries :)
<wyre> wtay, but can't see any newer RFC for SAP 🤔
<wtay> wyre, it's perfect, there is no need for a newer RFC
<wyre> so I guess it's just it's not experimental anymore but that RFC2974 is right
* Mo (~Mo@0002a66a.user.oftc.net) has joined
<Mo> Hi, what is the difference between pacmd and pactl? Older Howtos for Pulseaudio use pacmd. Can I use pactl exactly the same way?
<wyre> wtay, now I'm re-reading this https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#rtpsdpsaptransportmodules I guess RFC2327 shouldn't be duplicated and it want to mean RFC2974, am I right? 😊
<pinkflames[m]> Mo: generally speaking pacmd does not work with PipeWire because it relies on implementation details of pulseaudio
<pinkflames[m]> however it might somewhat work now, not sure. Either way best use pactl if there's the equivalent command for it or the native PW module if there is one
<wtay> wyre, probably
<wtay> pacmd does not work
<wtay> pactl can do almost all things pacmd can do
<KitsuWhooa> I'm trying to host a JUCE-based LV2 plugin with libpipewire-module-filter-chain but the whole thing segfaults. I wouldn't put it past the plugin being badly designed, but other hosts do not cause it to segfault.
<KitsuWhooa> Any idea what is going on? https://tasossah.com/txt/module-filter-chain_lv2_segfault
<wtay> KitsuWhooa, it seems to be expecting some sort of atom thing on an output port, I don't think it is implemented
<KitsuWhooa> Oh
<KitsuWhooa> no easy way to stub it I assume?
<wtay> no..
<KitsuWhooa> I don't actually want to use anything fancy or any events
<KitsuWhooa> I see
<wtay> you could use the ladspa version of the plugin..
<KitsuWhooa> Something is off with it, and it wastes cpu cycles when the VAD doesn't pick any audio up
<KitsuWhooa> wastes enough CPU to 100% a core on an old Xeon and cause constant underruns
<KitsuWhooa> the LV2 version of it doesn't exhibit this, so I was hoping to avoid it
<KitsuWhooa> either way, thanks
<pinkflames[m]> wtay: that reminds me, what are your thoughts on the CLAP plugin API by Alexandre Bique ?
<pinkflames[m]> I think you did mention/discuss it last year but I do not recall if it's not being implemented because you're not interested or would prefer LV2 or if it wasn't ready at the time.
<wtay> are those the only options?
<pinkflames[m]> No, feel free to express yourself :)
<wtay> no time
<pinkflames[m]> Ok. If anyone asks again should I say that it will be hopefully supported at some point or only if someone else implements it or you'd be against accepting such contributions?
<wtay> I would be happy to accept to that implements CLAP support
<wtay> s/to/code/
<pinkflames[m]> Alright, if anyone wonders, I'll say that they are free to make an MR :)
<Mo> pinkflames[m]: And for module documentation I can still rely on https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-remap-source ?
<Mo> I don't understand what the  remix= actually does.
<wtay> Mo normally a stream adapts (and remixes) itself to the configuration of the sink/source it connects to
<wtay> Mo, remap-source has a stream as input (that links to a source) and a source as the output. What you likely want to do is keep the original stream channelmap and map that directly to the source channelmap without remixing
* plush has quit (Ping timeout: 480 seconds)
<Mo> wtay: I have a mic that says it is stereo, but it's not, Only the left channel is valid. So I like to map the left channel to some new mono device.
<Mo> For that I found 2 solutions in the net:
<pinkflames[m]> Mo: it may not be surprising to learn that I do not read such documentation, if I can help it - the automated source code tag dumps just make my head hurt :)
<pinkflames[m]> which is to say I do not know if it's up to date or not
<Mo> pactl load-module module-remap-source source_name=Samson_C01U-mono master=alsa_input.usb-Samson_Technologies_Samson_C01U-00.analog-stereo master_channel_map=front-left channel_map=mono
<Mo> pactl load-module module-remap-source source_name=Samson_C01U-mono master=alsa_input.usb-Samson_Technologies_Samson_C01U-00.analog-stereo master_channel_map=left,left channel_map=left,right remix=false
<pinkflames[m]> Mo: multiple people (including me) have told you already: create a virtual device that is MONO. Which is in effect what the pactl remap does, too
<Mo> wtay: I guess the first is correct, as it maps only left channel to some new mono device.
<Mo> So the first?
<pinkflames[m]> Alternative would be to maybe fix the ACP/UCM for your device so that it stops claiming to be a stereo when its not
<wtay> Mo try this: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/filter-chain/source-duplicate-FL.conf
<pinkflames[m]> No, manually load a libpipewire-module-loopback with the config you want is how I'd do it
<pinkflames[m]> But the really good solution would be to fix this at ALSA level for everyone
<pinkflames[m]> I'd imagine/hope that it's possible to just create a profile which has MONO with the data from FL (I imagine that's the one with the actual data)
<pinkflames[m]> wtay: isn't it cleaner to expose a MONO source and let the consumers figure out that it needs to be doubled (maybe with fake stereo effect, too)
<pinkflames[m]> One would think that PW could even automatically handle such MONO to [FL, FR] use cases in the adapter or when creating the links
<Mo> Then the first pactl module-remap-source is easier. Next issue is, it's not working like this as in PA mixer, Recording tab, I have the remapped device now recording from EasyEffects Source, I always need to manually set it to "C01U Stereo" port, how would I do that by pactl?
<wtay> pinkflames[m], ah, so FL -> MONO, yes much better
<pinkflames[m]> Since most microphones are likely MONO at best, one would think this would be a common thing :)
<pinkflames[m]> Alternative are the laptops with array microphones but those likely use some form DSP and may or may not also present themselves as real or synthetic stereo (I'd imagine)
<pinkflames[m]> traditional binaural microphones are probably very rare
<Mo> I use the mixer xfce4-pulseaudio-plugin, there on tab "Recording", device "Remapped ...stereo" I always need to select "..stereo" after the load-module module-remap-source. Any way to do that via pactl?  set-source-port doesn's seem to be the right command.
<pinkflames[m]> Mo: if you were manually creating the module like I suggest, you'd set target.object and if that did not get honored probably go yell at EE or something :)
<pinkflames[m]> Mo: the xfce stuff might itself be a problem
<pinkflames[m]> I don't recall the details but xfce applet is known to interfere with WirePlumber and caused plenty of user reports so far
<pinkflames[m]> Might be worth trying without any applet running to rule out that it's interfering. And if that does not help, then also try with EE not running
<Mo> When migrating from pulseaudio to PW we decided that actually xfce4-pulseaudio-plugin should work and was confirmed at #xfce to do with Pipewire.
<Mo> pinkflames[m]: What is the recommended mixer for Pipewire?
<pinkflames[m]> It works. But, if it's the one, then it works in ways is should not be working...
<pinkflames[m]> i.e. such applets should present information and let the user make API calls to change the state but not actively do management without user interaction
<pinkflames[m]> since both PA and WP will take such automated applet behavior as meaning intentional user action which has a lot of weight
<Mo> What mixer should I take as alternative?
<pinkflames[m]> Mo: well, pavucontrol is the most standard but personally I use plasma-pa. The issue specifically one applet that, I think, is the xfce4 one
<pinkflames[m]> * The issue is specifically one
<pinkflames[m]> and strictly speaking it's not the mixer but management GUI - the actual mixer is inside PW :)
<pinkflames[m]> just like alsamixer is actually a TUI for the mixer that resides on the hardware which is controlled by the kernel driver
<Mo> pinkflames[m]: I see. The xfce4-pulseaudio-plugin is actually only the tray icon with menu.. opening the app it also calls pavucontrol. So what I meant, it's in pavucontrol, Recording, Device Remapped..mic..stereo needs to be set to port mic..stereo to record from. How to do that via pactl?
<pinkflames[m]> No idea since I use plasma-pa :)
<pinkflames[m]> Mo: besides you can keep using pavucontrol. It's only the applet in the tray that needs to not be running
* dv_ has quit (Ping timeout: 480 seconds)
* plush (~Core7720@p200300f1c710f2007c891b1d42babbaa.dip0.t-ipconnect.de) has joined
<plush> I am back to debugging Bluetooth issues. Any help very welcome!
<plush> To recap, I am streaming music to my PipeWire instance and the source is not seeing absolute volume capability.
<plush> I tried streaming from Android and a Chromebook. In both cases, they attenuate samples internally and the stream volume is always 100%. They don't use AVRCP absolute volume.
* Blendie (uid453465@id-453465.helmsley.irccloud.com) has joined
* AdeptVeritatis (~musibitch@dslb-188-106-079-151.188.106.pools.vodafone-ip.de) has joined
* dv_ (~dv@62-178-206-113.cable.dynamic.surfer.at) has joined
* ashafq (~ashafq@pool-74-104-169-62.bstnma.fios.verizon.net) has joined
* lack (~lack@lack.user.oftc.net) has joined
* Mo has quit (Quit: Leaving)
* christil has quit (Ping timeout: 480 seconds)
<plush> With lots of debugging, I found that the volume isn't visible anywhere in PipeWire, but it does show up in org.bluez.MediaTransport1.
<plush> So maybe absolute volume is working after all. It's just invisible in PipeWire, as the source gets attenuated by the spa plug-in, and the resulting stream always has 100% volume.
* p|yush (uid501240@id-501240.helmsley.irccloud.com) has joined
<marler8997> hello trying this question again today.  Does anyone know whether I should be specifying a set of supported formats when I try to connect to a stream started by the flatpak screencast portal?  I'm getting different results on different distros, it's not clear whether I should be specifying formats, if I don't newer distros don't seem to connect the stream so will need to know how to connect in that case
<marler8997> pw_connect_stream docs say the "node id" is deprecated, I should be using node name or object serial instead?  I'm guessing libportal is creating a stream for me then I need to connect to it?  Maybe I can patch libportal to give me an object serial or node name, but I don't know what those are, what they mean and how to get them. Docs seem to be lacking in this area?
<marler8997> I see there is a pw_stream_get_node_id, but that seems to be the deprecated id.  I can't seem to find an equivalent of the "object serial" nor the "node name"?
<marler8997> maybe "node name" is the name you pass in to pw_stream_new?
<pinkflames[m]> marler8997: if you want a response, consider hanging around for longer. For now the portal is using ID but that should change eventually and it will use the serial (AFAIK). No idea what workaround you can or should attempt.
<pinkflames[m]> If you stay around for long enogh, maybe you'll get lucky and a developer will respond on the technical aspects of how to proceed.
<marler8997> pinkflames yeah I saw your response yesterday, I'm trying to implement it myself hence the questions I just asked
<pinkflames[m]> Right, if the API permits node.name, by all means use it.
<marler8997> doesn't seem like it's the same thing though, pw_stream_new takes a "name", but then pw_stream_connect is expecting a PW_KEY_NODE_NAME property?  not sure if they are the same thing or different, docs seem to be very sparse in this area
<pinkflames[m]> serial would work, too, but I doubt you have such an option, since any individual function can at most support either id or serial but not both. AFAIK
<marler8997> serial?  I haven't found any docs on what that is or how to get it?
<pinkflames[m]> I do not think portal currently supports serials but I could be of course wrong :)
<marler8997> I can patch libportal to get it
<pinkflames[m]> Again, just a guess but I'd imagine that the two names you talk about are the same thing
<marler8997> I'm assuming they are creating a pipewire stream internally, I can patch the library to expose whatever I need to reconnect to the stream outside the library
<marler8997> If anyone can answer the question what is an "object serial" and/or "node name" that would be most helpful.
<pinkflames[m]> marler8997: from what I understand, PW_KEY_NODE_foo is how stuff is internally implemented while the node.foo is how it's seen from power-user facing tooling which is what I'm more familiar with
<pinkflames[m]> marler8997: what kind of answer do you want? node.serial is a 32 bit int (from what I recall, sorry if I got it wrong) and node.name is a string associated with a node. Both should be unique or bad things will happen. Anything else?
<wtay> marler8997, object serial is the object.serial property on an object
<marler8997> so object.serial is a unique 32-bit identifier for the stream.  sounds like i could use it to reconnect it?  
<wtay> marler8997, node name is the node.name property on a node
<marler8997> is "node.name" guaranteed to be unique?
<marler8997> is that generated by the server or is it just the name passed in to the stream by the client when it's created?
<wtay> marler8997, you can use the object.serial or node.name to connect with the target.object property
<wtay> node.name is not guaranteed to be unique
<wtay> object.serial is guarenteed to be unique
<pinkflames[m]> marler8997: not quite, node.name should be unique to avoid bugs but ultimately user can make two nodes with the same name by accident and things won't go nicely :)
<marler8997> gotcha, sounds like I should go down the "object.serial" route to somehow get access to the stream created by libportal
<wtay> object.serial is generated on the server from an ever increasing counter
<pinkflames[m]> but keep in mind that the object.serial is not stable across daemon restarts, so never use a cached value from a previous instance
<wtay> marler8997, you should ideally but the portal doesn't give you the object.serial yet
<marler8997> I can patch libportal
<marler8997> I already have some patches to it, for example, a patch to prevent it from calling "abort" if it can't connect to DBUS...wow that was bad
<wtay> marler8997, you have 2 options then, add the object serial to the protocol (in addition to the object.id) when binding or do some more work in the portal to get the object.serial by looking at the registry and waiting for your object and info to appear
<wtay> I would do 1) but that's requires some more knowledge about pipewire internals
<marler8997> hmmm yeah I don't quite understand what 1 means.
<marler8997> you're saying I can connect to the pipewire stream libportal created without patching libportal to give me the serial somehow?
<wtay> marler8997, you can, and you also can also consume the stream without using the serial
<marler8997> one thing, I do have a stream "id" from the glib variant object that libportal gives me, that must be the "object.id"?
<marler8997> (the newer distro gives me this, only distros don't have this but they seem to work with the old deprecated node id)
<wtay> that's the object.id, yes
<marler8997> so I can use that to connect to the stream somehow?  through a property or something?
<wtay> you can pass this to pw_stream_connect as the target_id
<marler8997> wth?
<marler8997> I get 2 ids, I get the "pipewire_node_id" and the stream object also has an "id".  These values are different
<marler8997> Now I'm very confused :)
<pinkflames[m]> Well, id is not promised to be stable, so you can't cache it
<pinkflames[m]> or are they different at the same time?
<marler8997> I thought the "target_id" on pw_stream_connect was the deprecated "pipewire_node_id", not the "id" property on the stream object?
<wtay> I don't know where you get those ids..
<wtay> marler8997, yes, the target_id is the deprecated object.id
<pinkflames[m]> marler8997: the ID itself should be getting deprecated, I believe (but I could be wrong as always)
<marler8997> well the target_id doesn't work on my newer distro I've been testing on
<marler8997> it works on the older ones
<wtay> marler8997, I don't know what other 'id' you have or where you get it from
<wtay> marler8997, that would be a wireplumber problem then
<wtay> quite fatal because it would break screensharing
<marler8997> it comes from xdp_session_get_streams https://libportal.org/method.Session.get_streams.html
* rncbc (~rncbc@0002d149.user.oftc.net) has joined
<pinkflames[m]> but all id's come from the main pipewire daemon, right? WirePlumber would still connect to it and get the id from it, IIRC
<wtay> I don't know what those are
<marler8997> basically Xdp is giving me 2 ids, one they call the "pipewire node ID", and then they have a dynamic list of property/value, on the newer distro there is a second "id" inside this dynanmic prop/value set, called "id" which has a value of 0 when I get it
<marler8997> this dynamic set of properties also has "source_type" "position" and "size"
<marler8997> in any case, using the "pipewire node id" works on older distros, not on my newer distro, so the only way I have to connect to the stream on a newer distro is to specify a list os supported formats and try to get lucky that I connect to the stream created by libportal?
<marler8997> but you said there was a way I could connect to it without getting the object serial, I still don't understand that cause the pipewire node id doesn't work on this newer distro
<wtay> marler8997, don't know, a bug somewhere in the dirstro.. this should work
<marler8997> well it's deprecated so I'm guessing it could have been removed on the newer distro?
<pinkflames[m]> marler8997: just a guess but that sounds like some object oriented programming thing, so maybe an ID that's internal to glib or something
<pinkflames[m]> marler8997: very unlikely
<wtay> marler8997, no
<pinkflames[m]> The only reason it would be removed was if someone did -DPW_REMOVE_DEPRECATED and I think I'm about the only one crazy enough to actually run that :)
<marler8997> It's GNOME on NixOS, I could check 
<wtay> it won't compile then
<pinkflames[m]> wtay: well, sure, I have -UPW_REMOVE_DEPRECATED wired up via Portage for pipewire build :)
<pinkflames[m]> but it's the only package that needed it
<wtay> it probably only removes it from the headers then, the code still uses it
<marler8997> I don't immediately see that compile flag (https://github.com/NixOS/nixpkgs/blob/117fc28b9883ab7a7bcbc2762f9ed8a55458a338/nixos/modules/services/desktops/pipewire/pipewire.nix)
<wtay> anyway, it does not matter, consider it not deprecated for now
<wtay> it will be really deprecated when we have a replacement
<pinkflames[m]> wtay: ah, you mean a client can use the ID even if the header didn't have it, because the PW protocol would have it and the header does not affect that?
<marler8997> they way I'm using it is I'll specify the node id, then I won't specify any supported formats, when I do this on the newer distro the stream goes from connecting to paused then to unconnected
<marler8997> if I specify a list of supported formats, then it works on the newer distro (older distros don't need this list)
<wtay> marler8997, you should always give some supported formats, else you might get something you can't handle
<marler8997> but the catch22 is if I specify a list of supported formats, and the actual format isn't in my list then the stream just never connects, it just gets stuck in "paused" so that's also a bad outcome if I encounter a platofm with a format not in my list
<wtay> no... if you can't handle the format it should not want to continue
<pinkflames[m]> marler8997: but what's the point if you can't handle that format anyway?
<marler8997> so I can report an error to the user
<pinkflames[m]> I doubt the user can do anything about it either
<marler8997> right now the stream just never connects and no error is reported
<wtay> it generates an error you should report to the user
<wtay> in newer wireplumber
<marler8997> it doesn't though, I've set all the stream callbacks
<marler8997> that's the issue
<wtay> you need a newer wireplumber
<dv_> marler8997: you are essentially probing what's supported?
<marler8997> but this is helpful, you're sayign that it *should* report an error if there isn't a supported format in my list? 
<marler8997> how can I be probing if the server doesn't tell me anything?
* FenTiger has quit (Remote host closed the connection)
<dv_> no, I'm asking if this is what you are trying to do
<marler8997> there's no callback that tells me there was an error
<dv_> trying to set up a "dummy" stream with format X and see if that format works
<wtay> you can't probe, realistically
<pinkflames[m]> WIth PW you're not supposed to probe anyway - just use your most preferred option and work from there
<dv_> welllll....
<marler8997> ok that makes sense, so then it sounds like this is just a bug
<dv_> I actually do probe :)
<marler8997> is there a way to probe?
<marler8997> so I can workaround this bug for the time being?
<dv_> I create a pw_stream, set an audio type I want to probe, and see if connecting it works.
<marler8997> how do you know whether it works or not?
<marler8997> like I said I get no error, stream state just goes to "paused' and sits there forever
<pinkflames[m]> marler8997: the expectation is that most things will work with PW, so don't ask if it can convert to it (it will likely say yes)
<dv_> wtay: I know you aren't a fan of that approach, but in the use cases I am running into, this is unavoidable :|
<marler8997> (it also goes to "paused" in a good case before going to the "streaming" state)
<dv_> marler8997: https://github.com/dv1/gst-pipewire-extra/blob/main/ext/pipewire/gstpwaudioformat.c#L2062
<pinkflames[m]> so just ask for what you actually want to use and see where that lands you
<marler8997> pinkflames huh? convert?
<marler8997> pinkflames it lands me in a "paused" state forever
<marler8997> with no way of knowing what's going on
<pinkflames[m]> For audio most probing will always succeed. Video might be less successful because not everything has converters for (yet)
<wtay> we don't convert for video yet, but we might soon
<pinkflames[m]> and you can't by design know which is the "native" format, so just negotiate (not probe) for what you actually want to use in the order of what you prefer the most
<marler8997> On the older distros I could solve this by not specifying any formats.  Then when the stream connects I get a "format changed' event and can detect whether we support it and detect an error.  But this doesn't work on newer distros
<marler8997> there's no negotiation though, that's the problem
<marler8997> if I provide a list of supported formats, the stream just never connects and never reports an error
<dv_> the latter (never reports error) seems off
<dv_> at least the core should get something
<pinkflames[m]> I think Wim already said that that should get solved once you update the WirePlumber (perhaps to git master, not sure)
<marler8997> I've set all the "stream_events" callbacks and I get nothing, the stream just goes to the 'paused' state
<dv_> but yes, an up to date wireplumber is a must
<marler8997> ok this is good info, so to summarize.  You should "always" specify your supported formats when connecting to an existing stream.  If the format is not in your list, you *should* always get an error of some kind.  The situation I'm in now is a "bug" in wireplumber?
<dv_> "supported formats" - you are talking about EnumFormat?
<marler8997> yeah
<wtay> yes, always give formats, when something matches, it links otherwise you get an error. hanging forever is a bug, linking without giving formats is also a bug
<dv_> it is possible that perhaps your params are insufficient
<marler8997> maybe, they're taken from the video capture tutorial, mediaType/SubType/format/size/framerate
<marler8997> https://gist.github.com/marler8997/f7c826a93c2b4614902368a351ae6d3a
* plush has quit (Ping timeout: 480 seconds)
<pinkflames[m]> marler8997: the very idea of accessing devices is probably a bad fit with PW (at least conceptually)
<marler8997> "accessing devices"? huh?
<pinkflames[m]> so instead of thinking what's good for hardware, probably probe in the order of what you actually want to receive
<marler8997> not sure what you're talking about :)
<pinkflames[m]> your comment says "TODO: find a device that has i420 and/or nv12" - PW is supposed to abstract that away, so in the future all devices should match
<marler8997> I420 is the ideal format I want, this data is getting sent via some encoding that expected I420, but, I havnen't found a "device" that gives me I420 yet to test it on
<pinkflames[m]> the only reason that's not the case right now is that the video conversion is not as well rounded out as the audio conversion facilities in PW
<dv_> marler8997: with pw, you should rather think in terms of sending data "into the graph" or "letting the graph handle it"
<dv_> think of the pw graph as this smart entity that can adapt to the data
<marler8997> gotcha yeah that's my understanding as well
<dv_> there _are_ cases where you want to know what's supported though
<marler8997> yeah makes sense
<dv_> but these are more specific though
<pinkflames[m]> it may even be possible that you could get the encoded data from PW, too, although I'm not sure if PW is ready/willing to handle proprietary codecs or if the client software even wants that
<marler8997> like I said, I want I420, just need to find a device to test it on but it looks like that may not exist (a compositor that captures the screen and sends I420 frames)
<pinkflames[m]> marler8997: well... that's still a conversion, since I can't imagine any PC GUI running in I420
<marler8997> sure
<marler8997> did I say it wasn't a conversion?
<pinkflames[m]> so ultimately someone is turning RGG, BGR or some other related format into I420
<marler8997> right
<pinkflames[m]> s/RGG/RGB/
<marler8997> I feel like I'm missing some point you're trying to make pinkflames?
<pinkflames[m]> Well, sort of, you're trying to find something that does not really make sense to exist...
<marler8997> are you saying that I shouldn't ever consider supporting I420?  Just only specify RGB/BGR?
<pinkflames[m]> The only motivation any display sever would have to implement that was if there were client applications that wanted I420 and the not unreasonable position would still be to let PW handle the conversion :)
<marler8997> so you're saying I should include I420 in my list?
<marler8997> so PW can handle it if it wants?
<pinkflames[m]> marler8997: no, I'm only saying you are looking for a compositor that quite likely does not exist. There could be valid I420 sources such as physical cameras or capture cards
<marler8997> gotcha yeah makes sense
* oscillope (~osci@38.122.195.162) has joined
<marler8997> I think this *bug* where the stream just gets stuck in the "paused" state occurs on 3 different distros
<marler8997> Ubuntu 20, Ubuntu 22 and NixOS 21
<marler8997> Actually it may occur on all distros, I can test
<pinkflames[m]> There's two distros for Ubuntu 22... :)
<pinkflames[m]> marler8997: if the fix requires WirePlumber git master then it's very likely that, yes, all up to date distros are affected
<pinkflames[m]> I don't think anyone is shipping snapshots right now (other than NixOS but they probably still just pick a release or something close to that)
<K900> Uhh what
<K900> We're definitely not shipping snapshots
<marler8997> So it's easy to reproduce, I just change my list of enum formats to just have 2 items both being I420 (which won't be supported).  I confirm it's happening on all my distros
<pinkflames[m]> K900: well, you're building from a git checkout, right?
<K900> No
<marler8997> is there a reference to this bug fix or something I can find?
<K900> Well yes but we're building from a git checkout of a stable tg
<K900> s/tg/tag/
<pinkflames[m]> Okay sorry for that then. I was sure your build infrastructure was checking out known commits and therefore could in principle do a snapshot build just as easily
<K900> And we're only doing that because it's easier
<K900> We can do that, yeah
<pinkflames[m]> So, yes, was right :)
<K900> We just don't
* oscillope has quit (Quit: leaving)
<pinkflames[m]> marler8997: no idea, I'm merely going by what Wim said ;)
<K900> Also I can't actually promise our build scripts will be compatible with more recent wireplumber
<K900> Nothing you can't fix with a bit more elbow grease
<K900> But "just tell it to build git master" miiiiight not work
<pinkflames[m]> K900: ugh... you mean 0.5?
<K900> Yeah
<pinkflames[m]> I think on Gentoo side the ebuilds are quite close but let me diff them to refresh my memory
<pinkflames[m]> but I imagine the non-meson part might not port well
<K900> Well, less work for me when 0.5 releases then
<marler8997> my newer nixos distro is on wireplumber 0.4.12
<marler8997> looks like it was released 4 months ago, so is this bug of the stream getting stuck in "paused" fixed in the last 4 months wtay?
* oscillope (~osci@38.122.195.162) has joined
<K900> We should have 0.4.13 on both 22.11 and unstable
<K900> Maybe you need to update
<marler8997> or was that dv_ who suggested updating wireplumber?
<pinkflames[m]> K900: anyway, the ebuilds are identical in all but some trivial and boring ways. However my 0.5 builds are also broken, so /shrug
<marler8997> looks like there are only a few dozen MR's merged in the last 4 months
<pinkflames[m]> I think the way they break has nothing to do with the ebuild, though
<K900> If you're on 0.4.12, you're probably on a pretty old pipewire too
<pinkflames[m]> marler8997: no, that was Wim
<K900> Cause Wireplumber 0.4.13 is a few months old now
<K900> And we had it in NixOS pretty much immediately
* kaira[m] (~kairamatr@2001:470:1af1:101::1:988) has joined
<K900> I don't know if that's going to fix your issue
<marler8997> oh this must have been another convo?
<K900> But it's probably worth mentioning
<pinkflames[m]> marler8997: a developer can merge stuff without going through MR process. Also the focus has shifted to 0.5 series in the past 2-3 months
<pinkflames[m]> marler8997: no, here not that long ago
* dv_ is curious how much will change in 0.5
<pinkflames[m]> I cry at the thought that 0.5 was supposed to be out and I'm not sure what I should tell next time someone wants to develop against 0.4 :(
<marler8997> I don't see anything from Wim since yesterday when I joined
<pinkflames[m]> marler8997: ugh.... what?
<kaira[m]> Hi, I was using Pulseaudio on Debian Testing. My setup is generally Android/IOS Bluetooth -> Debian Testing -> Bluetooth headphones. This used to work on Pulse. I moved to Cinnamon and it is using PW Wireplumber. I am unable to get audio to my headphones when the audio sent over a2dp from IOS.