| OvenWerks | Eickmeyer: to use PW with jack as a device it seems I will have to use jackd with a wrapper. This means that jackdbus will not work, I think. | 18:35 |
|---|---|---|
| Eickmeyer | OvenWerks: Yeah, I seem to recall that I told Wim years ago about jackdbus being a thing and he was surprised. I don't think the API was ever implemented. | 18:36 |
| OvenWerks | jack_control or other dbus commands to start jack via jackdbus, tell the dbus system to auto start jackdbus | 18:36 |
| OvenWerks | I wonder if it is possible to prestart jackdbus manually | 18:37 |
| Eickmeyer | No idea. The question is, and maybe you've answered this, but what's the advantage of doing that vs using the pipewire implementation of jack? | 18:38 |
| OvenWerks | VIA doesn't stick around long enough for an answer. | 18:38 |
| arraybolt3[m] | I thought it was FireWire support. | 18:38 |
| * arraybolt3[m] may be far off track | 18:38 | |
| Eickmeyer | arraybolt3[m]: Well, one would have to switch to the old PulseAudio setup for that as well. | 18:39 |
| OvenWerks | yes, using jackd as a device allows using jack backends PW does not support | 18:39 |
| OvenWerks | Eickmeyer: no, it appears that is not true. | 18:39 |
| Eickmeyer | Oh, so that's news. | 18:39 |
| OvenWerks | It is a matter of working out the gymnastics to make things happen | 18:40 |
| OvenWerks | some things can be changed on the fly, other things have to be changed in a file and PW restarted. | 18:41 |
| OvenWerks | using pw as a jack client seems to require a restart | 18:42 |
| Eickmeyer | Complete system restart or pipewire.service restart? | 18:42 |
| OvenWerks | remains to be seen :) | 18:42 |
| Eickmeyer | Ah. | 18:43 |
| OvenWerks | the changes to autojack are significant to make this work. | 18:44 |
| OvenWerks | I am a long way just to do testing. | 18:44 |
| OvenWerks | A lot of the stuff I would normally do in autojack it seems might be best done in studio-controls, except for autostart things. | 18:45 |
| OvenWerks | There are a number of things I am not happy with in pipewire still... but they are not show stoppers. | 18:46 |
| Eickmeyer | That's good. | 18:47 |
| OvenWerks | I can set the default device to show in the jack graph as system:playback/copature_* but if we want a jack master as one device but a virtual device as default for desktop use (to redirect L/R to system:playback_9/10 for example) pavucontrol switching default from USB,0,0 to virtual will move the system: names to the virtual device as well :P | 18:50 |
| Eickmeyer | O_o | 19:04 |
| Eickmeyer | I'm not sure if it's because it's the day after Thanksgiving or if it's because it's a downpour outside, but my brain is having trouble groking that. I'm assuming that's a good thing. | 19:07 |
| Eickmeyer | I mean, I *know* that would make sense to me normally. LOL | 19:07 |
| OvenWerks | Eickmeyer: :) thats ok. I would like jack system or master device to be disasociated from desktop default. They are not the same thing really. | 19:22 |
| Eickmeyer | Right, but bridgable to desktop default would be nice, such as we can do now with PulseAudio. | 19:23 |
| OvenWerks | yeah. we can do that in a number of ways. we can make a loopback which has input ports and output ports which can auto connect to system:playback_15/16 (if thats where the speaker or headphone is) which is fine | 19:30 |
| OvenWerks | the desktop application can be manually sent to that loopback. This is fine. now we set the desktop default to that loopback and the loopback inputs are now renamed to system:playback_1/2 and the original system:playback_* are now M66:playback-AUX* | 19:32 |
| OvenWerks | but M66:capture_AUX* are still named system:capture_* | 19:33 |
| Eickmeyer | I see. | 19:34 |
| Eickmeyer | As long as it makes sense to the user, then I'm cool with it. | 19:34 |
| OvenWerks | well lets see, we want ardour to see our multi port device as system:* we don't want that to change. but we want desktop stuff to auto connect to system:playback_9/10 cause that is where the physical outputs are. | 19:36 |
| OvenWerks | but to playback a video on firefox, we start the video, ff connects to system:playback_1/2, we have to manually start pavucontrol and change the output of that stream to desktop:playback_L/R | 19:38 |
| Eickmeyer | So, pavucontrol, despite being PulseAudioVUControl, still works under PipeWIre? | 19:39 |
| OvenWerks | because if we change the desktop default to desktop:playback_* the name of output device changes in the jack graph and ardour now has only 2 outputs in stead of 12 or 16 or whatever. | 19:40 |
| OvenWerks | yes the desktop stuff still uses the pulseaudio api | 19:40 |
| OvenWerks | so pavucontrol still works | 19:41 |
| Eickmeyer | Yeah, that totally makes sense. | 19:41 |
| OvenWerks | (as do all the DE specific audio controls which use the same dbus calls) | 19:41 |
| Eickmeyer | So, what I'm thinking is this: default would be PipeWire + pw_jack. Studio Controls would then have a switch to change it to the setup you're designing. Is that what you have in mind? | 19:43 |
| OvenWerks | that sound like a different line of thought :) | 19:45 |
| OvenWerks | I think I will look at the system | 19:45 |
| Eickmeyer | Ok. Ruth had found an article that does the configuration, so a separate configuration for pw-jack needs to be done in order to make it start by default, which means a new package. | 19:46 |
| Eickmeyer | (some files have to be installed to /etc) | 19:46 |
| OvenWerks | if pactl info tells me that pulseaudio is supplied by PW then I set desktop to PW. if libjack is forwarded to pw then the whole system is PW (for both desktop and jack) | 19:47 |
| Eickmeyer | Right. But, there's an easy way to stop pw-jack, I just don't remember how off the top of my head. | 19:48 |
| OvenWerks | if pulse is not supplied by pw then we run pa/jack and make sure that libjack is not worwared to PW | 19:48 |
| Eickmeyer | I think it's a matter of removing that config file I'm talking about and then restarting pipewire. | 19:48 |
| OvenWerks | pw-jack can run all the time so long as jack clients can't see it | 19:49 |
| OvenWerks | pw internals are hard coded to see the pw libjack anyway. | 19:50 |
| OvenWerks | but yeah, it is not hard to get pw not to load the jack plugin. | 19:52 |
| Eickmeyer | I think I'd like it to load the jack plugin by default so people have something that "just works" out of the box, and then if they want a more advanced setup, studio-controls can do that configuration via the methodology you're describing. | 19:53 |
| OvenWerks | Eickmeyer: my thought had been to have three options: pa/jack, pw, pw/jack | 19:54 |
| Eickmeyer | Right, we were agreed on that from the start. | 19:55 |
| OvenWerks | The default should be determined by what the system runs by default. If pa is running then the default is pa/jack. if pw is running then pw works as both pa and jack | 19:55 |
| Eickmeyer | Yep, that's what I'm thinking. PW by default. BUT, FYI, on Ubuntu Desktop (Vanilla), the pw-jack plugin is not installed by default. Even if it's installed, it needs some configuration to be loaded at startup otherwise one has to run "pw-jack ardour {arguments}" for instance. | 19:56 |
| OvenWerks | depending on how well these different modes work.... My preference would be pipewire does it all with the possibility of jack as a device | 19:56 |
| OvenWerks | that is just a one file change/install and ldconfig (all sudo) | 19:57 |
| OvenWerks | I don't think a reboot is even needed | 19:58 |
| OvenWerks | (or a pw restart even) | 19:58 |
| OvenWerks | however, if pw/jack works better, I might opt for that. | 19:59 |
| Eickmeyer | You might be right. | 19:59 |
| Eickmeyer | pw/jack might work better in some situations, but it's a far more complex setup than pw alone. | 19:59 |
| Eickmeyer | From an end-user perspective. | 20:00 |
| OvenWerks | that I don't know at this point. first I need to be able to switch reliably from pa/jack to pw_alone and back. Then I can try more. | 20:01 |
| Eickmeyer | Fair. | 20:02 |
| OvenWerks | I would like to see what pw presents to jack as ports when running as a "jack client" | 20:02 |
| OvenWerks | If it shows all the devices pw can see, that could be a good thing. | 20:03 |
| Eickmeyer | Ah, sure. What I was thinking was, using PW alone, all Jack and PulseAudio clients simply present themselves in qpwgraph or patchance as individual clients irrespective of type. | 20:03 |
| Eickmeyer | That would be a huge boon to end users. | 20:04 |
| OvenWerks | yes. no zita-ajbridge needed | 20:04 |
| OvenWerks | or setup | 20:04 |
| OvenWerks | if pw just works then controls is not really needed. | 20:05 |
| Eickmeyer | One thing that is important, though, is that it still needs a buffer size and possibly a way to change sample rate. | 20:05 |
| OvenWerks | it will still provide some nice things in a gui, like being able to change the name of a device. | 20:05 |
| OvenWerks | the GUI will do that (the GUI being controls) | 20:06 |
| OvenWerks | pw has two names (well three) for every device. The desktop uses description, the jack graph uses description by default but can be set to use "nick". The there is the actual node name | 20:08 |
| Eickmeyer | That "nick" is convenient. | 20:09 |
| OvenWerks | The node name is unique.... and long. The nick can be set to something like "Daves_mic" | 20:09 |
| OvenWerks | if all devices in the system are allready unique (different manufacture or model) then the user can set both description and nick to something nice and short. | 20:11 |
| OvenWerks | Eickmeyer: in controls in the extra devices tab (now device info... or should it be settings?) there is a "jack base name" that will become the pw nick. I have added a description field as well that the user can change. | 20:13 |
| OvenWerks | also a pw profile selector. | 20:14 |
| OvenWerks | The pw profiles seem to be the same as the PA profiles, just copied to another directory. | 20:15 |
| * OvenWerks will have to learn profiles :P | 20:15 | |
| Eickmeyer | This could become, like, the ultimate PW setup utility. | 20:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!