[00:08] <len-dt> hmm interesting. The ART tube pres have to "warm up" for a few min before use. Ok makes sense (been a while since I used tube equipment), but that is not just before using, it is also before plugging into the computer. Or so the manual says.
[00:09] <len-dt> Spdif rate and USB rate do not have to be the same. And it seems can (not sure why) be used at the same time.
[00:42] <ailo> len-dt: Perhaps to control another machine that does not support up to 96kHz?
[00:43] <ailo> I know very little about those things. I've only synced my m-audio cards so far, and I barely knew what I was doing
[00:47] <len-dt> ailo, well I will be using it for that too. I have a d66 so this will give me 6 analogue inputs should I ever need it... and two tube pres anyway.
[00:47] <len-dt> I have been reading the online manuals... and saw this...
[00:48] <len-dt> Though the USB Dual Pre is compatible with USB 1.1
[00:48] <len-dt> and 2.0 interfaces, USB 2.0 is preferred for the cabling and computer connection as it allows for more
[00:48] <len-dt> system bandwidth. If you must use a hub, it should be a powered USB 2.0 compliant hub for best
[00:48] <len-dt> results, This is especially important if you plan on using multiple units for more channels of simulta-
[00:48] <len-dt> neous digital audio input.
[00:50] <len-dt> ailo, Looking at that got me thinking... it may be better to buy two or three USB1.1 units or USB2.0 units running as 1.1 than messing with making a 4x4 USB2.0 box.
[14:04] <len-dt> ailo, I was reading stuff on the RT kernel page... in the FAQ actually and came across this bit:
[14:05] <len-dt> For example, if a device grabs the PCI bus for long periods during DMA activity, that can introduce significant latencies in the system. In addition some firmwares can stop the system for housekeeping activities via Service Management Interrupts (SMI's) on x86 and x86_64 architectures; SMI's can not be trapped by the OS, so latencies introduced by SMBIOS routines can only be addressed by working with the firmware designers of the motherboard. 
[14:06] <len-dt> It may have something to do with the xrun/minute (or worse) the netbooks have.
[14:07] <len-dt> So while the ath9k driver may be open, the wlan TX firmware is set and may not be able to be changed.
[14:09] <len-dt> I suspect on better systems there is an additional layer of hardware (small processor?) between the TX and the CPU that deals with this stuff outside of the system bus.
[14:12] <len-dt> anyway I'm going to work now.
[15:32] <ailo> len-dt: Interesting.
[15:32] <ailo> In other words, in these cases your hardware sets the limits for you, and there's nothing you can do about it
[15:33] <ailo> But that would mean the same problem will appear with Windows with other drivers
[15:43] <ailo> But in your case there's a clear connectin with the software too
[15:43] <ailo> connection*
[15:46] <ailo> len-dt: If you ever intend to record more than 4 ch, I'd recommend getting another m-audio, like the LT-1010. Would seem easier than to combine usb with m-audio on two different machines
[15:46] <ailo> I got my M-66 + LT-1010 working, but rarely do I need them
[18:47] <len-dt> ailo, I don't know about the windows thing, but it wouldn't surprise me. The sales people who sell the netbooks are very careful to recommend them only for browsing and light use. I suspect they have had too many complaints about what can't be done with them.
[18:49] <len-dt> I thought about the using more than one usb audio IF and decided ART doesn't know what they are talking about. There is no way to sync more than one interface to another.
[18:56] <ailo> len-dt: If there's spdif, and the ability to adjust clock from internal to external you should be able to sync it
[18:56] <len-dt> And... as the netbook is marginal for audio anyway
[18:57] <len-dt> The IF I am looking at has spdif out but not in. I can use it to get 6 audio ins from my d66
[18:57] <ailo> If you want both devices controlled by the same machine you need a custom alsa config at least
[18:59] <ailo> I only know that you can use two of the same chip on the same machine, synced, on the same audio server
[18:59] <len-dt> alsa has trouble with more than one card at a time in anycase even when they are synced.
[19:00] <len-dt> alsa wants to have one control for the card and so when combining cards alsa only sees the control section of one card.
[19:00] <len-dt> can cause the odd hicup.
[19:01] <len-dt> Jack needs to be set up to see more than one card at a time. Jack is a "pro" audio setup and as such should realize there are audio cards designed to sync for that purpose.
[19:05] <len-dt> ailo, I would consider it a jack bug that two cards can not be used by jack at the same time
[19:06] <ailo> len-dt: http://www.jrigg.co.uk/linuxaudio/ice1712multi.html
[19:17] <ailo> That's how I got my m-audio cards synced. It worked, but I didn't fool around much with it
[19:18] <len-dt> Thats about what I have seen before.
[19:19] <ailo> OSS is much easier when it comes to that, I noticed while using puredata in the past
[19:19] <ailo> You can have any number of cards enabled at the same time
[19:19] <ailo> For puredata that's fine, as long as you don't use any other programs
[19:20] <ailo> Didn't much look at how well it performed latency wise though
[19:22] <len-dt> ailo, I notice none of thew alsa configs on that page do controls stuff. That may be why it works. Set stuff with mudita24 and just use jack to move audio data.
[19:24] <len-dt> It does say there were/are problems with this setup and the RT kernel.
[19:24] <len-dt> but low latency should be ok.
[19:26] <len-dt> ailo, That page seems to suggest that for the delta series cards the spdif link is better that the word clock.
[19:34] <len-dt> ailo, I like this mod... http://www.jrigg.co.uk/elec/interface.html
[19:35] <len-dt> Actually someone did that with three ensoniq cards successfully too.
[19:38] <len-dt> ailo, on the page you gave me, did you see the last paragraph?
[20:04] <ailo> len-dt: Yeah. But, I didn't do enough testing myself to see if I had the same problem
[20:06] <len-dt> I thought you were saying things where worse with the rtirq script... was that the same machine ailo ?
[20:06] <ailo> len-dt: Same machine as what?
[20:07] <len-dt> With the two delta cards
[20:08] <ailo> len-dt: No. I synced the two cards on a different machine. One that does not seem to change behaviour with or without threadirqs and rtirq
[20:08] <len-dt> ailo, just checking...
[20:11] <ailo> len-dt: I guess you read on the devel list about the kernel
[20:11] <ailo> It would really make things simpler for us
[20:11] <len-dt> I am just finishing it up... 
[20:12] <len-dt> Yes it would be nice to just have it build auto.
[20:12] <ailo> Can't say I have gone through every kernel config option to see what it does, but just reading about the shortly, it seems they are set right
[20:13] <len-dt> I have also been doing some reading on the realtime kernel. There are some interesting things.
[20:13] <ailo> Ubuntu Studio would only need to maintain the config options, and just that is a bit of work
[20:13] <len-dt> ailo, There may be one more thing in the kernel config to change that may help midi.
[20:13] <ailo> len-dt: Yes?
[20:14] <len-dt> it was a timer thing... I'm looking...
[20:15] <len-dt> Try enabling tickless timer support (CONFIG_NO_HZ)
[20:16] <len-dt> this is from the realTimeConfigQuickScan.pl
[20:16] <len-dt> script from http://wiki.linuxmusicians.com/doku.php?id=system_configuration
[20:16] <ailo> len-dt: I've been meaning to take a look at that
[20:16] <ailo> So far, I haven't commented on configs I'm not sure about
[20:17] <ailo> Would be good to see what the difference is
[20:17] <len-dt> Thts the only thing other than the kernel not being real time that the script complains about.
[20:17] <ailo> So far, with the configs that are default to both Ubuntu and Debian kernels, and adding just two configs, I get what I need
[20:18] <len-dt> It also complains about some other system configs though...
[20:18] <ailo> Yeah, about the hard disks
[20:18] <len-dt> looks for noatime
[20:19] <len-dt> scaling_governor
[20:19] <ailo> Yeah
[20:19] <len-dt> Checking swappiness... 60 - not good
[20:19] <len-dt> ** vm.swappiness is larger than 10
[20:19] <len-dt> set it with '/sbin/sysctl -w vm.swappiness=10'
[20:19] <ailo> I think those we need to test
[20:19] <len-dt> Checking checking sysctl inotify max_user_watches... < 524288 - not good
[20:20] <len-dt> Checking access to the high precision event timer... not readable - not good
[20:20] <len-dt> /dev/hpet found, but not readable.
[20:20] <len-dt> Checking access to the real-time clock... not readable - not good
[20:20] <len-dt> /dev/rtc found, but not readable.
[20:20] <ailo> It's a good page, but for me, aside from not having tested midi much, I can't say any of those configs make a difference for me
[20:21] <ailo> But it would be good to test and see
[20:21] <ailo> And look at implementing them for US
[20:22] <ailo> Can't say I've done much studio recording with linux though
[20:22] <len-dt> Setting the governer to performance may help my netbook.
[20:22] <ailo> So, the hard disk option I haven't really tested in practice
[20:23] <ailo> len-dt: I've only shortly looked at how the governor works, and mostly it's at maximum
[20:23] <ailo> For me
[20:23] <ailo> But yeah, perhaps
[20:24] <ailo> It won't be idle much when you're active at least
[20:24] <len-dt> There is supposed to be a newer style coming out that looks at dsp load as well.
[20:25] <len-dt> The problem with the governer is that it is scalable and can kick in even at as much as 50% cpu (maybe more... going from memory) I can record my first track or two at 20% or less.
[20:26] <ailo> I still haven't put my machines up for testing. Been having some router issues
[20:27] <ailo> But, this is exactly why I'm putting them up, so I guess it's just to start testing away
[20:31] <len-dt> The swappiness thing concerns me too. Though I haven't seen the effects of it. Basically, it seems to be saying that even though there is 70% of memory left we will start swapping things out anyway.
[20:32] <len-dt> But I would think in an audio chain everything is in constant use which should hold it in memory anyway.
[20:44] <ailo> len-dt: I guess that might become a problem when loading lots of samples
[20:46] <ailo> I could see what happens using 512MB of memory.
[20:46] <ailo> I mean, on a machine with 512MB RAM
[20:46] <len-dt> ailo, it would be hard to detect if that was causing problems or not. In audio, then general thing is to run everything in memory... like no swap at all.
[20:48] <ailo> Ok, so while some things might get sluggish, audio won't?
[20:49] <len-dt> ailo no, what I mean is a good audio setup would be to have no swap memory configured.
[20:50] <len-dt> Swap and low latency do not go hand in hand...
[20:51] <ailo> Maybe we should start a wiki page discussing these possible configurations
[20:52] <len-dt> Your example with the sampler ailo was great, each octave might have different samples, or even every third octave. So a sample may sit not being used long enough that it gets swapped out.
[20:52] <len-dt> ailo, video editing may have similar problems.
[20:55] <len-dt> ailo should we start another wiki page about it? or just ask questions on the ones out there about audio already?
[20:55] <ailo> len-dt: Much of these things could be things that the user might want to toggle, or tweak, so that brings again up the discussion on having a -controls application to do this.
[20:56] <ailo> len-dt: I have lost orientation on what pages are out there right now. It's a bit hard to keep track
[20:57] <ailo> There's nothing in the Ubuntu Studio wiki page that links to anything relevant I think
[20:57] <len-dt> Yup, controls is good. maybe even more important than workflow stuff. I don't know half of what is out there let alone keeping track of it :P
[20:59] <ailo> len-dt: I realized earlier that ubuntustudio-controls is available in the repo for precise. I thought it had been removed
[21:00] <ailo> It will override jackd's /etc/security/limits.d/audio.cong file, if used
[21:00] <ailo> And the firewire stuff doesn't apply anymore
[21:03] <ailo> I'm thinking about what would be a good title for the page. Primarily I think it's about evaluting what things apply to a ubuntustudio-settings meta
[21:03] <ailo> And if a -controls application is created, it should belong to that group
[21:04] <ailo> ubuntustudio-settings testing?
[21:11] <ailo> Or just ubuntustudio-settings, and make a subpage for testing etc
[21:13] <ailo> Going to see what the package ubuntustudio-default-settings contains
[21:15] <len-dt> default-settings is mostly look and feel stuff ailo.
[21:15] <ailo> len-dt: Seems so
[21:16] <ailo> Perhaps a ubuntustudio-audio-settings, or ubuntustudio-multimedia-settings?
[21:16] <len-dt> workflow-settings or a settings for each workflow.
[21:18] <len-dt> ailo, So ya, audio-setting, videa-settings, graphic-settings.
[21:18] <ailo> I don't like the workflow term in this situation, since it's not really about changing settings depending on worklow, but more about optimizing for at least audio, but perhaps also video, as you suggested
[21:18] <ailo> Well, I guess that works
[21:19] <ailo> Since I don't do a lot of graphics and video, I tend not to consider those
[21:19] <ailo> Just because I don't even know what would benefit them
[21:20] <len-dt> ailo, workflow is a bad term yes, as there are broad workflows and narrow workflows and it just gets confusing.
[21:20] <ailo> Ok, so if we begin pages for those three, I know at least one that I would like to start filling :P
[21:21] <len-dt> ailo, I am the same. audio is what I know. But I feel very much like the video/graphics/photo part of our distro are largely ignored.
[21:23] <ailo> I think so too. It would be good to have someone on board who knows more about those. If we do start pages for them, we could at least do some research on what might be missing from US
[21:23] <len-dt> Ya, there was at least someone who was talking about monitor calibration
[21:24] <len-dt> Gotta go for now...
[21:25] <ailo> len-dt: Ok. I'll put the pages up, call them: audio-settings, video-settings and graphic-settings. The links will be under https://wiki.ubuntu.com/UbuntuStudio/. I'll just add a few lines of text for now
[22:11] <ailo> len-dt: I put up the pages and made it somewhat easy to orientate by adding parent links. I put links for them in https://wiki.ubuntu.com/UbuntuStudio/TeamResources.
[22:11] <knome> it's a bit of work, but think of starting to use a "header menu" like xubuntu does: https://wiki.ubuntu.com/Xubuntu
[22:12] <knome> ( https://wiki.ubuntu.com/Xubuntu/Toolbox/Menu is simply included from every page )
[22:31] <ailo> knome: Thanks for the tip
[22:31] <knome> ailo, no problem :)
[22:31] <knome> ailo, the big hard work is in the beginning
[22:31] <knome> after that, it's sooo easy to change the menu in all the pages since it's included :)
[22:33] <ailo> knome: That is definately something I've missed
[22:34] <knome> hehe, yeah
[22:34] <knome> it's not obvious
[22:34] <knome> and of course, you need to add the include in any new page you create
[22:34] <knome> but that's the easy part :)
[22:35] <knome> we are just undergoing a huge wiki cleanup too - most done though
[22:35] <knome> that's why the front page is so clean!
[22:36] <ailo> It looks very clean and orderly
[22:36] <knome> i've been pushing any things that users might want to read - including instructions on how to contribute - to xubuntu.org
[22:36] <knome> the wiki serves as things that only developers need
[23:18] <len-dt> ailo, I have to fix your page already...
[23:22] <len-dt> ailo, You have "graphic-settings - testing and documenting possible configs for audio users "
[23:24] <len-dt> ailo, I have changed it to: "graphic-settings - testing and documenting possible configs for graphics and photography users"
[23:24] <ailo> len-dt: Yeah, that was bound to happen. I was copying the same text for all the pages
[23:24] <ailo> I added a kernel category for audio-settings
[23:25] <len-dt> Ok
[23:28] <len-dt> ailo, We may wish to list what we have done so far that goes beyond Ubuntu vanilla, what we have read or heard that might be good, and then which of those things we at US think we should actually change and why.
[23:29] <len-dt> The why would include testing and results.
[23:29] <ailo> len-dt: Yeah. I put a release page for 12.04 on audio-testing, which I thought we could do for all the pages later, to document what is in this release
[23:30] <ailo> Not only for our own sake, but for anyone who later wishes to join the team
[23:30] <len-dt> ailo, does that need to go to another page? or is the list short enough for inline?
[23:31] <ailo> It's probably not a long list, but I think at least we should separate stuff made for a single release
[23:32] <len-dt> Or could we have a short point form list inline and a more detailed set on the other page? I was thinking that if it is on the same page, it is easy to compair where things have been and gone and are going.
[23:32] <knome> remember you can include pages, even sections of pages
[23:33] <knome> if you want to assemble different stuff together later
[23:33] <len-dt> Makes sense
[23:33] <knome> my take is: make the structure as logical as possible
[23:34] <ailo> We can always organize things around later. Perhaps we should not make pages subpages to subpages as I have done though
[23:34] <len-dt> My wife puts things away in a logical order... I've just never figured out what that logic is.
[23:34] <knome> len-dt, lol
[23:35] <ailo> If everything is named /UbuntuStudio/pagename, then we can put things in any order we want
[23:36] <knome> as long as everything related to say, testing, is under US/Testing/, it's relatively fine :)
[23:36] <len-dt> I think what knome is saying is that we can make things separate pages and then use some command to have a part of those separate pages appear on a main page.
[23:37] <micahg> you can do includes in the wiki
[23:37] <knome> our page tree can be seen at: https://wiki.ubuntu.com/Xubuntu/Cleanup
[23:37] <knome> micahg, as i've said ;)
[23:37] <micahg> knome: ah, sorry
[23:38] <knome> micahg, if you have time by any means this week, try to sit down with pleia2 and talk a bit about our pages about development in the wiki+website
[23:38] <ailo> len-dt: I got that, but if we want to reorqanize all the pages later, it would help not naming them as deterministically as I have done for subpages
[23:38] <len-dt> This is a little bit beyond the plain html I learned (3.0)
[23:38] <ailo> Everything will relate to UbuntuStudio, so at least have that as the root
[23:39] <knome> "what is the most usual use case/way of looking at data X"
[23:40] <knome> ^ that's another good starting point for organizing stuff
[23:40] <knome> especially in the ubuntu wiki, since it's damn slow, and you don't want to do kinky stuff all the time ;)
[23:42] <ailo> To begin with, we need to collect all the configs we can find for audio. List them, and add links to relevant pages. 
[23:44] <len-dt> ailo, I am thinking when looking at audio settings that rather than having just the word "kernel", put "Ubuntu Studio uses the Ubuntu kernel with low latency settings enabled"
[23:44] <len-dt> Then the linked to page could have the specifics about how.
[23:45] <ailo> It also involves discussion about the -rt kernel
[23:45] <len-dt> That way without following the link the reader has an idea of why the kernel is mentioned
[23:46] <ailo> But, you could add some descriptive text after the link
[23:46] <ailo> kernel - description
[23:46] <len-dt> Ya, like that.
[23:56] <ailo> Well, it's late. Better use a fresh mind tomorrow, and add some stuff. I like the strategy to first have a look at what we already have, and then as you said, have a look at what we don't have.
[23:56] <ailo> Only later start thinking about testing and applying
[23:56] <len-dt> ok ailo have a good rest. I'll be home tomorrow... sick again...