[00:39] <ailo> I got my toe dipped in jack programming today. Created a jack transport start|stop cli app. Just a couple of lines in python
[07:54] <smartboyhw> Hi!
[10:15] <astraljava> len-dt: Good news, thanks!
[10:16] <smartboyhw> astraljava: What good news?
[12:53] <smartboyhw> On the news of len-dt, another news: 64-bit testing completed by me now
[12:56] <astraljava> Thanks. I'm still not sure whether there'll be new images, so please keep your eyes on the tracker, if you have time still before the release.
[12:56] <astraljava> Huge thanks for all testers!
[12:58] <astraljava> I don't expect any big issues, as our unique parts haven't changed much, this refresh is mostly foundations-related. But have you noticed any peculiarities, len-dt or smartboyhw? I'm not talking bug-worthy (as I expect those having been filed), but anything out of the ordinary?
[12:59] <smartboyhw> astraljava: NO!
[12:59] <smartboyhw> BTW, thanks scott-work and astraljava and everybody for making such a nice OS
[13:00] <smartboyhw> Now I'm waiting for ailo to finish the 64-bit lowlatency kernel to test...:)
[13:06] <astraljava> ailo isn't making the kernel (yet), but writing testcases for it. I need to bug the kernel team tomorrow so that we'd get an updated -lowlatency for 12.04.1, though.
[13:07] <smartboyhw> ailo jst got len-dt a kernel to test for 32-bit, mate
[13:07] <astraljava> Which would, of course, require new tests for the image, if it happens. I'll keep this channel posted, though.
[13:10] <smartboyhw> astraljava: I mean this
[13:11] <smartboyhw> http://cdimage.ubuntu.com/xubuntu/precise/daily-live/20120817.3/precise-desktop-amd64.iso
[13:11] <smartboyhw> Oh, sorry, not thed link
[13:11] <smartboyhw> [14:28] <ailo> len-dt: Kernels are built https://gitorious.org/ubuntustudio-testing/pages/Kernel
[13:11] <smartboyhw> On 17th August, that is
[13:14] <astraljava> smartboyhw: Right. Well, we aren't hosting our official kernels on gitorious, that's just unofficial testing. If you look into the kernel version on quantal, you'll notice that we're still in the 3.5.0 tree.
[13:15] <smartboyhw> Oh, that's why
[14:13] <stochastic> That's it I'm goin' camping. :)
[14:15] <knome> have fun stochastic 
[14:16] <smartboyhw> stochastic: Bye and have some fun!
[14:48] <smartboyhw> ailo: Are you here? I want to know the progress of the amd64 kernel:)
[15:21] <ailo> smartboyhw: I told you before, I'll let you know when the tests are finished. Me and Len have been working on the ground work for them. That is why I have only been notifying Len so far
[15:21] <smartboyhw> Oh, that's why.....
[15:21] <smartboyhw> Thanks
[15:33] <smartboyhw> ailo: Been wondering about Bug 1021264
[15:33] <smartboyhw> You have already succeeded in doing so, why don't you change the Importance to "Fix Released"?
[15:34] <ailo> smartboyhw: Not fixed
[15:34] <smartboyhw> ailo: Why?
[15:35] <ailo> I need to do some research on that. But it's not a priority at the moment. We have the bug team, and a new mail list for bugs. The forwarding was a bit difficult to set up.
[15:36] <smartboyhw> Oh, that's why, the forwarding
[15:36] <smartboyhw> BTW, on Bug 152853
[15:36] <smartboyhw> I packaged it today, but I'll need a MOTU to do so, but actually has it been fixed?
[15:40] <smartboyhw> I mean I'll need a MOTU to actually merge the branches
[15:40] <ailo> smartboyhw: If you have packaged it, the best way is to get it into Debian
[15:40] <smartboyhw> ailo: I need to wait for a MOTU to approve the packaging
[15:40] <ailo> subscribe to the Debian Mentors list, and tell them you want to upload a package
[15:41] <smartboyhw> Debian Mentors List? What's that?
[15:41] <ailo> smartboyhw: It's better you go through Debian. 
[15:41] <ailo> That way, it will end up in all Debian based distros, including Ubuntu
[15:41] <smartboyhw> OK
[15:41] <ailo> Only upload to Ubuntu, if for some reason, it is Ubuntu specific
[15:42] <ailo> Like, ubuntustudio-controls
[15:42] <smartboyhw> oh
[15:42] <ailo> smartboyhw: The Debian Mentor mail list is a place where Debian uploaders and developers help new participants
[15:43] <ailo> You just say you want to upload a package, and you are seeking a sponsor
[15:43] <smartboyhw> OK
[15:45] <smartboyhw> Ok, subscribing now
[16:23] <len-dt> astraljava, The only differences I have noticed have been good. For example I have not seen any scrollbars on our install slideshow for a while now.
[16:41] <len-dt> ailo, to continue on the comment I left in the other channel.
[16:43] <len-dt> ailo, in your controls app, it may be a good idea to have a way for checking user is in audio group and adding iff needed
[17:59] <ailo> len-dt: That is the main feature I'm adding. realtime privilege administration
[17:59] <len-dt> Good
[18:00] <ailo> len-dt: And, my comment was more about the task installs for ubuntu studio
[18:00] <ailo> That even if you install the ubuntu studio desktop task, you might not get those settings correct
[18:00] <ailo> If I remember correctly, this is still the case
[18:00] <len-dt> Ya, there are a number of people who start with vanilla or kubuntu and use our metas.
[18:01] <ailo> I've noticed over the years..
[18:01] <len-dt> permissions is the biggest issue with doing that right now
[18:02] <ailo> One of the metas could have a post install script to handle that, and ask the user if to be included into the group
[18:02] <ailo> Just like the jackd install
[18:03] <len-dt> Yes like -settings or maybe a new -audio-settings
[18:03] <len-dt> or maybe the audio meta
[18:03] <ailo> I'd vote settings
[18:04] <len-dt> Though that would be harder because the audio meta is based solely on seeds right now.
[18:04] <ailo> I think settings should have everything that includes any kind of system configuration
[18:04] <len-dt> ailo, I am wondering if someone installing mettas over vanilla would want our -default-settings
[18:05] <len-dt> They are xfce dependant
[18:05] <ailo> I could imagine someone only wanting realtime privilege, and one or two apps
[18:06] <ailo> I would assume that all happens in settings. On the other hand, I'd assume installing jackd would be enough to get started :(
[18:06] <ailo> And if realtime privilege is done in settings, should audio depend on it?
[18:06] <ailo> Or should be we break settings into workflows?
[18:06] <ailo> As you said before
[18:07] <ailo> Then ubuntustudio-audio would depend on ubuntustudio-audio-settings
[18:07] <len-dt> Maybe the audio meta should be separated from seeds and have its own package so we could include audio settings or maybe an audio-setting package that the audio meta includes
[18:08] <micahg> no, it makes most sense as a seed, I see no issue with something like ubuntustudio-audio-settings being built out of the -default package for a case like this
[18:09] <len-dt> micahg, I think we both just came to that conclusion :)
[18:10] <len-dt> Anything else is too much work to maintain
[18:10] <micahg> right
[18:11] <len-dt> micahg, if we add setting the user to audio group in a settings package then we could remove the preseed line that does that, right?
[18:15] <micahg> not sure about that
[18:16] <len-dt> I guess my question should really be would it hurt to add the user to the audio group twice.
[18:18] <ailo> len-dt: Nope. But the install script could be made smart.
[18:19] <len-dt> ailo, the preseed would have to be smart too.
[18:19] <ailo> len-dt: I think we need to separate those, unless you can add ubiquity choices as well. Same as for jackd
[18:20] <len-dt> Ya
[18:21] <len-dt> if we set group in settings it would be best to remove the preseed.
[18:22] <ailo> Only if we can make choices during ubuntustudio install
[18:22] <len-dt> It could be a choice like jack does and preseed the choice like we do with jack
[18:22] <ailo> Aha, like so
[18:22] <ailo> Right
[18:22] <len-dt> The if we ever get a ubiquity module the coices could be made there.
[18:23] <len-dt> *Then
[18:25] <ailo> len-dt: Did you have a loot at the kernels I built? There's not that many versions, and not a great deal of difference between them
[18:25] <ailo> There's the one with the ticking timer
[18:26] <len-dt> TBH no I haven't. I have been busy with other things so far.
[18:26] <len-dt> I will have other family related things to do this next few weeks too.
[18:26] <ailo> len-dt: Well, the ticking timer might be interesting as far as midi goes
[18:27] <len-dt> For midi I still need to find a situation that causes problems...
[18:27] <ailo> len-dt: I think the ticking timer might make things worse
[18:28] <len-dt> So far all of my tests have shown no changes with any setting.
[18:29] <ailo> I'm getting more busy now as well. Starting tomorrow
[18:30] <ailo> Things have a tendency to just drag on forever. I keep putting too much time on the wrong details
[18:32] <len-dt> I think we should but swappiness and hrt/rtc in audio group in defualt settings at least for this cycle. The rest we have yet to prove they do anything (good)
[18:40] <ailo> len-dt: My tests are meant to do that, however, have you found any proof of hrt/rtc making any improvement yet?
[18:41] <len-dt> None, but I have not played with rosegarden at all. It is just that as we have added them to the kernel we should finish the job.
[18:42] <len-dt> We can't test everything.
[18:42] <ailo> Shouldn't be any different on Rosegarden. Still alsa midi
[18:43] <ailo> The purpose of the tests I'm making is to gather data from several machines, to see the actual impact of tweaks
[18:44] <len-dt> I don't know, it is just that these recommendations have come from the rosegarden forums, so I would think that is where they solved problems.
[18:44] <ailo> alsa midi is a bit difficult to automate though, but we should still probably use the same test for it
[18:45] <len-dt> midish might make it easier.
[18:45] <len-dt> It can set up connections and filtering as well as playback/record midi streams
[18:45] <len-dt> All CLI driven.
[18:46] <ailo> I'm creating a standard use case using at least a DAW. Perhaps, qjackctl + hydrogen
[18:46] <len-dt> Anyway, I should go...
[18:47] <ailo> Controlling transport from the script
[18:47] <ailo> len-dt: See you
[18:49] <ailo> That should have been qtractor + hydrogen..
[19:31] <ailo> len-dt: Just recorded some audio from hexter to qtractor,  using qtractor to send midi to hexter. It's not in sync.
[19:32] <ailo> I'm on Debian now. Need to check my settings too
[20:28] <ailo> len-dt: Actually, I found that monitoring qtractor controlled Hexter, and Hydrogen, both started with jack transport are not in sync at all
[20:28] <ailo> But, after recording hydrogen to qtractor, the recording itself was a bit better synced
[20:29] <ailo> Still, not nearly perfect
[20:30] <ailo> The midi seems to be a few notches ahead of audio
[20:30] <len-dt> ailo, it should be
[20:30] <ailo> It's just strange that what I hear is not what is
[20:30] <len-dt> What setting are you using for -p on jack?
[20:31] <ailo> The latency is pretty large right now
[20:32] <ailo> The audio from hydrogen is taking less time to arrive to my speakers, than to qtractor
[20:33] <ailo> Also, the recorded material in qtractor is a few notches too early
[20:33] <ailo> I'm missing maybe 10-20 ms at the beginning
[20:34] <len-dt> midi or audio?
[20:34] <ailo> audio
[20:34] <ailo> Also, not in sync
[20:34] <ailo> The beats are a bit off
[20:35] <ailo> I'm not really doing any testing now
[20:35] <ailo> Was just going to record some audio to use for the test
[20:36] <ailo> len-dt: Hang on. I'm making a screen shot
[20:38] <ailo> len-dt: http://imagepaste.nullnetwork.net/viewimage.php?id=4721
[20:38] <ailo> len-dt: The bottow two channels have the same exact drum loop, but those are two separate bars of it
[20:39] <ailo> I just copied and pasted one under the other
[20:40] <ailo> You can clearly see they are out of sync, not only with qtractor, but with themselves
[20:40] <ailo> I'm using the hpet and rtc improvements
[20:40] <ailo> -p 1024, I think
[20:45] <len-dt> I did not test midi to audio timing. My question is this a qtractor problem?
[20:45] <ailo> One could try using different settings too. qtractor has settable midi timer
[20:45] <len-dt> We probably need to have signal flow diagram for both midi and audio.
[20:47] <ailo> Could be the situation changes dramatically if not using jack transport. There's a lot of variables
[20:50] <ailo> Coming to think of it, these are exactly the type of things we should get right, and document.
[20:52] <ailo> But, I do think jack midi would make things easier here
[21:18] <ailo> len-dt: Measuring midi agains midi doesn't show you if the midi clock has jitters
[21:18] <ailo> Since everything is following the same clock
[21:19] <ailo> Previously, when I explained the sync problem and how it was apparent to me, was when recording audio
[21:19] <ailo> I haven't ever tried recording midi
[21:19] <ailo> jack midi is solid in this sense
[21:20] <ailo> I used ardour3 to control my external synth and recorded from it
[21:21] <ailo> I think with all the problems that comes with alsa midi, it would just make things easier if we just replaced everything with jack midi
[21:21] <ailo> not "we", literally, of course
[21:23] <ailo> heh, funny. I set qjackctl to use "seq" midi driver, and I get a ticking sound from my speakers
[21:24] <ailo> Hmm, it's from PA
[21:24] <ailo> Seems like my internal card has disappeared too. Something with this MB
[21:25] <ailo> well..