* OvenWerks doesn't know LSP plugs...looking | 02:34 | |
OvenWerks | maybe we can get people to likke those over calf ;) | 02:36 |
---|---|---|
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:41 |
Eickmeyer | That said, I might get to work on pulling their code and what falktx has in terms of packaging and cleaning that up. | 02:42 |
OvenWerks | Eickmeyer: LSP... what is the difference between "leftright" and "stereo"? | 03:06 |
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:07 |
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:08 |
Eickmeyer | Might be worth asking in #lad. | 03:10 |
OvenWerks | just figured it out | 03:14 |
OvenWerks | stereo does seem to have one control for both channels | 03:14 |
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:15 |
OvenWerks | stereo is two, but with linked controls | 03:16 |
OvenWerks | s/two/too/ | 03:16 |
Eickmeyer | Naturally.. Just in my experience, two independent channels are referred to as dual mono. That might be my video production experience talking. | 03:17 |
* OvenWerks video production experience is very old.... 1980 to 1984 or 5 | 03:18 | |
OvenWerks | All analog | 03:19 |
OvenWerks | Video recorded on 2inch quad or 1inch helical. | 03:20 |
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:23 |
Eickmeyer | OvenWerks: Yeah, that makes sense. | 03:25 |
OvenWerks | have you been watching LAC at all? | 03:26 |
Eickmeyer | LAC? (in other words, no.) | 03:27 |
OvenWerks | linux audio conference | 03:27 |
OvenWerks | There are two days left | 03:27 |
OvenWerks | I got yesterdays, but missed most of todays | 03:28 |
Eickmeyer | That must be what rgareus and falktx were talking about. | 03:28 |
OvenWerks | https://lac.linuxaudio.org/2019/ | 03:29 |
OvenWerks | ya, #lac2019 in irc | 03:29 |
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:30 |
Eickmeyer | Cool. I might have to jump-in tomorrow. | 03:31 |
OvenWerks | You can ask questions via irc. | 03:31 |
OvenWerks | I found out AVB is a cpu hog... at least the way https://lac.linuxaudio.org/2019/doc/kuhr.pdf | 03:32 |
OvenWerks | these guys do it | 03:33 |
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:34 |
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:35 |
OvenWerks | There is a 1ms mode (aes67 standard) which I would tend to use. | 03:36 |
Eickmeyer | I agree with that. I reallllly want to see something replace Dante. | 03:37 |
OvenWerks | Dante will now connect to aes67 | 03:37 |
Eickmeyer | Well, that eases the transition, certainly, but Audinate has kinda had the market cornered on that concept for all too long. | 03:38 |
Eickmeyer | I absolutely abhor it being proprietary / without Linux support. | 03:39 |
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:40 |
Eickmeyer | Indeed. | 03:41 |
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:42 |
OvenWerks | (from avb/aes67 network master clock) | 03:43 |
OvenWerks | Some projects I would like to see (or do): | 03:45 |
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:46 |
OvenWerks | - a bluetooth audio jack client using libzita-src | 03:47 |
OvenWerks | - jack avb and aes67 clients | 03:48 |
OvenWerks | - make one of the pins of an intel i210 enet card have wordclock/spdif sync out from avb/aes67 media clock | 03:49 |
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:50 |
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:55 |
Eickmeyer | Honestly, it sounds like something we've needed for a long time to happen. | 03:58 |
OvenWerks | pulse-jack was only ever an example pulse plugin | 03:59 |
Eickmeyer | Well, exactly, and the buffer it requires causes way too much latency. | 04:03 |
OvenWerks | I forgot to add putting gui stuff for tablets in -controls | 04:04 |
Eickmeyer | Oh yes. Definitely. | 04:04 |
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:05 |
OvenWerks | Then there is the digital video audio lines (HDMI?) which wants jack set to 8192 | 04:12 |
OvenWerks | I don't know if zita-ajbridge deals with that well at all | 04:13 |
Eickmeyer | Yeah, that seems weird. I don't know enough about how audio is sent over HDMI. | 04:19 |
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:22 |
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:23 |
OvenWerks | yes, but obviously any syncing is is to the nearest frame | 04:24 |
Eickmeyer | Right. | 04:24 |
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:25 |
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:26 |
OvenWerks | Standard SR for audio with video is 48k... they can pull that from chroma (in the old days) | 04:27 |
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:35 |
Eickmeyer | They can push 96k afaik. | 04:36 |
Eickmeyer | 12G SDI is where it's at though. 4k video and audio via a coaxial cable. | 04:37 |
Eickmeyer | Of course, it's limited to 300 feet, but for live video that's pretty good. | 04:38 |
Eickmeyer | And then there's repeaters that can be implemented, but that's where latency can become an issue. | 04:39 |
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:40 |
OvenWerks | is sdi still 8 audio streams? | 04:53 |
OvenWerks | hdmi is these days | 04:54 |
Eickmeyer | OvenWerks: 12G can do up to 16, I believe. | 05:08 |
Eickmeyer | Rosco2: o/ | 18:44 |
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:45 |
Rosco2 | I was just looking at carla | 18:46 |
Rosco2 | We have a build failure on arm which will prevent 2.0.0 getting out of proposed | 18:47 |
Rosco2 | Might want to try -- --disable-sse2 or something on the auto-config override conditional on ARCH=armhf | 18:48 |
Rosco2 | will do the seeds now | 18:49 |
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:50 |
Eickmeyer | Either way, he's aware. | 18:51 |
Rosco2 | Maybe ask for the same exception? | 18:51 |
Eickmeyer | I'm on it. | 18:51 |
Rosco2 | If disabling the sse flag doesn't work, we could just not build for arm | 18:52 |
Eickmeyer | <Eickmeyer> vorlon: That failure won't prevent it from migrating from propsed will it? | 18:52 |
Eickmeyer | <vorlon> Eickmeyer: no | 18:52 |
Rosco2 | OK | 18:52 |
Eickmeyer | So, an arm failure isn't a blocker in this case. | 18:53 |
Eickmeyer | <vorlon> what matters for migration is not regressing the set of supported archs | 18:53 |
Rosco2 | Got it. | 18:53 |
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:54 |
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:57 |
Rosco2 | :-) | 18:58 |
Eickmeyer | Rosco2: Will do. I think my next big project is going to be the lsp-plugins. | 19:03 |
OvenWerks | Eickmeyer: midizap looks good | 19:06 |
Eickmeyer | OvenWerks: Indeed. I was looking for something with that functionality at my previous job. | 19:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!