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