[01:19] <len-dt> zequence, interesting thing with the new PA. When jack-sink is available, it becomes default even though pavucontrol still shows the device as default. (this is a good thing)
[01:20] <len-dt> zequence, so if jackd manages to start, then the stream transfers to jack. Good deal.
[01:24] <len-dt> I think the new problem is because PA takes just a bit longer to release the HW than jack takes to aquire it (or try to).
[02:51] <len-dt> It may be worse on my system because it is slower or maybe has a slower drive.
[02:56] <persia> Might also be an architectural thing.  JACK might not want to advertise a working device to PA until it has claimed a device, and PA may not wish to release a device until there is an alternate available.
[02:56] <persia> When a machine is fast enough, the two things happen "simultaneously", making it unnoticeable.
[02:56] <persia> That said, I haven't actually looked at the code to see if it is anything like this.
[02:59] <len-dt> I don't either (know what the code looks like). But PA does stop/release it's stream.
[03:00] <len-dt> I don't know if there is a way to find out who has an alsa port
[03:02] <persia> You can look at lsof output to see what is claiming the device
[03:03] <persia> `lsof | grep /dev/snd` should show you most stuff, although you might get some permission denied errors for some processes (unlikely to be sound-related).
[03:03] <persia> You can make it quieter with 2>/dev/null or sudo, but the output should otherwise be the same.
[03:04] <persia> Mind you, this only reports which kernel devices are currently being accessed: mapping that to specific ports might be a bit trickier, especially if someone is running a multiplexor inside ALSA, or other sorts of interesting configuration.
[03:05] <persia> I believe that by default, Ubuntu doesn't have much fancy ALSA mappings: just definition of 2-channel defaults for cards that don't advertise this well.
[03:08] <len-dt> We don't add any plugins. I will try as I have time.
[03:10] <persia> Heh: take a look in /usr/share/alsa/ sometime if you're curious: there's more than a few cards for which there are special arrangements :)
[03:12] <len-dt> Interesting, Jack has the sinks/sources, but PA retains control of some of the controls.
[03:14] <len-dt> when I cause the problem, Jack says it can't access the hw because some other application has it, but none of the sinks/sources show connections.
[03:16] <len-dt> However, when I killall -9 jackdbus PA takes them back at that time.
[03:17] <persia> JACK might not be able to attach to the sinks/sources without a control connection
[03:19] <len-dt> Ya, but it looks like many things can connect to the controls at the same time.
[03:21] <len-dt> Looks like about 8 things right now.
[03:22] <persia> Hrm.  That's confusing.  Maybe there's some setting in the control that indicates exclusive access, or maybe JACK has higher requirements?
[03:22] <persia> This is deeper than I understand :)
[03:24] <len-dt> When jack is running, PA actually grabs more controls.
[03:25] <len-dt> PA on it's own only uses two channels, but when it's connected to jack it uses 10, because jack sees ten outputs.
[03:25] <len-dt> (12 inputs)
[03:26] <len-dt> Every time I have started jackdbus, PA is running. The difference is only if PA has accessed a port or not.
[03:27] <len-dt> That is why I think timing may be something to do with it. When PA is idle it can give up the ports faster
[03:28] <len-dt> In this version of PA it does more things as it gives up the port. (nice things actually)
[03:29] <len-dt> It seems to have figured out that jack is replacing a port and redirects that stream to jack.
[12:36] <smartboyhw> Hey scott-work, how are you?
[12:40] <scott-work> good morning smartboyhw , slight headache today. but i expected it since i was having some sinus issues lately *shrug*
[12:41] <scott-work> smartboyhw: yesterday (and probably today) have been real busy at work because of a small crisis with one of our jobs in the field, but i do hope today to add some to the blueprint for testing
[12:41] <smartboyhw> scott-work, oh no on the headache and work, :-D on the blueprints
[12:42] <scott-work> P)
[12:42] <scott-work> oops :)
[12:43] <smartboyhw> scott-work,lol
[12:49] <astraljava> scott-work: You got something wrong on the right lens of your goggles.
[19:37] <scott-work> astraljava: just a note to say that i increased the max size limit for emails to the ubuntustudio-devel mailing list because the nansukan ones for the images keep getting hung up
[19:38] <scott-work> hmmm, however, i just though i might be able to uncoditionally approve those emails and keep the limit the same
[19:38]  * scott-work is digging back into the mailman options
[19:40] <scott-work> eh, cdimage@nusakan.canonical.com was already on the "automatically accepted" list, so it looks like the limit size is considered separately after approval
[19:41] <scott-work> leaving it with the size increase then
[19:56] <zequence> Damn. I never got the beta steam client, as all members of UDS were to get
[19:56] <zequence> The "wine" version works just fine for me though
[20:14]  * micahg hasn't gotten one yet eitehr
[20:34] <scott-work> we keep getting errors building the i386 version of the image, it looks like blender, -video, and -graphics are problems, they might all stem from blender
[23:27] <ttoine> zequence, steam was demonstrated on Ubuntu ?
[23:46] <ttoine> at the UDS, I mean ,
[23:46] <ttoine> ?