[00:33] <ailo> This is the patch for threadirqs https://lkml.org/lkml/2011/2/23/513
[00:38] <len-dt> ailo,  I didn't think we were running a 2.6 kernel.. I guess we were at the time.
[00:41] <ailo> len-dt: Linus changed how the versioning is done after 2.6.39. In a way, the 3.x.x kernels are 2.6 kernels
[00:42] <TheMuso> ailo: No I don't know.
[00:44] <ailo> TheMuso: Thanks. Are very occupied in the coming future? I was thinking about maybe starting to document the kernel maintenance bit. At least it would be really helpful for me to get an idea of your current steps to update it
[00:44] <ailo> I mean to ask, are you very occupied in the coming future. Didn't realize I was leaking words
[00:46] <ailo> len-dt: Also, the threadirqs option was included with 2.6.39, if I remember correctly. Either that, or the version before
[00:46] <TheMuso> ailo: Its UDS this week, so will be flat out with that, probably not till I return, eta Monday week.
[00:47] <ailo> TheMuso: Ah, right. Well, I'm not in any particular hurry, so whenever you can is fine with me
[00:47] <TheMuso> Ok no problem.
[00:47] <len-dt> OK, ailo the network-manager is another of those respawn things.
[00:54] <ailo> len-dt: How's your skill in reading C?
[00:55] <len-dt> It has been a number of years to honest. No real training, just read the part of the book needed for the next project ;-)
[00:55] <len-dt> ailo, what would you like me to look at?
[00:56] <ailo> I'm looking at the kernel patch. Unfortunately, I don't read C very well. Trying to figure out where the threadirq function is defined, or whatever, and where it in that case could be enabled without having to add a boot option
[00:56] <ailo> len-dt: I pasted the patch here http://paste.ubuntu.com/972612/
[00:58] <ailo> The interesting part I guess starts at around line 87 .. linux-2.6-tip/kernel/irq/manage.c
[00:59] <len-dt> ailo, I had just sort of figured that out..
[01:02] <ailo> len-dt: I was just reading a comment there, which talks about some buses being slow, like maybe the irq for your network card
[01:03] <ailo> It's a little frustrating not having a good picture of the whole. I really should go to school and study these things
[01:04] <len-dt> ailo, I'm a bit old for that ;-) I've had enough school forever...
[01:19] <len-dt> ailo, it has to be the bit at the begining of manage.c (lines 95 to 105)
[01:20] <len-dt> To really tell I would have to know the way the kernel deals with CL parameters.
[01:24] <len-dt> ailo it seems to be a call to early_param()
[01:24] <ailo> len-dt: I think this might have to do with it too, lines 155,156
[01:24] <ailo>  	sched_setscheduler(current, SCHED_FIFO, &param);
[01:24] <ailo>  	current->irqaction = action;
[01:24] <ailo> Wondering about &param particularly
[01:24] <ailo> But then, I don't really know what I'm reading
[01:26] <ailo> SCHED_FIFO is important at least http://lwn.net/Articles/296419/
[01:26] <len-dt> Part of the problem is that the rest of the file is missing. It would be best to look at manage.c with the patch added. It would add context to things
[01:29] <ailo> len-dt: I suppose you are right
[01:29] <ailo> Still, the part which makes threadirqs option readable is in that patch
[01:31] <len-dt> Yes. but what it does with it is not.... maybe...
[01:38] <ailo> Well, it's always interesting to learn half a story of something new :P. I'm hoping someone will pick up on the subject on LAD and explain how the threadirq option can be added into the source.
[01:38] <ailo> Now it's time to go to bed!
[02:17] <len-dt> QasMixer has some nice features over the xfce mixer for setting levels while using jack.
[10:44] <ailo> len-dt: Well, it seems there is a way to add boot arguments to the source, without the need to hard code it. It can be done adding the argument to /arch/<arch>/Kconfig under a couple of places, but I don't think this is how -lowlatency does it
[12:47] <ailo> len-dt: I started a discussion about the rtirq script on LAD
[12:47] <ailo> http://lists.linuxaudio.org/pipermail/linux-audio-user/2012-May/084809.html
[12:47] <ailo> LAU, I mean
[12:47] <ailo> Anyway, I really want to get to the bottom with this
[12:47] <ailo> You have your NM causing problems in spite of the rtirq script
[12:48] <ailo> I want to know if we can make your problem go away without stopping NM
[12:55] <ailo> len-dt: Also, about the threadirq, it can be passed as a kernel config option argument. Just trying it now
[14:11] <len-dt>  ailo hi, just woke up. I am certainly willing to try things. My netbook is about the worst HW likely to be used for audio.
[14:20] <len-dt> ailo, there is probably slower HW around, but this is about as anti-audio as they get ;-)
[14:22] <ailo> len-dt: Sounds like a perfect machine for testing then
[14:23] <ailo> One thing I realized I haven't really tried is running stuff without realtime privilege, to see what the difference is
[14:24] <len-dt> ailo, I figure so. I played with recording using the internal audio IF and an external (cheap) mixer.
[14:25] <len-dt> I turned the internal card way down (mic boost off) and the mixer as high as I could with out clipping.
[14:26] <len-dt> I used a dynamic mic (no phantom power) with an xlr to phone jack adaptor.
[14:28] <ailo> Running jackd without privileges on -lowlatency is sort of like running jackd with privileges on -generic
[14:28] <ailo> Working pretty decently at -p 128
[14:28] <len-dt> I was able to record quite a quiet stuff. It is not studio quality for sure, but good enough pod caste for example.
[14:29] <ailo> Allthough, I believe -generic is worse
[14:29] <ailo> len-dt: Not bad :P
[14:29] <len-dt> -p 128 is the lowest jack will even start at on my netbook
[14:31] <ailo> I'm more and more thinking that when it comes to system configuration, only the kernel and privileges are absolutely needed. And that the rest is very hardware dependant. Perhaps solvable by hacking the kernel
[14:32] <ailo> It would be nice if the kernel could be easily made more audio friendly, either by patching the vanilla source, or by adding ways to tune the kernel easily either during boot, or runtime
[14:34] <ailo> By patching I mean making it permanent for all kernels that derive from the vanilla kernel
[14:35] <ailo> I don't see why we need to shut things off in order to get rid of xruns
[14:35] <ailo> If audio is prio, then it should be able to make it prio more easily
[14:47] <len-dt> ailo, sorry, I was helping someone on the other channel connect a midi keyboard to qsynth.
[14:48] <len-dt> ailo, I think part of my problem may be the wlan driver.
[14:51] <len-dt> I'm not sure how unless the irq top half has more in it than it should.
[14:59] <len-dt> There may also be internal bus issues.
[15:44] <len-dt> ailo, the netbook is all about doing things with the least. I wonder if the wlan chip(set) uses system bus for some things. So NM tells wlan to scan and waits for irq when done, but wlan uses system bus while scanning preempting the cpu for a short time.
[15:44] <len-dt> I do know the video chip uses system bus, but it knows how to interleave better.
[15:46] <ailo> len-dt: Perhaps it is a driver issue then, and that the wlan is being rude by taking up too much time, or something? But, how do drivers work? Aren't they limited by something else in the kernel, or can you really create havoc for realtime applications with badly written drivers
[15:47] <ailo> If it is driver specific, then all hardware using that drivers could have the same issue
[15:47] <ailo> And in that case it's a matter of doing something to the driver, which is probably not open source
[15:48] <len-dt> ailo, the driver is supposed to be divided into top half and bottom half. the Top half is supposed to answer/reset the interupt and call the bottom half.
[15:48] <len-dt> If the top half does too much that would be a problem.
[15:49] <len-dt> The netbooks share a lot of stuff. It may even be that the wlan chip and the sound chip share things too.
[15:50] <len-dt> ailo, it will be interesting to see how my USB audio IF handles things.
[15:53] <ailo> I'm not sure I got the right picture, but I'm guessing it's something like this. The bottom half is either activated by whatever it is physically connected to, and since it doesn't have it's own way of storing a lot of the data coming through, it will want to pass that on to the top half, which in turn tells the kernel it is ready to send it's data, no?
[15:53] <ailo> Either activated by that, or the top half which wants to send info out..
[15:54] <ailo> It seems to me the problem is not in managing what is coming to the device, but in how network-manager handles it
[15:57] <ailo> And that the kernel allows network-manager to do something odd
[15:58] <ailo> Or, allowing the wlan device to execute a number of tasks in que instead of breaking it up
[16:03] <ailo> I'm being unclear as usual. I need to start reading about this stuff. Never been interested in drivers, hardware and that sort of things before
[16:06] <ailo> len-dt: What did you say the driver was called?
[16:46] <ailo> Found a nice tutorial on how to write device drivers for linux, as well as modules. Both are something I don't really what they are right now. http://www.freesoftwaremagazine.com/articles/drivers_linux http://www.linuxtopia.org/online_books/linux_kernel/linux_kernel_module_programming_2.6/index.html
[16:47] <ailo> I'd love to learn all that right away, but it's time to do other things for a while
[17:00] <Len-nb> ailo, netbook driver is ath9k.
[17:03] <Len-nb> The list of modules is much longer... aht9k, mac80211, ath9k_common, ath9k_hw, ath, cfg80211
[17:09] <Len-nb> probably the ath9k_hw is probably the one that plays with the irq
[17:20] <ailo> Len-nb: Well, at least that driver is FOSS http://linuxwireless.org/en/users/Drivers/ath9k
[17:22] <len-dt> ailo,  the question is if the problem is that or NM
[17:28] <ailo> len-dt: What is the model name for that notebook. I had a crazy idea. I might try to find a used one and buy it :P
[17:29] <len-dt> It says KV60
[17:29] <ailo> And he brand?
[17:29] <len-dt> acer aspire one netbook
[17:30] <len-dt> the acer aspire is a series of netbook/laptops.
[17:33] <len-dt> ailo, I have found it is one of the more usable netbooks. My wife has the HP (don't buy one) which has had more HW problems and has no pgup or pgdn keys even with funct.
[17:34] <len-dt> As a small computer the netbook is wonderful, it is light and small and yet complete.
[17:35] <ailo> I've actually had good experience with HP's
[17:35] <len-dt> I think the HP laptops are probably better, it is the netbook I don't like.
[17:35] <ailo> And ACER I often find is cheap for the performance you get, but it gets hot and noisy instead
[17:35] <len-dt> Cut too many corners...
[17:37] <len-dt> I have not found it too hot... though it does get warm. The atom chip is cooler than others.
[17:40] <ailo> len-dt: The IEEE that I've been using gets pretty hot with the atom, though it's kind of old. More recent notebooks are pretty splendid for the cost
[17:40] <len-dt> ailo, I will say that the HP battery seems to be lasting longer. My 3.5 hour battery is down to about 1.5 or so hours.
[17:40] <ailo> The HP's I've seen around seem to last forever
[17:41] <ailo> A more recent HP was a lot worse quality wise. Really bad keyboard
[17:41] <ailo> But there are thousands of models. Some are bound to be bad
[17:42] <len-dt> ailo, The HP has a less nice wlan chip, it drops connection more often than the acer. Not a big thing though, might be antenna placement.
[17:42] <ailo> I think I need to change strategy. Perhaps assemble a list of computers that are know to cause problems, and then try to find one for sale. 
[17:43] <ailo> I should put an ad: Looking for really badly behaving hardware. Will pay a reasonable amount for it!
[17:44] <len-dt> I just added a note to the ubuntu aspire page about the internal mic. The left and right have to be unloacked and one full one and the other full off.
[17:44] <len-dt> The HW sends left and right inverted and alsa mixes them...
[17:44] <ailo> len-dt: You should probably mention this at alsa-devel list, and maybe a pulse list as well
[17:45] <ailo> Or maybe a bug-report?
[17:45] <ailo> To alsa, I mean
[17:45] <len-dt> The pulse/alsa devs are aware. "there will be no fix"
[17:45] <ailo> ok
[17:45] <len-dt> The problem is that it can't be auto detected.
[17:46] <ailo> It's not the same at each boot?
[17:46] <len-dt> The same chip is used different in different models.
[17:46] <len-dt> So if they fix my problem they break someone elses box
[17:47] <ailo> And they don't do model specific fixes
[17:47] <ailo> Why did you think the HP was worse again? M)
[17:48] <ailo> ;)*
[17:48] <len-dt> I don't know if they can. 
[17:49] <len-dt> keyboard is lacking keys I use all the time. wireless seems less sesitive. HD light is hard to see. no line in jack for audio.
[17:50] <len-dt> Seems to me I had problems with the card reader too at one point. I haven't tried it for a while though.
[17:50] <len-dt> the card reader on the acer had problems at one kernel release too.
[17:51] <len-dt> Its funny because the OS sees it as a usb device and a usb stick or a USB card reader works fine...
[17:51] <len-dt> even with the same SD card.
[17:53] <len-dt> HP has had problems with the sound. But not with 12.04, when we first got it I had to manually switch the output from headphone to speaker... some config change or something. It seems to be fixed though. I put 12.04 in and it just works.
[17:55] <ailo> I'm getting more and more convinced about the HP. At least for audio use :P. I would guess you can run jackd at a lower latency and without xruns caused by the network manager
[17:56] <len-dt> But no audio in.
[17:56] <len-dt> So what would the point be?
[17:59] <Len-nb> ailo, when I get the usb audio IF, I will try it on both.
[18:02] <ailo> Len-nb: I,ve rarely used builtin devices for recording, so that would be no problem for me. But, when usb is the only option otherwise, I guess that is a problem in itself. At least from how it seems
[18:02] <ailo> I think this must be the single biggest problem in the linux pro audio world right now in fact
[18:03] <ailo> In a modern world you'd like to be able to move away from pci cards
[18:04] <ailo> Firewire is great, if you have a port for it. For now, that is the only type of notebook I could imagine getting for audio use
[18:04] <ailo> Also since I already have a functioning firewire device
[18:05] <ailo> We use my friends macbook at times with it, since we only use puredata
[18:05] <ailo> I'd love to install linux on it, but it's not my hardware, so :D
[18:07] <Len-nb> ailo, the big plus with the netbook is size. If there was a proper USB2.0 audio standard then I think the max number of inputs likely to be used would be available.
[18:08] <Len-nb> Really, once I start carrying more than two mics, the size of a notebook computer doesn't matter and the advantage of using a netbook is gone.
[18:10] <Len-nb> ailo, having said that... the one port (fast even) that every computer has these days is Ethernet. It would be nice to see cheap ethernet sound IFs.
[18:12] <Len-nb> With an open standard. It should be possible to add an ethernet plug to any of the FW/USB sound IFs now available.
[18:13] <Len-nb> Just put jack-net on there....
[18:17] <Len-nb> ailo, how about a little box with two eth connectors and one FW connector.
[19:13] <Len-nb> ailo, just put a message on the list with some thoughts about latency and workflows.
[19:16] <ailo> I still don't believe in shutting down stuff that should work
[19:16] <ailo> Something like the NM should not be causing problems for audio
[19:16] <ailo> Nothing should
[19:17] <ailo> I can understand not including processes that are useless on a audio desktop
[19:17] <Len-nb> I conclude that the few uses where really low latency matters are not uses where networking needs to be on.
[19:17] <Len-nb> we have talked about a "record mode", but I think it makes more sense to think in terms of latency levels.
[19:17] <ailo> I don't agree with that
[19:18] <ailo> I think that is backwards thinking suitable for 2001
[19:18] <Len-nb> we have a new ISO in our daily.
[19:18] <ailo> A standard desktop is not causing any problems on most systems
[19:19] <ailo> I can put 100% load on both my cores, and that will not affect audio performance
[19:19] <ailo> Or not much
[19:19] <Len-nb> I agree with that because even my 8 year old desktop has no problems with it.
[19:20] <ailo> I'm more into not having to do any adjustments at all, and that someone can add stuff to their desktop without breaking audio performance
[19:20] <ailo> Since xruns aren't caused easily
[19:21] <ailo> All I need to do is add two config options to the kernel and recompile + add realtime privilege
[19:21] <ailo> That's it
[19:21] <ailo> All desktops work just as well. Gnome3, XFCE, Unity
[19:22] <Len-nb> ailo, for most uses, with latency set to reasonable levels. This netbook is fine.
[19:22] <ailo> No software that I know of is causing xruns for me
[19:22] <ailo> Instead of making things complicated for the user, it might be better to solve some techincally complicated problems
[19:23] <ailo> Since then there would be no need to fix anything from the user side
[19:24] <ailo> Also, I don't see why LTS 2012 should put too much weight on being compatible with machines from 1002
[19:24] <ailo> 2002*
[19:24] <ailo> It's going to be the LTS for 4 years
[19:25] <ailo> And 4 years from now, computers from 2002 will be 14 years old
[19:25] <ailo> That's pretty old
[19:25] <Len-nb> the only use that would cause problems with this netbook are live uses. And really i am not sure that this is the appropriate hardware for that seeing as HW synths are more robust anyway. and so are guitar effects. maybe cheaper too.
[19:25] <ailo> 5 years back makes more sense to me
[19:26] <Len-nb> ailo I was not suggesting making 8 year old machines work, only pointing out I have one that does... without any trouble or extra configuration.
[19:26] <ailo> The older netbooks are a bit like P3 computers, aside from having slightly better graphic cards
[19:27] <ailo> At least the single core ones
[19:27] <Len-nb> This Netbook is less than two years old
[19:28] <Len-nb> The new ones are not any better. They are not made for audio, but for browsing. I would not suggest that an audio distro be based on one.
[19:29] <ailo> I didn't mean to say we shouldn't support netbooks. I think they are fine, and support reasonable graphic load as well. Their weak point may be processing power, which is not really that much affected by the desktop and its processes in my experience
[19:29] <Len-nb> It is interesting to see how much can still be done. I just want to see how far I can push it.
[19:29] <ailo> So, they will perform poorly nevertheless, except they can support a more modern UI
[19:34] <Len-nb> The nice thing is that they can be used for audio at all. And they can do it reasonably well. One's expectations have to fit the HW.
[19:35] <Len-nb> ailo, anyway, assuming a reasonably new machine.... what changes should we be making for 12.11 now that there are daily builds...
[19:38] <Len-nb> ailo, I have been looking qasmixer for audio IF that do not need their own mixer.
[19:39] <Len-nb> This is not to replace pavucontrol, but to be in the mixers menu
[19:39] <Len-nb> for use when setting up levels to use with jack.
[19:44] <ailo> I'll have a look
[19:47] <ailo> Len-nb: Pretty neat
[19:48] <ailo> Nice to have both pulse and alsa there
[19:48] <ailo> Strange things happen when I move the pulse level
[19:49] <ailo> Both pcm and master are affected
[19:52] <ailo> I can see that some people would prefer that to the pulsemixer
[19:52] <Len-nb> ailo, try setting pavucontrol beside and control PA with that while watching what happens to the alsa levels.
[19:53] <Len-nb> I was not thinking to replace the pulse controller, but the xfce mixer
[19:54] <ailo> I didn't mean that you should replace it
[19:54] <ailo> But, I still think some people might use this one more often than pavulcontrol
[19:55] <Len-nb> It is nice to everything on one page.
[19:55] <Len-nb> I could even use it for the envy24 for most things.
[20:06] <ailo> I do think it would be good to have a trouble-shooting helper
[20:06] <ailo> Sort of like the "record mode" you have been talking about
[20:07] <ailo> I guess it would be convinient to be able to toggle many things with one button
[20:07] <ailo> But, I wouldn't want to call it "record mode", since it's really more of a last resort
[20:08] <ailo> More like a workaround for specific issues
[20:12] <Len-nb> ailo, "record mode" was not my name for it. just what was being used.
[20:12] <Len-nb> low latency tweak might be better.
[20:13] <ailo> I don't think it would get you lower latency either
[20:13] <ailo> Shutting off NM would only fix issues for normal latency on certain machines
[20:13] <ailo> It won't lower it for anyone
[20:14] <ailo> And I don't expect there are any other tweaks that will do that either
[20:14] <ailo> I don't expect there will be anything that will enhance performance much at all
[20:16] <ailo> That is why I object to the idea of having a "record mode" button, because it would be falsely suggesting that you do get a performance boost, when most likely it does nothing at all
[20:19] <ailo> Other than shut down things that you might now need to shut down
[20:25] <ailo> Just out of nowhere I'm having huge problems with xruns using my builtin card
[20:26] <Len-nb> ailo,  on this machine minimum latency without NM is -p128 but with, it is 1024 with no xruns. 
[20:32] <ailo> Len-nb: Yes, and I'd say 128 is quite a high latency on a modern system, so we're not talking about improving latency. More so about fixing an uncommon problem which prevents you from having "normal" operation
[20:34] <ailo> The goal should be at least 64 on a fairly modern machines, like dual core and onwards
[20:35] <ailo> 128 to me is a bit too slow
[20:35] <ailo> Depending on the machine probably, but still
[20:36] <ailo> Netbooks are a bit like P3 when it comes to processing power, so 128 is probably a good lowest latency for them
[20:37] <ailo> That's what I would get with a P3 and a realtime kernel, not too long ago
[20:51] <len-dt> ailo, I will see what I get with the usb IF when I get it. The 128 may be a hardware thing to get away with a cheaper card.
[21:29] <ailo> 20
[21:41] <ailo> len-dt: Interesting. The kernel that had "threadirq" put as a config option for the build was giving me xruns like crazy
[21:42] <ailo> With the rtirq script using that kernel I got the opposite effect of what you would expect
[21:42] <ailo> I'm on the same exact kernel now with the only diff being that this boot option was not added during the build
[21:43] <ailo> "threadirqs"*
[21:50] <ailo> It's the same with using it during boot-time. Just checking to be sure :P. I didn't notice this before
[21:58] <len-dt> ailo, fun with tuning.
[21:59] <len-dt> amybe that option turns it off?
[21:59] <len-dt> s/amybe/maybe/
[22:11] <ailo> len-dt: No, it turns it on for sure
[22:11] <ailo> I've found that this machine will start misbehaving with the rtirq script enabled
[22:12] <ailo> I double-checked with the -lowlatency on Ubuntu Studio, and it's the same thing
[22:13] <ailo> Don't have the energy to find out why today. But I'm coming to the conclusion that in normal cases the rtirq script is superfluos and should perhaps only be used to fix problems
[22:14] <ailo> Having it on by default may cause just as many problems as it fixesa
[22:14] <ailo> Or the script just needs to be edited
[22:15] <ailo> len-dt: Did you ever try moving moving away the script and try without it?
[22:16] <ailo> All though, it doesn't fully help because threadirqs are enabled anyway
[22:16] <len-dt> ailo, no. I haven't. It doesn't seem to hurt this desktop anyway.... well I did move all the pci cards around.
[22:16] <ailo> We need a kernel to test without that option enabled, but with PREEMPT config
[22:17] <len-dt> ailo, the web pages to do with it do say that somethings are high with out the script.
[22:19] <len-dt> USB is kinda wonky anyway. on some machines some of the internal peripherals use USB ports too
[22:19] <ailo> len-dt: Normally the rtirq script should do nothing at all, since normally you don't have a problem. I never heard of someone getting problems because of it though, and this is the first for me. That is why I would like to see if it is the same for you
[22:19] <len-dt> ailo, How do I test then?
[22:20] <len-dt> How do I turn it off?
[22:20] <ailo> len-dt: First we need a kernel without the threadirqs enabled, since -lowlatency has it hardcoded
[22:20] <ailo> It's edited into the source code. I checked with abogani before
[22:21] <ailo> I could build one and pass a link later
[22:21] <ailo> Maybe tomorrow, or the next day
[22:21] <len-dt> OK, whenever.
[22:21] <len-dt> As always I'm not always available...
[22:24] <ailo> len-dt: What arch btw?
[22:24] <ailo> No matter. I should build both anyway
[22:26] <len-dt> ailo, 32 bit... both machines
[22:28] <len-dt> ailo, I just took out the yamaha rm602 mixer and put the mackie 1604 in... 
[22:29] <len-dt> there is a big diff in sound even with an avi file.
[22:29] <ailo> len-dt: That Yamaha looks a bit old :)
[22:30] <len-dt> The mackie is not much newer actually. It is one of the first 1604s with the 6 mic preamps
[22:31] <ailo> I have an older Heath & Allen, which can be controlled with a commodore 64. Used to cost a whole lot. Got it cheap some years ago. Killed it unfortunately :(
[22:31] <ailo> Or is it Allen and Heath?
[22:31] <len-dt> ailo, the yamaha was made to use with an old cassette porta studio kind of setup.
[22:31] <ailo> Been mostly using a Behringer, 16 ch mixer. Not bad really
[22:32] <ailo> len-dt: Ok, so it wasn't exactly top notch
[22:32] <ailo> With our live setup with the band we're down to using only the firewire device
[22:33] <len-dt> It was easy to access and hook up when we moved in. There wasn't room for the mackie. Now that I need the phantom power...
[22:33] <ailo> That and a laptop, + our instruments
[22:33] <len-dt> Ya mixers are not really needed for recording any more.
[22:34] <len-dt> less stuff to hook up and everything.
[22:34] <ailo> I have a couple of really decent preamps, and mics to go with them, so vocals, and anything acoustic stereo is going to sound really ok
[22:35] <ailo> For the rest it's mostly sm58 and mics like that
[22:35] <ailo> A couple of audo line CM3's
[22:36] <len-dt> Thats why I'm getting the ART pre. It is a lot easier to lug around than the mackie.
[22:36] <ailo> You only need a lot of mics for drums, or when you record stuff live
[22:38] <len-dt> I started on drums, but I haven't had a kit for years now.... I have an 8pad box and hydrogen...
[22:39] <len-dt> I kind wish I at least had a snare... so many different sounds depending on how it is played.
[22:44] <ailo> I'm a drummer too, though I began plauying guitar at the same time. I also play piano. Have a trumpet, but haven't had the time to learn it. Strange instrument :P. Played some violin too
[22:44] <ailo> So, mostly string instruments and percussion