[02:34] * OvenWerks doesn't know LSP plugs...looking [02:36] maybe we can get people to likke those over calf ;) [02:41] OvenWerks: Perhaps, but they're still missing some features that Calf has. Also, Calf is actively working on their own toolkit as to not depend on GTK, so that might help. [02:42] That said, I might get to work on pulling their code and what falktx has in terms of packaging and cleaning that up. [03:06] Eickmeyer: LSP... what is the difference between "leftright" and "stereo"? [03:07] OvenWerks: That's a question to which I don't have the answer. I can only assume it's the difference between dual mono and stereo processing, but I don't really know. [03:07] My first thought was that for stereo one set of knobs would control both channels but that doesn't seem to be the case [03:08] I don't see a chanel lock or anything and the leftright has balance too. [03:08] I'll have to investigate. I have yet to install for myself. [03:08] Crazy busy weekend with my son's birthday and all of the shenanigans with that. [03:10] Might be worth asking in #lad. [03:14] just figured it out [03:14] stereo does seem to have one control for both channels [03:15] That would make sense. Means LeftRight is dual mono. [03:15] leftright is two independant eq sets... left and right can be EQed differently but stereo can't [03:16] stereo is two, but with linked controls [03:16] s/two/too/ [03:17] Naturally.. Just in my experience, two independent channels are referred to as dual mono. That might be my video production experience talking. [03:18] * OvenWerks video production experience is very old.... 1980 to 1984 or 5 [03:19] All analog [03:20] Video recorded on 2inch quad or 1inch helical. [03:23] Eickmeyer: in a plugin case, rightleft makes sense as a plugin either sits in a mono strip/route or a stereo strip/route. So a 2 chanel strip/route is stereo program material not two mono channels. With a hardware two channel EQ one side may be used for drums and the there for a guitar [03:23] s/there/other/ [03:25] OvenWerks: Yeah, that makes sense. [03:26] have you been watching LAC at all? [03:27] LAC? (in other words, no.) [03:27] linux audio conference [03:27] There are two days left [03:28] I got yesterdays, but missed most of todays [03:28] That must be what rgareus and falktx were talking about. [03:29] https://lac.linuxaudio.org/2019/ [03:29] ya, #lac2019 in irc [03:30] there is a group in cbase berlin (I think) watching remotely the video stram. [03:30] stream [03:30] The video stream is picky, vlc works though [03:31] Cool. I might have to jump-in tomorrow. [03:31] You can ask questions via irc. [03:32] I found out AVB is a cpu hog... at least the way https://lac.linuxaudio.org/2019/doc/kuhr.pdf [03:33] these guys do it [03:34] They are doing 6 frame packets... very low latency. 16 is 2/3ms [03:34] Perhaps now, but if they can whittle it down and optimize it, perhaps it'll be better in the future. [03:35] Ya, I think I would go for the 12 frames to see if that was better [03:35] Yeah, that's zero latency for all intents and purposes. [03:36] There is a 1ms mode (aes67 standard) which I would tend to use. [03:37] I agree with that. I reallllly want to see something replace Dante. [03:37] Dante will now connect to aes67 [03:38] Well, that eases the transition, certainly, but Audinate has kinda had the market cornered on that concept for all too long. [03:39] I absolutely abhor it being proprietary / without Linux support. [03:40] there is an alsa ase67 driver... but it is not that nice, it needs work... the jack backend the link above has would work great for aes67 as a jack client. [03:41] Indeed. [03:42] the nice thing about using jack client is being able to change network routing or number of channels without stopping jack. [03:42] The backend just supplies the media clock [03:43] (from avb/aes67 network master clock) [03:45] Some projects I would like to see (or do): [03:46] I would've used that to implement multi-track recording across a network. [03:46] - pulse-jack bridge upgrade (make it look like a device [03:47] - a bluetooth audio jack client using libzita-src [03:48] - jack avb and aes67 clients [03:49] - make one of the pins of an intel i210 enet card have wordclock/spdif sync out from avb/aes67 media clock [03:50] Those would all be super useful. [03:50] Eickmeyer: yes, it would be easy to add new inputs with extra avb boxes when needed. [03:55] The last one is so I could still use my internal audio card in sync :) [03:55] (it will sync to spdif) [03:58] Honestly, it sounds like something we've needed for a long time to happen. [03:59] pulse-jack was only ever an example pulse plugin [04:03] Well, exactly, and the buffer it requires causes way too much latency. [04:04] I forgot to add putting gui stuff for tablets in -controls [04:04] Oh yes. Definitely. [04:05] pulse should not share the same buffer size as jack, but the bridge forces that. [04:05] Exactly. That's the sucky part. [04:12] Then there is the digital video audio lines (HDMI?) which wants jack set to 8192 [04:13] I don't know if zita-ajbridge deals with that well at all [04:19] Yeah, that seems weird. I don't know enough about how audio is sent over HDMI. [04:22] Eickmeyer: video is more latent than audio. frame rate of 60hz 166ms [04:22] so audio is probably sent at a similar rate... the audio card in part of the gpu [04:23] OvenWerks: Indeed. At my former job, we worked with a lot of BlackMagic Design hardware and SDI. Introducing a frame (1/30 sec) of latency was something we'd try to avoid. [04:23] When encoding for IP broadcast we'd have to take the audio from the mixer and inject it into the video stream, adding a compensation delay. [04:24] yes, but obviously any syncing is is to the nearest frame [04:24] Right. [04:25] if there are two video streams out of sync frame storage is the only thing. [04:25] Yep. A delay anywhere meant a delay everywhere. [04:26] Of course, when doing IP broadcast it was to a remote IP DVR, so we weren't worried about that so much as we were making sure the recording on the other end was nicely synced. [04:27] Standard SR for audio with video is 48k... they can pull that from chroma (in the old days) [04:35] I'm pretty sure it's still 48k, but the audio is sent as a digital track now not relying on the chroma. ATSC is worlds apart from NTSC. [04:36] They can push 96k afaik. [04:37] 12G SDI is where it's at though. 4k video and audio via a coaxial cable. [04:38] Of course, it's limited to 300 feet, but for live video that's pretty good. [04:39] And then there's repeaters that can be implemented, but that's where latency can become an issue. [04:40] I've done audio for 25 years, but my video knowledge and implementation tends to be stronger for whatever reason, and I've only done that for about 16 years. [04:53] is sdi still 8 audio streams? [04:54] hdmi is these days [05:08] OvenWerks: 12G can do up to 16, I believe. [18:44] Rosco2: o/ [18:45] I just sent an email. Carla is in the archive, feel free to remove jack-rack and add carla to the seed at your earliest convenience (ASAP since today is beta freeze) :) [18:46] I was just looking at carla [18:47] We have a build failure on arm which will prevent 2.0.0 getting out of proposed [18:48] Might want to try -- --disable-sse2 or something on the auto-config override conditional on ARCH=armhf [18:49] will do the seeds now [18:50] Rosco2: Not true, it's out of proposed. vorlon made an exception. [18:50] yes - for 1.9.13 - not 2.0.0? [18:50] As a rule for the package. [18:51] Either way, he's aware. [18:51] Maybe ask for the same exception? [18:51] I'm on it. [18:52] If disabling the sse flag doesn't work, we could just not build for arm [18:52] vorlon: That failure won't prevent it from migrating from propsed will it? [18:52] Eickmeyer: no [18:52] OK [18:53] So, an arm failure isn't a blocker in this case. [18:53] what matters for migration is not regressing the set of supported archs [18:53] Got it. [18:54] Anyway - we can try and fix it in Debian. [18:54] True. [18:54] Either way, that's going to be the 2.0 release. I did a whole new tarball for it. [18:57] Let me know if you want me to sponsor an upload to Debian for you [18:57] Then you will have your first upload there. [18:58] :-) [19:03] Rosco2: Will do. I think my next big project is going to be the lsp-plugins. [19:06] Eickmeyer: midizap looks good [19:07] OvenWerks: Indeed. I was looking for something with that functionality at my previous job.