[14:33] <Eickmeyer> studio-controls 2.3.9 is now in the official backports.
[14:33] <Eickmeyer> For 22.04
[22:48] <OvenWerks> Eickmeyer: RE: yucky sound from zita-ajbridge. The package that got the change to fix this was: zita-alsa-pcmi I could not find that but noticed that zita-ajbridge does have a depends for libzita-alsa-pcmi0 which does have an upstream package zita-alsa-pcmi.
[22:49] <OvenWerks> Eickmeyer:  the version I have the LTS is 0.4.0-1 the version with the fix is 0.6.1
[22:52] <OvenWerks> now that packages.ubuntu.com has come back... I see that lunar has the right one. kinetic is 0.5.1-1
[22:53] <OvenWerks> Eickmeyer: so it was not the zita-ajbridge package number.
[22:57] <OvenWerks> Eickmeyer: there are some packages that depend on this including jackd (both) as well as zita-ajbridge. Probably this needs to have a new package available back to the LTS. I don't know if backports is still there or still in the process of being replaced.
[22:58] <OvenWerks> But this may mean new dependant packages as well
[22:58]  * OvenWerks thinks he is going back to bed.
[23:02] <Eickmeyer> OvenWerks: I literally just sat down at my computer.
[23:03] <Eickmeyer> OvenWerks: That information is completely incorrect. packages.ubuntu.com is known for being misleading sometimes.
[23:03] <Eickmeyer> https://launchpad.net/ubuntu/+source/zita-ajbridge
[23:03] <Eickmeyer> Unless you mean zita-alsa-pcmi
[23:04] <Eickmeyer> Then, yes, that would require a backport as an SRU would be inappropriate. Lunar has 0.6.1
[23:04] <OvenWerks> hello, I still have sore sides but a week ago I also got sick so I am a bit dopy
[23:04] <OvenWerks> yes I mean zita-alsa-pcmi
[23:05] <Eickmeyer> No worries. I eventually figured out what you meant.
[23:05] <OvenWerks> but that is the problem with ajbridge
[23:05] <Eickmeyer> https://launchpad.net/ubuntu/+source/zita-alsa-pcmi
[23:05] <OvenWerks> I was just reading through some of the Ardour forum.
[23:05] <OvenWerks> It is great to know that at least the latest is correct
[23:06] <Eickmeyer> If I can figure out for certain that nothing else really depends on it, I might be able to submit a backport to the LTS.
[23:06] <OvenWerks> jackd2 does
[23:07] <OvenWerks> aeolus, jaaa, aliki, japa, zita-alsa-pcmi-utils
[23:08] <Eickmeyer> Yeah, I just looked up the rdepends.
[23:08] <Eickmeyer> That's quite a few.
[23:08] <OvenWerks> jackd2 is listed twice?
[23:08] <Eickmeyer> I only see it listed once.
[23:08] <OvenWerks> could be muon
[23:09] <Eickmeyer> I'm not using muon. I used "apt-cache rdepends"
[23:10] <Eickmeyer> Do we know the exact bug and/or craziness that is being caused? That would make my life easier when trying to backport.
[23:13] <Eickmeyer> Additionally, this would require no-change rebuilds of each of those rdepends, and I know the TB is having trouble with the Backporters team on that.
[23:15] <Eickmeyer> teward: TL;DR because I know you're going to try to send me into the 30th nether of whatever void: we're considering a backport of zita-alsa-pcmi, which is a dev library for a handful of audio tools, because it's bugging out some stuff in the LTS. Each of those would need a NCR.
[23:16] <teward> *was pinged*
[23:16]  * arraybolt3 tosses Eickmeyer a void protector
[23:16] <teward> Eickmeyer: NCR = No change rebuild?  *is high on sugar and drunk on hard cider right now*
[23:16] <Eickmeyer> teward: Yes.
[23:16] <teward> Eickmeyer: i'm confused, because it's my understanding the main repos *do not* include Backports in the builders
[23:17] <Eickmeyer> It's not as simple as a SRU since the only way to fix it is with a whole upstream version, so too many changes.
[23:17] <teward> so an NCR *only* applies if you're going to backport the entire version of everything dependent on it too
[23:17] <teward> the other time it applies is if you do an SRU with the entire version with an ABI bump
[23:17] <OvenWerks> Eickmeyer: the thread I find is going around in circles. but it comes down to "Zita-a2j is way too hot!"
[23:18] <Eickmeyer> teward: That's what it comes down to is that we'd have to not only ABI bump, but each of the tools would need an NCR, so I guess we NCR in backports?
[23:19] <Eickmeyer> I doubt the SRU team would accept a whole ABI bump on this one. Too many changes.
[23:19] <Eickmeyer> We'd have to go 1-2 whole versions higher.
[23:19] <OvenWerks> Eickmeyer: https://lists.linuxaudio.org/hyperkitty/list/linux-audio-user@lists.linuxaudio.org/thread/HCVROUMLYYT3ZTM6KVSGDUNVVCFKYH3N/
[23:20] <teward> Eickmeyer: each tool needs a backport then
[23:20] <Eickmeyer> OvenWerks: ack. TL;DR: bug in the dev library causing issues in one tool.
[23:20] <teward> and its own backport request, etc.
[23:20] <Eickmeyer> teward: Ok, that's probably doable.
[23:20] <teward> but i'm not sure we would do that if it's the same-version and not 'newer'
[23:20] <Eickmeyer> It's only a handful of tools, tbh.
[23:20] <teward> that's a backports team review decision
[23:21] <OvenWerks> this also points to an Ardour thread :P  but Fons Adriaensen replies about half way down with: This is due to a bug in libzita-alsa-pcmi, which will affect all
[23:21] <OvenWerks> sound cards using the S32_LE format. This is s fixed in version 0.6.1 which is now available at the usual place: <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html> How I could make such a stupid mistake is beyond me.
[23:21] <Eickmeyer> We have 0.6.1 in Lunar, so that's what we'd have to backport.
[23:22] <Eickmeyer> So, 2 versions newer.
[23:22] <OvenWerks> Thats the good one
[23:22] <Eickmeyer> I'll have to play with all of this in a PPA.
[23:23] <Eickmeyer> Right now, my focus is tomorrow's beta release (and its corresponding announcement).
[23:23] <Eickmeyer> teward: Thanks for the info.
[23:24] <OvenWerks> Eickmeyer: there are not that many cards using S32_LE 
[23:24] <OvenWerks> Eickmeyer: no worries, I just wanted to get the message through before I forgot... again.
[23:25] <Eickmeyer> OvenWerks: Right. I, for one, haven't experienced the issue myself, but we have seen people passing through that have, and they likely have S32_LE.
[23:25] <OvenWerks> Yeah the device puts out 32bit stream direct instead of 24i
[23:26] <Eickmeyer> Staggers the imagination.
[23:26] <OvenWerks> Zoom and sound design are the two big ones
[23:29] <OvenWerks> They take three inputs at different levels and choose the one just below clipping encoding it direct to 32 bit float. Supposed to allow set and forget level settings without having to set things 20db down. Most people just plain forget and the sound ends up crummy anyway. (Just read about one such case that is asking how they can "recover" decent sound)
[23:30] <OvenWerks> anyway, I do need to lay down. later
[23:30] <Eickmeyer> Get well soon!