Live from Fedora Moonbase Alpha, part 2.

OK, let’s assume you’ve got your mic set up, and you want to make sure you have sound coming to the computer. This is easy to check by selecting System > Preferences > Sound, or right-click the volume control in the notification area and choose Sound Preferences. Then select the Input tab in the dialog box.

You’ll see a list of sound devices attached to your computer, and (if applicable) different connectors available. Select the proper device, and then the connector for your microphone, and you should be able to test the mic and see the level in the display.

You should also check the Output tab, and choose a sound output that goes to some headphones. You don’t want to select speakers whose output will be picked up into the mic, especially since at higher volumes, that causes feedback. (You’ll know feedback from the woooooooo sound that makes you want to pull your own hair out.)

Now you can run the Audacity program to do your recording. You can use other apps as long as they’ll support the audio framework you’re using. In Fedora 12, Audacity works great with PulseAudio. If you don’t have it installed, just use the Add/Remove Software tool, or run pkcon install audacity at a terminal. In Audacity, open up the Preferences dialog by hitting Ctrl+P or choosing Edit > Preferences from the Audacity menu. Choose Devices on the left side:

In the Playback and Recording selections, you’ll generally want to choose pulse. You can use the Sound Preferences tool described above to switch devices around as needed. You can also use the PulseAudio volume control utility (provided by the pavucontrol package) to do on-the-fly switching and metering. It’s a pretty handy tool so I recommend it, especially on distributions that do PulseAudio correctly like Fedora does.

Now you’re ready to record! You can just hit the big red button to start your recording. If you find you’re not capturing what you thought:

1. Check your sound preferences again
2. Make sure your mic is plugged in and registering sound in the Sound Preferences tool using the handy VU meter
3. Make sure your output device is performing correctly and check levels in the Sound Preferences tool

In part 3 I’ll point out some helpful post-processing you can do with the LADSPA plugins, to make your recording sound fuller and more acceptable to listeners.

Live from Fedora Moonbase Alpha, part 1.

I finally picked up a piece of equipment I’d wanted for a while — a decent desktop-mounted boom arm to use with a condenser mic for recording podcasts. After a little review reading I settled on the Heil PL-2T and I’m pretty pleased with its looks and performance. Not only is it quiet and very sturdy, but the tension springs are well hidden in the housing, and there are handy removable cable guards so you can keep the mic cable routed in the housing.

The mic I have mounted is not a super-expensive model. For those readers who are considering podcasting but don’t know where to start when it comes to mics, a versatile choice is a large-diaphragm condenser mic like this Superlux CM-H8A. There’s a wide selection of Chinese-made condensers like this to choose from; some are even marketed nowadays under well known names in recording like M-Audio and Shure. They tend to run in the $80-150 range.

As can be expected, quality varies. If I was looking for matched sets, I’d probably have to do a little testing, and go back and forth with a physical store taking home and returning mics to get close enough for comfort. That’s a consequence of paying $100 for a condenser as opposed to $400+. But since I only needed one solid mic to record voice in a non-professional context, I didn’t want to waste a lot of time dithering and hand-wringing.

You’ll notice I don’t have a shockmount on this mic — that’s something else I kept meaning to pick up and simply forgot when I ordered the boom arm. That will be next.  However, if I’m not banging up against my desk or the boom arm, it’s not a critical worry right now. I’ve had this mic for a while and used it in a variety of contexts, and I can cut out the vast majority of rumble simply by engaging a 75Hz cutoff on my mixer, or using the mic’s internal switch which cuts off around 80 Hz. (For those of you who aren’t audio geeky, that’s a pretty low bass frequency, the kind that would show up from a “thump” that resonated through the mic from something it was attached to either directly or indirectly.)

The pop filter is essentially a gooseneck arm attached to a circular frame that has two layers of nylon inside, a little less than a centimeter apart. That sits between the mic and my mouth to keep plosives (sounds like ‘b’ and ‘p’) from spiking the mic levels and sounding like I’m spitting into the listener’s ear.*

Although I have a large mixer with mic preamps built-in (as most prosumer models do), there are alternatives such as the Alesis USB mini-mixer Clint Savage uses at Fedora events, or a dedicated little mic preamp such as a venerable ART Tube MP. Each method has its advantages and disadvantages depending on your level of comfort with audio processing and twiddling.

• The Alesis shows up on a Linux system as a USB audio device that can be selected in Audacity or other sound recording software.
• When using a standard preamp or a mixer (not USB or Firewire equipped), you need to route the signal to an existing audio device on your computer.
• Without some physical tube hardware in the signal path before it gets to the computer, some extra post-processing is called for to warm up the sound. (More on that later.)

In my next post, I’m going to go through one possible process of voice recording, using entirely free software.

* They’re usually not more than $20, but if you’re on a super-tight budget you can actually build one of these using a wire coat hanger, ladies’ pantyhose, and a wide solid circular object like a used-up roll of masking tape or a rubber gasket to keep the layers of nylon apart, securing it with a strong adhesive like duct tape. (It will look horrible, but it can get the job done.)

Bring on the skins.

Did you know that you can use Fedora trademarks to create skins, application themes, Firefox personas, and other such application sprucer-uppers, pursuant to our trademark guidelines? You can find this change, along with complete usage guidelines, through our trademark guidelines page on the Fedora wiki.

Power punch.

Fedora Talk, Gobby, and IRC make for a great combination when it comes to inclusive conferencing. I joined a bit late, but there’s a fantastic online-enhanced teleconference going on today to tease out all the details around No Frozen Rawhide.

Developers and maintainers will undoubtedly have questions about how the NFR changes might affect the different things they do every day in Fedora. So we have an excellent opportunity to get all those details elucidated, and then written up for easy reference.

The write-ups are being built as different use cases that will help us be crystal-clear about how NFR might affect someone (if at all) depending on what they’re trying to get done. Whether it’s building a brand-new package, pushing an update into the new pending tree, helping to test one of the branches, administering a mirror — there will be clear information for everyone.

Fedora Talk is great for a high-bandwidth, “Oh, I see what you mean” type conversation. But we scribe everything down to Gobby where anyone can watch the work as it happens — which in this case, is the development of the use cases.  And we’re also on IRC Freenode at #fedora-nfr to invite questions and comments.  This multiplication of communication doesn’t have to be confusing as long as everyone present is focused on the tasks at hand. On the contrary, it gives us many ways to react to input and get the work done faster, and more collaboratively.

Thanks to Jesse Keating and John Poelstra for putting this little mini-conference together!

Incidentally, our Docs team has been talking to Shaun McCance about using this type of multi-channel solution at the Desktop Help Summit so the conference can get more assistance and participation from remote attendees. It’s worked well at our Fedora Activity Day events which are very much the same kind of “can-do” context.

Against the morning’s white.

Musings on the muse.

I’ve been writing so much this week it’s hard to believe my blog’s empty thus far. Surveys, email interview questions, internal stuff for Da Hat — but no blogging!

And of course I’m low on time for tonight, but I wanted to respond to Kevin’s post about what people love to do in Fedora. I have a short list of stuff that I love to do but for which I unfortunately don’t get us much time as in the past.

• Writing and maintaining documentation on the wiki, website, and in formal guides. That’s how I started with Fedora and I still love to do it when I can.
• Bumbling my way through PyGTK to learn more about GUI programming.
• Meeting and talking to Fedora contributors at Fedora events. I wish there was a way for me to clone myself so I could be at more events and do this more often!

Thanks for the reminder that as we think about big-picture items, which people throughout the community ask for, we also should think about the small things as well. Good things come in small packages, including satisfaction from learning something new, or helping someone else out. What’s great about Fedora is there are plenty of ways for small and large scale work to make free software better for everyone.

M-stone.

According to the Statistics page on the wiki, last week we passed 1 million IP checkins for Fedora 12 systems!  This is roughly on par with where Fedora 11 was at the same time after its release, although it’s hard to discern the actual number of installations worldwide.

Although IP addresses are a convenient and anonymous way to gather these statistics, they’re not foolproof.  But given our past experience and analysis, which you can see in more detail in the section on yum check-ins, we are confident we’re significantly undercounting installations. There are millions of existing systems running Fedora 11 and other previous releases as well, although older systems are no longer receiving updates and we recommend that people try the latest and best free software available. And in a significant number of cases there are NATs and proxies that further impact this undercounting.

The above considerations influence me to be skeptical when I hear answers to the question “How many systems are running ‘Foo’?”. Is the claim supported with hard numbers? Are those numbers public and independently verifiable? As part of Fedora’s dedication to transparency, I definitely take those questions seriously.

We’re always trying to think of ways to improve our statistics gathering that continue that tradition of transparency, respect users’ privacy, and support the globally mirrored infrastructure that works so well (thanks Infrastructure team!). If you’ve got a suggestion that takes those factors into account, and you can help implement it, let me and other folks know through the advisory-board list.

Events FAD 2010.

I attended the Events FAD 2010 that happened this past weekend, along with Mel Chua, David Nalley, Clint Savage, Jon Stanley, Dennis Gilmore, Steven Parrish, Chris Tyler, and Max Spevack.

I arrived on Thursday evening, in time to catch Max and Greg at the office and say hi. Most of the remaining short time was spent sending a few emails, trying (in vain) to find a replacement battery for my camera since I managed to leave mine at home, and checking in at the hotel.

Friday we had a massive brainstorming session on what we lovingly called “FUDCon 2.0,” where we went over past event survey results and the comments that we had gathered from blogs and other feedback mechanisms. By far the two most consistent threads running through the discussion were:

1. the limitation on time imposed by our current model of one day of BarCamp technical sessions, plus two days of hacking
2. the need for regional FUDCon events to reflect the region where they’re held

In the North American region, the most straightforward solution to allow our event to scale better is to increase the length of the technical sessions to two days. This could result in a four-day FUDCon event as opposed to a three-day event in the past. Looking far ahead, I wonder if we would benefit from a week-long event, where besides educational value we could also tap into the planning value of having so many contributors in one place. But obviously that is a much more expensive event. So first things first, and the expanded length of technical sessions allows us to hold fewer tracks at one time, but still accommodate a similar total number of talks. And that solves one of the most frequently heard complaints, which is that people can’t attend every talk they want (or in some cases need) to see.

The second problem is more subtle, and we spent much of the FAD both generating a planning calendar for future premier Fedora events, and mapping out a better process for actually producing them. In the past, a premier event like FUDCon has been arranged by a very small number of people (sometimes just one or two, like me or Max). With FUDCon Toronto 2009, we debuted a dedicated fudcon-planning list and other open processes that helped other people get involved — especially a ground team at the FUDCon location.

In the future, contributors will be able to look at a calendar far in advance of the event, propose a FUDCon location through a streamlined and simple “bid process” (it’s not the Olympics, after all!), and we can use that information to figure out where and when to assign funding. Very helpful for the Community Architecture team which takes care of the budget for these events, and because the planning would use community centered, open resources and processes such as the list and IRC, anyone in the community can get involved in the process, helping with collateral design and creation, content decisions, FUDCon Live, and so forth.

During Saturday and Sunday, snow and ice kept us at the hotel, but we assembled in the hotel’s boardroom to work on from morning to night (and into the wee hours in some cases!). During this time, I worked quite a bit on the process docs for much of this, in collaboration with the other attendees, both remote and in person — particularly the sponsorship process that we have been successfully using for several months now for premier Fedora events.

Although I didn’t get to spend much time on code-type bits, I was very happy that the FOSSLC guys joined us throughout the event to hack on freeseer, their remote A/V capture utility which we are planning to use for future events. It’s very important to us in Fedora that we achieve our free software goals with free software, and the FOSSLC folks have been very excited about getting a fully free toolchain working. Clint Savage took the lead on working with them, and that partnership has already yielded fruit, like Ogg Theora support and trading some development model information that will help freeseer grow even faster in the coming weeks. If you run an event, whether you’re interested in doing it with 100% free software or not, the FOSSLC guys do incredible work and we highly recommend them. You can see some of their work at the FOSSLC site.

As it turned out, the sun came out on Sunday, bright and clear, and with it the contractors plowing the hotel lots and other side streets. Along with the natural melting, we were all able to get out of town successfully, delayed in some cases but not discouraged. While I was sad that we didn’t get to see more of Max in person because he (along with everyone else) was snowed in, we got a lot done through online collaboration, and the FAD was time very well spent. A very sincere thank you to all those who showed up and participated, both in person and virtually — the effort you put into the event made it a great success!