WEBVTT 00:00.000 --> 00:12.120 So, good morning, it's a pipe wire talk, I'm been tired months, I'm been working on pipe 00:12.120 --> 00:29.200 wire for 10 years now, sponsored by Red Hat, so what is pipe wire for you, don't know, it's 00:29.200 --> 00:36.520 a low level layer for sharing multimedia on your desktop. 00:36.520 --> 00:42.480 So first of all, sharing of multimedia, which means audio, video, and all of that, but then 00:42.480 --> 00:50.440 also later processing, audio processing and other stuff. 00:50.440 --> 00:56.480 So it started basically as a way of sharing video from Wayland, because that wasn't supported 00:56.480 --> 00:57.960 natively. 00:57.960 --> 01:06.360 So then a scheme was developed to transfer video frames from one application, the window manager, 01:06.360 --> 01:14.320 to other applications, the consumers via IPC, and then it was invented that you could also 01:14.320 --> 01:21.080 use these four webcams, because currently webcams on that desktop, most browser go directly 01:21.080 --> 01:28.680 to the kernel with IOCTLs, it doesn't work so well for newer cameras that deal a little 01:28.680 --> 01:31.160 bit more setup and so on. 01:31.160 --> 01:41.040 So these things were retot 10 years ago, and that's how it started later on, audio was added 01:41.040 --> 01:46.560 and it became big. 01:46.560 --> 01:54.840 So a little overview of what's currently happening with pipe wire, so it's sitting there 01:54.840 --> 02:00.360 is basically just passing around multimedia between a whole bunch of applications and 02:00.360 --> 02:04.680 services that there are. 02:04.680 --> 02:11.800 So you have video apps, you have audio apps, there's also professional audio apps that 02:11.800 --> 02:15.840 used to go through a different audio server back in the day. 02:15.840 --> 02:24.000 You have window managers, all the things on top, media players, VLC, G-Streamer, that all 02:24.000 --> 02:33.960 needs some way of accessing cameras, Bluetooth devices, also devices and so on. 02:33.960 --> 02:38.240 Underneath that for the kernel, you have a couple of services and libraries that are used 02:38.240 --> 02:49.480 like also, lip camera is a new library for accessing cameras, specifically for more complex 02:49.480 --> 02:54.160 cameras that have processing units and so on. 02:54.160 --> 03:00.400 So you can't really go directly anymore to the kernel to get your camera things and 03:00.400 --> 03:03.800 expect to work these days. 03:03.800 --> 03:10.520 Then there's also the Bluetooth services, which traditionally on Linux, used Bluetooth, 03:10.520 --> 03:13.880 which is basically a debug service. 03:13.880 --> 03:21.080 So all of that needs to be made available to applications in some sort of API, so traditionally 03:21.080 --> 03:30.360 we have pulse audio doing nothing and the whole separate thing for pro apps which jack. 03:30.360 --> 03:39.360 So popular is basically the common denominator of all these things to pass around this 03:39.360 --> 03:41.840 data. 03:41.840 --> 03:51.480 So basically an application of sorts would make a note in a draft, so it's all graph based. 03:51.480 --> 03:56.800 Data flows from one component through a couple of links to another component of two 03:56.800 --> 03:58.720 whole bunch of things. 03:58.720 --> 04:06.720 These components can be applications or devices or enemies you want. 04:06.720 --> 04:11.440 So it's built a generalization of what pulse audio did. 04:11.440 --> 04:19.040 It's very similar to what jack did, but not also extended for video and audio. 04:19.040 --> 04:24.920 So yeah, 24 was 1.2 release. 04:24.920 --> 04:35.440 So last year I talked about 1.0 release, which was basically a BI stable, all of the features 04:35.440 --> 04:37.800 baseline features implemented. 04:37.800 --> 04:42.080 So in 1.2 we just continued doing that. 04:42.080 --> 04:48.440 So couple of things that are new in that release. 04:48.440 --> 04:56.600 So in the 1.0 version you could have that if one of the processing blocks didn't respond 04:56.600 --> 05:02.400 in a graph everything would stall because basically you give it data, pipeline will wait until 05:02.400 --> 05:06.320 it says I'm finished and then we'll go on processing the next block. 05:06.320 --> 05:13.880 So if you block one part in a graph the whole thing doesn't finish to completion. 05:13.880 --> 05:19.640 So you can have this situation where you can control v and up pause it and things just 05:19.640 --> 05:22.760 don't work anymore. 05:22.760 --> 05:26.680 The only way to fix that is to add delay latency. 05:26.680 --> 05:34.160 So you start the processing of the app, but you use data from the previous cycles that you 05:34.160 --> 05:35.160 schedule it. 05:35.160 --> 05:39.840 If you didn't do anything then it's just silence, but you give yourself enough time to be 05:39.840 --> 05:45.360 able to handle the fact that it's not doing anything. 05:45.360 --> 05:52.000 So asynchronous processing I don't know we don't really activate it yet because it's 05:52.000 --> 06:00.160 I mean it's a real problem, but it's not very I mean don't really get to it very often. 06:00.160 --> 06:04.760 But theoretically we could do it for flat-park apps so that they don't block audio, but 06:04.800 --> 06:11.400 it's really like a very theoretical case. 06:11.400 --> 06:17.480 Apps that don't work people just usually don't run them. 06:17.480 --> 06:21.080 Most apps they work fine. 06:21.080 --> 06:28.360 So I was going to show this but then I realized that the only thing to actually show it very 06:28.360 --> 06:36.760 well is with a jack client, but the jack simple client doesn't really do what I need 06:36.760 --> 06:41.240 to do and then I'll make it a virtual device but that doesn't work either. 06:41.240 --> 06:48.040 But anyway you could run for example two jack clients if they come back to the right sync 06:48.040 --> 06:55.000 which they don't buy default, they can stall things and you can manually set the property 06:55.080 --> 07:02.040 to true with some properties and then it will be in asynchronous but it will have a delay 07:02.040 --> 07:06.680 but you won't really notice it normally but at least it won't block everything. 07:09.080 --> 07:14.680 So jack used to have something like that but system wide so all of the things would be delayed. 07:14.680 --> 07:20.280 In part where you can select one specific app that is yep I have a question. 07:20.280 --> 07:29.080 And because you will block in client, block everything that is somehow connected to it 07:29.080 --> 07:33.640 or will it only block something that's where data flows through it. 07:33.640 --> 07:39.960 So the question is if a client doesn't process in the graph will it block everything 07:39.960 --> 07:45.320 or only the things it's connected to? So only the things it's connected to is the answer. 07:45.320 --> 07:55.480 So if you have two media players they go to a sync and one is blocking the other one will still go 07:55.480 --> 08:00.840 through. But if you have for example two media players going to a filter going to a sync 08:00.840 --> 08:06.120 then one will block the filter and it will also block the data transfer for the other. 08:06.120 --> 08:13.320 So our components in the middle there will be blocked. So that's what this could fix. 08:13.400 --> 08:21.080 So this for example is by default for things like pulse audio. So all the pulse audio apps 08:21.880 --> 08:27.160 that currently use the pulse audio API they are already a sync. It's slightly different 08:27.160 --> 08:36.520 but they will never block anything in in part where. So you need to have jack apps or native apps 08:36.520 --> 08:42.680 that can do these bad things. So it's already a very small part and the same thing 08:42.680 --> 08:49.000 if you have the jack app that was means behaving it will also not work with jack for the same reasons. 08:54.360 --> 09:01.240 Yeah, I'm not a trailer execution. The 1.0 or single threaded. But now it's multi-treaded. 09:02.120 --> 09:08.840 Also I'm not activated by default because we don't really know exactly if it's interesting to do this. 09:09.800 --> 09:14.840 But I know some people you can manually configure it and then some people they wanted to 09:14.840 --> 09:20.200 separate the threats for audio and video and give different priorities and have different kinds of 09:21.320 --> 09:32.040 things and pin threats to CPUs and all of that. You can do that but it's not really activated by default on desktop. 09:32.040 --> 09:38.600 I'll wait a bit until more people suffer. 10:02.040 --> 10:31.960 So these things, these features were added because some of the 10:31.960 --> 10:38.280 asks for them not exactly because we're going to activate them for everybody but if you want features 10:39.560 --> 10:48.520 you can suggest them. There's always a possibility that they are easy or that they make sense 10:48.520 --> 10:56.440 to implement and then they will be implemented. So the goal of starting is stopping things in the 10:56.440 --> 11:04.440 graph has been refined a bit so that it causes less glitches things like that. So it's more like 11:04.440 --> 11:10.440 a continuation of what we've been doing, making things a bit better. So for example, 11:11.720 --> 11:21.720 one of the things that are still ongoing is flappack security context. So one of the ways for doing 11:21.720 --> 11:29.880 security currently in Pyquires by using a portal. So if you I'll show you that later. 11:30.920 --> 11:35.640 If you for example go to a web browser and access the camera, you will see some pop-ups 11:36.840 --> 11:45.080 asking you for permission to access the camera. This also sounds very trivial but this is a new thing in Linux. 11:45.560 --> 11:52.920 It's using a portal to get access to the permissions of the browser and so on and then make 11:52.920 --> 11:58.360 a connection and make a secure context where the user can only access the cameras that have been 11:58.360 --> 12:05.320 allowed and so on. And there's another way of doing things with Whalen which is called the security 12:05.320 --> 12:12.680 context where a flappack would be given a Whalen socket or in this case a Pyquires socket 12:12.760 --> 12:18.360 which restricted permissions. So that would make applications work a bit more transparent because 12:18.360 --> 12:26.840 they just use Pyquires to access things instead of asking a portal to do things. But these things 12:26.840 --> 12:37.400 are in in the works. Don't actually use them yet. So also an ongoing thing that is 12:37.400 --> 12:44.120 getting there and I think we finally have an idea of what should happen which is the video 12:45.640 --> 12:51.880 processing pipeline. So the audio processing is pretty much figured out. The video part 12:51.880 --> 13:04.040 not so much like one of the things for example is I did this here. So if you for example have a 13:04.040 --> 13:14.040 normal, a newer distro and newer browsers all over the camera stuff will basically go to 13:14.040 --> 13:20.520 Pyquires. So there's a little tool you can use. PW top that should show you and it doesn't. 13:21.480 --> 13:37.960 Maybe I did something wrong. Maybe it's going to the fall back. I should have checked that. Anyway 13:39.560 --> 13:44.040 it's probably going to the fall back here. Maybe I can restart it. Oh this is chrome yeah I shouldn't do 13:44.040 --> 13:55.080 this chrome. And I have some extra time. See if I can get this 13:58.600 --> 14:11.960 yet some very happy. So well there's a thing where you get first an access thing from 14:14.840 --> 14:23.160 the browser itself which camera you want to allow. I probably already said yes to this from the portal. 14:27.160 --> 14:36.600 There we are. So you'll see Firefox is now accessing the camera through Pyquires 14:37.320 --> 14:44.840 and as you can see here from this format things is that it's using mjpec. So this is the thing 14:44.840 --> 14:53.880 with the cameras. You can use higher resolutions if you ask for compressed format because of 14:53.880 --> 14:59.880 bound with issues. The problem then is of course if you want to share the same screen or stream 14:59.880 --> 15:06.200 with another application that doesn't understand mjpec then things don't work automatically. 15:07.400 --> 15:14.360 So you need some way of converting the formats into one comonical format that everybody can consume. 15:15.400 --> 15:22.040 So the question is do I add decolors to all applications or do I decode before sending it into 15:22.760 --> 15:31.960 Pyquires and see if I do I have this up here or do I have help them? 15:38.840 --> 15:45.720 Those are haven't seen this yet. So you can also make a graph of whatever is running 15:46.120 --> 15:52.280 in Pyquires and if you use something that is not jack you will also see videos stuff. 15:53.800 --> 16:01.400 You can actually drag video connections to other video apps but it's all a little bit wonky still 16:01.400 --> 16:06.840 because in this case for example it would be mjpec that would be shared and you need an update also 16:06.840 --> 16:19.960 to understand some jpec. So the current plan is to actually add the decoder to the camera part. 16:19.960 --> 16:25.640 So before it goes into Pyquires decode everything so you can still get the high frame rates 16:25.640 --> 16:31.720 because it's captured as on jpec and everybody can consume it because it's already decoded date. 16:32.360 --> 16:44.680 So that is something that we're still moving to. So for that we would like to use 16:46.520 --> 16:53.800 accelerated stuff to do that especially for format conversions. So usually if you do a jpec depression 16:53.880 --> 17:01.560 compression is software you end up with some yuv format if you want converter to RGB 17:02.920 --> 17:09.560 you would like to do that with welcome instead of also software. So how do we get to those pieces in 17:09.560 --> 17:20.360 there it's ongoing. So another thing we're working on is explicit think. What is that? 17:20.360 --> 17:27.480 Well it's something Nvidia specific if I'm not mistaken. So basically when the composer 17:27.480 --> 17:34.040 renders the video frame it sends all of the commands to render the thing to the graphics card. 17:35.640 --> 17:40.840 What you usually then do as a composer is wait until everything is rendered and then tell the 17:40.840 --> 17:48.120 client okay here's a video thing that are captured. We'd explicit think what you can do is send it 17:48.360 --> 17:54.920 to the graphic card and set the checkpoints or a timer and then you send everything to the client 17:54.920 --> 18:00.280 wait for this timer to go off and then you can read the frame. So then you can already bump a whole 18:00.280 --> 18:06.520 bunch of things to the client the client can put all of these processing that it will do on the 18:06.520 --> 18:13.560 frame in the heart we're already synchronized on that sync point and then things get a little bit 18:13.640 --> 18:22.120 smoother. So in pipeline that involves something over a couple more of these and a couple more 18:22.120 --> 18:33.400 method data to get this working. Yeah so more Bluetooth codex so for Bluetooth for example 18:33.400 --> 18:40.760 interesting bits and for the next version there's some more coming up but there's also an 18:41.560 --> 18:49.080 opus codec that you can use or Bluetooth and there are actually two versions of them. So in one point 18:49.080 --> 18:58.200 zero pipeline we implemented our own version the time Google came out with another spec so now we have 18:58.200 --> 19:09.400 two two versions of the spec Google Opus and pipe wire Opus. So if you have if you have a Bluetooth 19:09.480 --> 19:16.920 device that understands Opus which I don't know you do probably not then you can use this but 19:16.920 --> 19:25.720 it's more interesting of course because you can you can make pipe wire act as a Bluetooth consumer 19:26.520 --> 19:32.360 or produce you can link two pipe wire desks up together and send Bluetooth between them. So then 19:32.360 --> 19:42.520 you can use any of the codex of course. Yeah something else that we're working on lazy scheduling. 19:42.520 --> 19:51.080 So what is that? Some people use the compositor to just fetch frames and then display them 19:53.080 --> 19:58.840 locally on their machine so you basically need to fetch frames at the refresh rate of where you're 19:58.920 --> 20:06.280 going to display them, not where they are generated. So there's a way in pipe wire for a client to 20:06.280 --> 20:14.840 fetch more frames and not fetch needlessly but only when there's actually something new on the server. 20:14.840 --> 20:20.360 So there's a communication way between server inclined or there's a new frame client can start 20:20.360 --> 20:28.760 the graph, pull the frame and all of that. There's some inversion of logic of who becomes the 20:28.760 --> 20:35.640 master and who becomes the driver of the graph and all of that but this is going to be used in these 20:36.760 --> 20:50.280 scenarios. So more things now where we are. So cameras are moving to pipe wire as well. 20:50.360 --> 20:55.160 So in firefox it's already done. Don't exactly implement this in firefox but in web 20:55.160 --> 21:02.520 party C and that piece of code should be shared with a Chrome. So eventually it will find its way 21:02.520 --> 21:17.960 in Chrome as well. Yeah that's the answer. Not an L by default yet but it will at some point 21:17.960 --> 21:25.400 be I guess. So this is good because then we can move everything of the camera handling to lip camera. 21:26.200 --> 21:34.120 We can also start sharing the cameras. We can also add permissions for new in the access control 21:34.120 --> 21:43.000 a little bit more fine grain but most important things newer Intel ships. You can't just 21:43.720 --> 21:49.560 get the frames easily. You first need to configure it to media control the whole pipeline of 21:49.560 --> 21:55.800 the camera and the processing units before it actually wants to do something. So firefox by default 21:57.160 --> 22:03.720 wouldn't work on that. So by switching to lip camera and pipe wire you make this work. 22:03.800 --> 22:17.880 Matter. Yeah so 1.4 is almost done. I made a pre release a couple of weeks ago. 22:20.600 --> 22:29.240 Yep so what else is there to do? Not so much but we have media too. 22:30.200 --> 22:39.400 So media is very old. It's used for synthesizers to send the notes that you do on the 22:39.400 --> 22:47.640 synth over a wire to a computer but these days it's mostly also used for triggering samples and 22:47.640 --> 22:55.640 doing interactive stuff. It's pretty good as an event mechanism and there's a new spec out 22:56.280 --> 23:01.560 which adds more resolution to the pressure of the keys and you can use 23:02.840 --> 23:09.960 non-standard tunings and all of these things. So there's also a new media format in the kernel and it 23:09.960 --> 23:16.920 was added and those are people they'll all work to make that work. So nobody was using it so 23:17.560 --> 23:26.840 finally we have a use for this. So basically we have everything in pipe wire now doing with 23:26.840 --> 23:36.440 media is now implemented as the media 2 standard which is a packet form of called UMP universal 23:36.440 --> 23:44.040 media protocol or universal media packet I think it is and you can just package standard media 23:44.040 --> 23:55.000 or the newer version of media in it. So it's not too hard difficult to change the alls iAPIs to 23:55.000 --> 24:01.400 use this. But we do a conversion between older and newer things it's quite trivial with these things 24:01.880 --> 24:07.320 but it needs some time to figure out who converts what and all the possibilities. 24:07.480 --> 24:21.560 What do you have as a concrete benefit with this don't know because the media 2 devices themselves 24:21.560 --> 24:35.160 they don't really exist or they are very expensive. We'll see. So together with this there is also 24:35.240 --> 24:41.080 an extension for the jack API. So most of the media tools that you can use on Linux today use the jack 24:41.080 --> 24:51.800 API. So there's an extension for them to also use media 2. So hopefully this will become a thing. 24:54.360 --> 25:01.720 So more of the video conversion that I talked about there's some experimental stuff we have 25:01.800 --> 25:09.880 come back to convert stuff especially for the coding of jpec frames and all of that we use that 25:09.880 --> 25:17.960 it works. Not enable by default but I think one of these next three is we will do that and then 25:17.960 --> 25:27.560 you get the better use case for using videos currently it's not very flexible 25:31.880 --> 25:42.200 you know this is I can actually try this let's see what happens to show you what i'd still 25:42.200 --> 25:53.640 running here the camera are great. I think i can can i i have to stop the slides 25:54.120 --> 26:03.560 so usually if you do for example something like this there's an example program 26:06.040 --> 26:18.600 where am i gonna do this here. There's an example program here to take a frame or video source 26:19.560 --> 26:26.840 maybe i should enlarge this i 26:37.240 --> 26:44.120 called video play you can run it's unfortunately 26:45.080 --> 26:58.040 oh i don't see anything of course so unfortunately the tool can only display a compressed 26:58.040 --> 27:08.600 formats so because the camera is now using use already with by Firefox doing mjpec this thing just 27:08.600 --> 27:18.040 fails to connect or do anything so with this thing here putting a video converter there 27:20.040 --> 27:24.040 i'm pretty sure that i probably need to do something else here 27:28.680 --> 27:35.160 i probably don't have this compiling i should have tried this anyway what you could have done there 27:35.240 --> 27:42.200 is insert the video converter and then have the client consuming the thing 27:44.280 --> 27:50.600 converting it to something it does understand this is not exactly what we want to do in the end 27:51.320 --> 27:58.040 we want to have only uncompressed video in the end like we do with audio 28:05.240 --> 28:19.960 okay so some of the else that we've been doing so one of the questions or use cases that people 28:19.960 --> 28:31.160 have is okay i want to add an equalizer to all of my output or some sort of processing or for 28:31.160 --> 28:37.800 example for my camera or microphone i want to add noise suppression something global 28:39.720 --> 28:44.680 the way you should do that right now and we have been doing a whole bunch of things 28:45.480 --> 28:51.880 to make that work is by inserting inside the graph in front of the the things 28:53.000 --> 28:55.880 or so after the sources processing note 28:55.960 --> 29:04.360 the problem is you need to have everything go through that both processing no buy pass it 29:04.360 --> 29:09.960 because then you lose the advantage of the filter and if it's something that is mandatory like 29:09.960 --> 29:19.080 limiting the volumes so that you don't blow the speakers it's not so very safe if you can buy pass it 29:19.160 --> 29:30.120 so another idea that that was brewing was adding arbitrary processing in all of the notes 29:31.320 --> 29:38.200 you need to understand a bit of things work for that so if you have pipe wire the basic IPC 29:38.200 --> 29:44.440 for sharing audio you have something that produces the audio or the audio in this case and 29:44.520 --> 29:50.360 something that consumes like for example and also sync and you have an app that produces audio 29:52.280 --> 29:59.960 the component of the pipeline provides called a stream and internally it has a little pipeline 30:01.000 --> 30:06.440 of stuff that needs to happen like format conversion because most apps and i don't know 30:06.440 --> 30:13.400 16 bit of something we need to convert that to something that is understandable for 30:14.280 --> 30:22.040 the graph it needs to be an example and all of these things if necessary or maybe even up or 30:22.040 --> 30:30.360 done mixed so we had already a little graph pipeline of things that needed to happen so now 30:31.640 --> 30:37.560 there's another thing you can add there which is a filter graph which is an arbitrary processing 30:37.640 --> 30:48.440 you can perform so you can do this almost for itself or directly in the sync so there's a good place 30:48.440 --> 30:57.720 to upload for example equalizers or noise suppression and your guarantee to always have these 30:57.720 --> 31:05.720 active they're not bypassable by making links in a graph currently not used yet but 31:07.560 --> 31:13.560 i'll can show a little demo for what that could be so a filter graph you currently have to use 31:14.360 --> 31:20.760 something like this to specify what happens but you can say a couple of for example lots pop plugins 31:21.640 --> 31:29.880 for peak detection and a limiter for example you can define those notes you can link them together 31:30.440 --> 31:36.200 the output of this into that and then the inputs and outputs of the whole graph 31:37.720 --> 31:42.120 and the inputs of that and the outputs of that so it's a little too component 31:43.160 --> 31:48.360 filter and you can upload that anywhere and it will apply these effects 31:49.160 --> 31:58.680 so what can you do with these things we have we have this already in a module but now it's more 31:59.720 --> 32:07.080 generalized you can also use it in all places so there's a whole bunch of things you can do 32:08.520 --> 32:13.320 except for the lots pop plugins or the other two plugins there's some built in things too 32:13.880 --> 32:22.200 so for example you can upload this like this i'm going to try to show that as well 32:26.280 --> 32:32.680 so for any of the notes you can set the property with this with the filter graph you can 32:32.680 --> 32:38.840 up up to nine of them with the definition this is a very stupid one with just one filter 32:39.400 --> 32:46.840 and it's complicated twice for stereo and I see if I can make this work here 32:56.600 --> 33:02.840 so I'll see if I can make this bigger as well 33:03.320 --> 33:09.320 come on 33:20.040 --> 33:28.200 so a little bit of demonstration here what you can see so if you have this thing 33:29.160 --> 33:41.640 usually I have one note here the player this is the the little player thing it 33:41.640 --> 33:48.040 it goes to a default sync which is now set to this virtual sync here a loopback device 33:49.720 --> 33:56.200 so this has an input and also an output they are not very linked together here in this graph 33:56.200 --> 34:06.040 but here is the output and that's an eventually goes into the hardware which is this headphone 34:06.040 --> 34:13.240 things so you have a bunch of notes and these things the sync here and the loopback things and 34:13.240 --> 34:23.320 all of these things are all streams so you could you could have a look after that for example 34:23.400 --> 34:33.400 the tools we use for this it's a PW top so here's the player you can now inspect a little bit 34:34.200 --> 34:40.840 what form of cities using natively those are these filters the loopback filters and that's the 34:40.840 --> 34:46.360 output device they have a number as well an idea 34:46.680 --> 34:55.400 so you could for example now say let's say this one which has 61 was a number 35:01.800 --> 35:05.080 I have this in my history 35:05.880 --> 35:17.160 I don't know if you're gonna hear this but now there's a flanking effect on it 35:22.600 --> 35:24.680 you can remove the filter again of course 35:24.680 --> 35:38.120 oh this is off a spec 35:41.080 --> 35:49.080 still wrong 61 and now I'm still with my bracket for 35:49.320 --> 36:10.360 oh no 36:10.360 --> 36:23.360 So this is something I don't know. 36:23.360 --> 36:28.360 It doesn't change the graph, so I think it's better. 36:28.360 --> 36:31.360 But you can, for example, also do other things. 36:31.360 --> 36:35.360 Like you can insert the filter in the player itself. 36:35.360 --> 36:38.360 It doesn't have to be the sink. 36:38.360 --> 36:43.360 It doesn't work for video yet. 36:43.360 --> 36:55.360 So it would be nice if all of these things would, of course, work for everything. 36:55.360 --> 37:02.360 Yeah. 37:02.360 --> 37:10.360 The pool. 37:10.360 --> 37:12.360 So what's next? 37:12.360 --> 37:13.360 What's up coming? 37:13.360 --> 37:15.360 Why doesn't this go away? 37:15.360 --> 37:16.360 Go away. 37:16.360 --> 37:17.360 No. 37:17.360 --> 37:19.360 Does it want to escape? 37:26.360 --> 37:27.360 Oh well. 37:27.360 --> 37:31.360 So what's up coming still for Bluetooth? 37:31.360 --> 37:35.360 So there's an hearing aid support finally. 37:35.360 --> 37:38.360 There are some standards for that. 37:38.360 --> 37:43.360 One of them is Asha, which is supported by Google. 37:43.360 --> 37:46.360 You have a supported hearing aid. 37:46.360 --> 37:49.360 You can connect to it's private protocol. 37:49.360 --> 37:50.360 What private? 37:50.360 --> 37:52.360 It's a specific protocol. 37:53.360 --> 37:58.360 There's also something more standard to upcoming for Bluetooth, L.E. 37:58.360 --> 38:01.360 Oh, thumbs up. 38:01.360 --> 38:02.360 Yeah. 38:02.360 --> 38:05.360 We fix bugs and things will work better. 38:05.360 --> 38:07.360 Quick questions. 38:07.360 --> 38:16.360 Quick questions. 38:16.360 --> 38:20.360 Quick questions. 38:20.360 --> 38:22.360 Four minutes for questions. 38:22.360 --> 38:27.360 Yes. 38:27.360 --> 38:39.360 Do we have an external party with sampler or do we have our own? 38:39.360 --> 38:42.360 Yes. 38:42.360 --> 38:48.360 How can we use a private protocol? 38:48.360 --> 38:49.360 Yes. 38:49.360 --> 38:53.360 How do you make part why I put two multiple headsets? 38:53.360 --> 38:58.360 Well, the easiest thing is to draw a line. 38:58.360 --> 39:04.360 You know, from your output application, you drag your line to another sync. 39:04.360 --> 39:07.360 And then it will play on two at the same time. 39:07.360 --> 39:10.360 You can really do it because I want to have one. 39:10.360 --> 39:17.360 You can also make a more automatic by using a filter that will automatically do that for you. 39:17.360 --> 39:19.360 Yeah. 39:19.360 --> 39:24.360 If you use a loop package device, that's like an introduced latency. 39:24.360 --> 39:25.360 No. 39:25.360 --> 39:29.360 So all of the notes normally in the graph produce no latency. 39:29.360 --> 39:34.360 So there is the start of the also device that says our 1,000 samples. 39:34.360 --> 39:37.360 1,000 samples are gotten from the player. 39:37.360 --> 39:40.360 1,000 samples given to loop back they come out. 39:40.360 --> 39:42.360 And then they go to the sync. 39:42.360 --> 39:44.360 And then the cycle stops. 39:44.360 --> 39:45.360 So it's loop. 39:45.360 --> 39:46.360 One go. 39:46.360 --> 39:48.360 Okay. 39:48.360 --> 39:55.360 How does pepper approach audio interfaces that have more than two channels? 39:55.360 --> 39:59.360 Because I've made the experience that the first two channels are taken. 39:59.360 --> 40:01.360 Because maybe stereo is expected. 40:01.360 --> 40:03.360 And the rest will need more. 40:03.360 --> 40:04.360 You have to configure it. 40:04.360 --> 40:05.360 Yeah. 40:05.360 --> 40:11.360 So how do you work with devices with multiple channels? 40:11.360 --> 40:18.360 So all of the configuration of the also devices is done with the old code from Pulse Audio, 40:18.360 --> 40:24.360 which sort of does auto detection of stereo and multi channel things. 40:24.360 --> 40:28.360 But it has its limitations and it doesn't find everything. 40:28.360 --> 40:34.360 In Papua there's also a pro audio mode, which basically just opens the also device and gives you everything. 40:34.360 --> 40:38.360 But it doesn't try to do anything fancy with volumes or mixers. 40:38.360 --> 40:40.360 It's just a raw thing. 40:40.360 --> 40:45.360 So if you talk about that and if you configure it in pro audio mode, 40:45.360 --> 40:50.360 we only assume the first two channels are stereo and the rest you don't know. 40:50.360 --> 40:55.360 So like for example, the session manager wire plumber will not root anything to the other ports, 40:55.360 --> 40:57.360 because it doesn't know how deep it is. 40:57.360 --> 40:59.360 Just assumes the first two are stereo. 40:59.360 --> 41:01.360 So if you want to give that a meaning, 41:01.360 --> 41:05.360 you have to place a sink in front of it, a stereo sink, 41:05.360 --> 41:09.360 and then route it manually to the other ports. 41:09.360 --> 41:11.360 Yeah. 41:11.360 --> 41:16.360 There is some work being done to automate that, 41:16.360 --> 41:21.360 because also has a configuration file where you can set these things, 41:21.360 --> 41:24.360 and then we can automatically generate something more sensible. 41:24.360 --> 41:27.360 But the config file has to be there, 41:27.360 --> 41:31.360 and it needs testing. 41:37.360 --> 41:38.360 Yeah. 41:38.360 --> 41:39.360 Thank you very much.