[03:46] <OvenWerks> Eickmeyer: FYI, Ardour 6.1 tagged... from some of the conversation, 6.2 may be earlier than expected. So not sure it is a great idea to pull in 6.1.
[03:47] <OvenWerks> Eickmeyer: -controls has moved a pace. 
[03:49] <OvenWerks> my old AudioPCI card has an AudioPCI,1,0 which zita-ajbidge can not open though I think jack can (could before).
[03:50] <OvenWerks> This may have been part of what I was seeing the other day. but there were other things too (now fixed) that were git master specific.
[03:57] <OvenWerks> so not in release. PCH,1,0 (playback) and PCH,2,0 (capture) do both work as extra devices and more cleanly than before.
[03:58] <OvenWerks> Headphones is part way there.
[04:00] <OvenWerks> if jackmaster is HDA and head phones get plugged into, head phones will switch when plugged in.
[04:01] <OvenWerks> and back when unplugged.
[04:09] <OvenWerks> alsa mixer will still switch even if not jackmaster... at least if PCH is called the headphone device. If another device is called the headphone device (like USB) then the usb un/plug event will be used to switch... but this requires more code to move the connections from jack master to PH device. I guess I should keep track of these connections because if the device is pulled the ports may 
[04:09] <OvenWerks> vanish before I get a chance to move them.
[04:10] <OvenWerks> I have already added a jack client to autojack and will be working on this next.
[04:11] <OvenWerks> The code I have now for making connections from devices to pulse bridges will be moved from external calls to this client as well.
[04:14] <OvenWerks> This will also allow something like use a usb device and decide to be quiet... plug HP into computer, noise from usb device goes away to headphones in PCH device... are we having fun yet?
[04:15] <OvenWerks> I will say this is farther than I ever expected autojack to go when I whipped up a quick bash script to set up the usb device for my wife's computer.
[04:19] <OvenWerks> Eickmeyer: in other news, I DL AVLinux and ran live. It says it supports the echofire 12... so someone has gotten it to work. mine doesn't. The only thing I haven't tried at this point is a new cable... so I have prdered another one (9 pin to 6pin instead of 6 to 6). This is my last stab at things fw unless someone comes along with lots of time to try things for me or who has one already 
[04:19] <OvenWerks> running.
[04:19] <OvenWerks> I may try installing AVL to see installed makes any difference.
[04:20] <OvenWerks> I don't like it so much in my tests. but lots of people do use it so it is at least something to go by.
[04:21] <OvenWerks> I think ubuntustudio is still better.
[04:21] <OvenWerks> Anyway, good night
[06:19] <Eickmeyer> OvenWerks: Sorry for the radio silence, just read through all of this. Good progress!
[06:20] <Eickmeyer> RE: AVL: If there's one thing that it has that we don't is an RT kernel. That said, Holstein and I tend to agree that RT kernels aren't the fix-all that people think they are. 
[06:36] <OvenWerks> Eickmeyer: no RT kernals are not a fix.
[06:37] <OvenWerks> generally it starts with getting lucky with hardware
[06:40] <OvenWerks> it seems ardour 6.1 is tagged but not released ;)
[14:30] <OvenWerks> Eickmeyer: I have found the reason I can not use zita-ajbridge with the AudioPCI,1,0 device. I thought I would try alsa_out and it failed too. However, it at least told me why it could not open the device. It seems that while AudioPCI,0,0 will open fine at 48000, AudioPCI,1,0 is 44100 only.
[14:33] <OvenWerks> Eickmeyer: because the card is as old as it is... pre AC97 even. there is no easy way for me to find that out. USB has a stream file and HDA has a Codec file which give the allowable rates.
[14:36] <OvenWerks> Eickmeyer: jack doesn't care, jack opens the device at whatever rate it is running at even if it fails to set the rate.
[15:55] <Eickmeyer> OvenWerks: Interesting.
[15:57] <OvenWerks> Looking at the alsaaudio module for python... it can try to set rate and fail but does not seem to have a way of querying availabale rates
[16:01] <Eickmeyer> So, that means it figures it out by trial and error and probably goes toward the lowest SR, right?
[16:02] <OvenWerks> I think the python alsa module just fails if you ask for the wrong SR just like zita or alsa_out
[16:03] <Eickmeyer> Fun.
[16:06] <OvenWerks> I think I might write a quick script just to test it. There is a command alsaaudio.pcms([type=PCM_PLAYBACK])
[16:06] <OvenWerks> with the description: "List available PCM devices by name."
[16:07] <OvenWerks> but looking at the c code it looks like it does a lot more.
[16:07] <Eickmeyer> Nice. That might help.
[16:15] <OvenWerks> Nope, I would have to write something in c. There alsapcm_setup works like: snd_pcm_hw_params_set_rate_near() then: snd_pcm_hw_params_get_rate()
[16:15] <Eickmeyer> Oh, fun. :P
[16:16] <OvenWerks> but that is not available in the python bit I think.
[16:16] <OvenWerks> And besides I don't really want to actually open the device.
[17:46] <OvenWerks> Eickmeyer: What I can do: I can set rate in python, check: /proc/asound/<device>/<subdev>/hw_params for rate:
[17:48] <Eickmeyer> In theory that should work. Nice.
[18:02] <OvenWerks> I think it will actually be better than trying to find the right file for the device type to parse
[18:04] <OvenWerks> So for this device, 48000 gives a rate of 5512 and 44100 gives a rate of 44100
[18:06] <OvenWerks> What is interesting is that sub 0 and sub 1 giv e two different results as if they have two different clocks
[18:07] <OvenWerks> rate is specified like: rate: 44100 (44100/1) with the first number bing what it is set for and the second being actual
[18:07] <OvenWerks> that is sub 1, sub 0 is: rate: 44100 (1411200/32)
[18:08] <OvenWerks> and even worse: rate: 48000 (1411200/29)
[18:11] <OvenWerks> Maybe that is how the clock gets it... so 48k is actually: 48662.068 and 44k1 is right on. Interesting.
[18:12] <Eickmeyer> Very interesting. Seems like an arbitrary sample rate for 48k for that device.
[18:12] <OvenWerks> try to get close I guess
[18:13] <Eickmeyer> It's clear that it's made specifically for 44.1k.
[18:13] <OvenWerks> yes
[18:14] <OvenWerks> I think AudioPCI,1,0 is a digital out (spdif-ish
[18:14] <Eickmeyer> My audio interface is capable of 192k, but I don't know why I'd ever run it that high unless I were recording bats.
[18:16] <OvenWerks> The main device does 32k but the sub1 doesn't
[18:18] <OvenWerks> So try to set the device to jack-rate if it fails, try one step up if 44k1 down if 48k then try 96k then try 32k... then give up :)
[18:19] <OvenWerks> (some webcam devices are 32k)
[18:20] <OvenWerks> Eickmeyer: my opinion is that if we are already going through an SRC stage (zita) then any possible gain from 96k or up is lost anyway.
[18:21] <Eickmeyer> I know someone who swears by 96k. I told him that he must have supersonic hearing then.
[18:21] <OvenWerks> The problem is that there are some devices that are 96k only (A&H new 32 channel mixer for example)
[18:21] <Eickmeyer> Yep, some Roland mixers do 96k. I mean, I get it as far as sample rate, but you're never going to be able to hear what that is capable of sampling.
[18:22] <OvenWerks> Eickmeyer: there are some (poorly made) plugins that do benefit from a higher sample rate... properly made ones will upsample inside instead
[18:22] <Eickmeyer> Which makes sense.
[18:25] <OvenWerks> digital mixers use 96k for latency in snakes... and in the case of A&H because they use all int math (so also 48 bit or more bit depth)
[18:26] <Eickmeyer> Ok, maybe that's why 96k sounds better in live venue settings.
[18:28] <OvenWerks> It just works better with the DSP chips they use... no real cpu ecept for control
[18:30] <OvenWerks> Also no discounting the Sales PR it gives  ;)
[18:32] <OvenWerks> Eickmeyer: is there a place where you keep depends for studio-controls?
[18:33] <OvenWerks> we will need to add python3-alsaaudio
[19:48] <Eickmeyer> OvenWerks: is python3-alsaaudio in the repos?
[19:49] <Eickmeyer> It is. Not hard to add that as a dep. Just make sure it's documented somewhere.
[19:50] <Eickmeyer> Already exists in Fedora as well, so looks like we've mostly got our bases covered.
[19:51] <OvenWerks> mention it in the changelog?
[19:54] <Eickmeyer> Sure.
[21:06] <Eickmeyer> OvenWerks: mcpdisp in the NEW queue.
[21:19] <OvenWerks> cool