Archive for the ‘recording gear’ Category

off to vcon!

Off to VCON! A reminder of my schedule:

That’s a big, big room they’ve given me on Saturday night. C’mon out and fill it!

Since I’ll be doing a couple of technical presentations today (scroll down to this post to get the handouts), here’s a nice presentation on digital audio processing, on the waveform level. There are other demonstrations I’d like him to include, but there are already many, and it’s quite interesting no matter how you look at it. Enjoy!

waveform rectifiers are weird

Playing with a waveform rectifier. It’s external hardware, so to bounce stuff through it, I have to route out through analogue and back in, old-school. That’s fine, but kind of slow.

The odd part is, to me, the difference is substantial – at least, when the drums are thrown at it, not so much with the zouk and vox – but Anna doesn’t hear much of a difference. I wonder which is more typical?

Trying to throw an entire drum mix through it and using that in place of the separates Does Not Work, though. If I want to use this even as an incremental change tool, I should use it live (as recommended by maker, actually) or bounce per-instrument. That’s also suggested as reasonable in the manual.

Either way, it’s not showing up that hugely in the mix, even to me, and a lot of what this is doing is reminding me how much better the headphone amp in my workstation is than the headphone amp in my Macbook. By which I mean damn.

But at least I get to say “I have a waveform rectifier.” That’s cool.

possibly some intel wtfery

UPDATED: See below.

Okay, so the latest: we’re pretty sure this is not actually xorg now. We’re back to session saves. Not I/O in general: specifically session saves, which is to say, saving the entire project.

See, the every two-minutes thing turned out to be a new feature in Ardour I hadn’t noticed: scheduled auto-saves, which turned out to be… every two minutes. Saves also happen whenever you enable master record, which is the other time I see it. So we’re pretty damn sure it’s Save Session.

We know it’s not I/O in general. Recording is actually far more I/O intensive, and once record is enabled and the save process is done, you can record all you want to without any problems. Bouncing existing material is also a complete nonissue.

It’s also not a filesystem issue: it happens even with RAMdisk, which is faster than anything else. And the behaviour reproduces itself perfectly on my non-USB on-motherboard Intel HD Audio card, so it’s not USB.

Now, to get into more details, I’ve gone digging deep into Ardour source code. BUT I HAVE AN IDEA, so bear with me.

In the source code, most of save happens in libs/ardour/session_state.cc

Save works fine when plugins are deactivated but triggers XRUNs – which means buffer overflows due to more than 100% digital signal processing capability (DSP) is available – when plugins are active.

That’s any kind of plugin, and it doesn’t seem to matter how few.

Save session calls a lot of things including get_state(), which in turn gets latency data from plugins via (eventually) latency_compute_run(), the code for which is the same! in both lv2 and ladspa plugin interfaces.

latency_compute_run() calculates the latency by actually running the plugin. Not a copy: it runs in place the actual plugin that’s in use.

This is all in here:
libs/ardour/lv2_plugin.cc
libs/ardour/ladspa_plugin.cc

latency_compute_run() activates the plugin even if it’s already activated (!) then deactivates it on exit (which I guess is stacked somehow because they don’t deactivate in Ardour itself) and runs a second thread on the same instance of the plugin. (Presumably, because how else I guess?)

This strikes me as a minefield.

And so, an hypothesis: this is causing the hyperthreading predictive Intel cpu I have to retrace because of bad prediction and/or bad hyperthreading.

Penalty for this in Intel land is large, and I have seen commentary to the effect that it is large in the Intel Core series I have. I suspect that the two versions of the active plugin may be continually invalidating each other(!) for the duration of the latency test. It may even be causing the on-chip cache to be thrown out.

This would explain why it stops being an issue when the plugin is not active.

Thoughts?

ETA: Brent over on Facebook pointed me at this 5-year-old bug, which led me to try fencing Ardour off to a single CPU. And when I do that… the problem goes away. Now, this sounds terrible, but I’m finding even with my semi-pathological test project (which I built to repro this problem) I can get down to 23-ish ms latency with a good degree of safety. So clearly, no matter what’s happening, it does. not. like. multicore.

That said, with hardware monitoring (which I have) that’s plenty good enough. I could live with 60ms if I knew it was safe. 23ms being safe (and 11.7 being mostly ok but a little iffy)? Awesome. Still: what is this?

ETA2: las, who wrote most of and manages the plugin code, popped on and said what I described would totally happen … except the latency recalculation doesn’t actually get called during save. I appear to have just misread the code, which is easy to do when all you have is grep and vi and an unfamiliar codebase.

ETA3: Well, hey! Turns out that setting Input Device and Output Device separately to the same device directly instead of setting Interface to the device (and leaving input and output devices to default assignment) means that Jack loads the device handler twice, as two instances – once for input, once for output. Thanks to rgareus on Ardour Chat for that pointer.

I can see how they get there, but there really ought to be a warning dialogue if you do that.

That means on a single-processor I can get down to 5.6ms latency and past my pathological repro tests cleanly. This is the kind of performance I’ve been expecting out of this box – at a minimum. Attained. I could in theory not even hardware monitor at these speeds – tho’ you really want to be down around 3ms for that ideally. (I can actually kinda run at 2.8ms – but it’s dodgy.) Since I have hardware monitoring I’m setting it all the way up to 11.6ms just to keep DSP numbers down. But any way you look at it – this is awesome.

I was really hoping to get this system back to usability before heading off, and – success! Thanks to everybody who threw out ideas, even if they didn’t work, because at least there are things we get to rule out when that happens.

Also, I’ve started putting together a dev envrironment (with help from Tom – thanks!) so I can explore this further when I get back into town. Saves shouldn’t be doing this. It’d be one thing were it just to HD and not to ramdisk, that’d be fine. But to ramdisk? No. Just… no. And the processor core thing, and the plugins-active-vs-not things are just odd. Maybe I can find it.

linux filesystem performance help

NEW READERS: IT’S NOT ABOUT THE FILESYSTEM ANYMORE BUT IT’S STILL BROKEN: SEE UPDATES AT BOTTOM OF POST. Addressing filesystem performance only partly fixed it. Thanks!

Since always, I’ve had latency issues on my digital audio workstation, which is running Ubuntu Linux (currently 12.04 LTS) against a Gigabyte motherboard with 4G of RAM and a suitably symmetric four-core processor. CPUs run 20%-ish in use most of the time (and all the time for these purposes), and I never have to swap.

In this configuration, I should be able to get down to around 7ms of buffer time and not get XRUNs (data loss due to buffer overrun) in my audio chain. 14ms if I want to be safe.

In reality, I can’t make it reliably at 74ms, and that has hitches I just have to live with. To get no XRUNs or close to it I have to go up to like 260ms, which is insane. I even tried getting a dedicated root-device USB card – I’ve long assumed it was some sort of USB issue. But no.

With some new tools (latencytop in particular) I have found it. It’s the file system. Specifically, it’s in the ext3’s internal transaction logging. To wit:

EXT3: committing transaction     302.9ms
log_wait_commit                  120.3ms

If I turn off read-time updating, which I tried last night, I get rid of 90% of the XRUNs, because the file system does about 90% less transaction logging to update all those inodes with new times.

But any attempt to write – well, you can guess. Even the pure realtime kernel doesn’t help; I compiled and installed a custom build of one today, but apparently this is still atomic: I get exactly the same behaviour. I may be able to live with that to some degree, because it’s a start-and-stop-of-writes thing, and as long as it doesn’t trigger during writes, I can get by.

But it’s bullshit, and it pisses me off.

I’m currently in progress of updating ext3 to ext4. I’d like to think that would solve it, given ext4’s dramatically better performance, but I have no such assurances at this point. I genuinely thought the realtime kernel might do it.

DO YOU HAVE ANYTHING YOU CAN TELL ME, DEAR INTERNETS? Particularly about filesystem tuning. Because this shouldn’t be happening; it just shouldn’t. Honestly, three tenths of a second to commit a transaction? I’ve been places where that kind of number was reasonable; it was called 1983, and I don’t live there anymore.

Anybody?

THINGS IT IS NOT:

  • Shared interrupt
  • This particular hard drive (the previous drive did it too; this one is faster)
  • ondemand CPU scheduling (i’m running in performance)
  • this particular USB port or a USB hub or extension cord or any of the sort
  • bluetooth or other random services (including search)
  • Corrupt HD
  • Old technology (it’s SATA; the drive is like six months old)
  • lack of RT kernel. I built this RT kernel today.
  • Going to be solved by installing a different operating system. Please don’t.

ETA: I got the ext3 filesystem upgraded to ext4, which made all those above numbers get dramatically smaller, but no further XRUN improvement. So I then disabled journaling, a configuration which outperforms raw ext2 in benchmarks I saw, and the machine is screamingly fast despite the RT kernel…

…and it hasn’t made one goddamn whit of difference in the remaining XRUNs. WTF, computer? WTF.

ETA2 (23:51 18 August): Okay, while screwing with the filesystem did solve many XRUN problems, there are still other XRUNs which are apparently unrelated, most notably, the master-record-enable XRUN. Even moving the project to a tmpfs RAM disk and running from there produced identical results, so I’m concluding this is an entirely separate problem.

I’ve already done pretty much everything there is to do the LinuxMusicians configuration consultation page and my setup actually passes their evaluation script. I should be golden, but I’m not. Help?

ETA3 (0:26 19 August): Every two minutes, right now, with the system mostly idle, I’m getting a burst of XRUNs. On an idle machine. But it is exactly every two minutes. And while Ardour remains on top of Top even when idle (at 10% of CPU and 13.5% of RAM), Xorg pops up just underneath it, and its CPU use spikes.

What does Xorg do every two minutes? Anybody? Seriously I have no idea.

ETA4 (13:19 19 August): ARDOUR 3 TRIGGERS SESSION SAVE EVERY TWO MINUTES BY DEFAULT. Disabling that STOPS the two-minute failures entirely. We’re back to file system adventures. Holy hell. THIS HAPPENS EVEN ON RAMDISK so it’s not filesystem or media specific. What the hell is going on here?

kitting out cheap handout

Thank you so much, everyone who stayed for my end-of-comicon panel on building a recording kit on the cheap! I’ll post about the convention in general tomorrow, but as promised, a PDF copy of the handout is right here (click to download).

Also, the series of blog post articles I talked about – which go into considerably more depth than I could in the presentation – can all be found here. That link takes you to a master post which collects all the articles into one convenient place. It’s also linked to from the blog itself, in the left column, below the RSS feed and podcast links, so bookmark that if you like for later reference.

More tomorrow – for now, time to unpack!

the studio buildout series

These are links to the complete studio buildout series, as well as some others highlights from our DIY category of posts. It’s by no means exhaustive – we post about DIY on a fairly regular basis – but these tend to be the topics asked about most often. Enjoy!

We also have posts on making other things, like instruments, pickups, and sound-effects boxes:

And there are the other DIY collections, too:

flower or space probe

I’ve always liked these little flowers. They look so fake, like they’re made of some sort of particularly sun-resistant plastic. I’M NOT SAYING IT WAS ALIENS BUT


…it was aliens.

Remember a couple of months ago the hell of upgrading Ubuntu so I could run a modern version of Jack, so I could run Ardour 2.6.14? Well, that was the latest version six months ago, the first time I tried to upgrade.

About five months ago, the long-awaited Ardour 3.0 finally came out. (They’re at 3.1.mutter now; and having the history with Microsoft, this sounds like a sweetspot for versions.) So now I’m fiddling around with that.

I’ve only been working with it for a few hours so far, but I’ve done a little test recording and editing, and tried to put it through some early paces. It works with the version of Jack included with Ubuntu 12.04 LTS; no Jack update needed. It still allows parallel installations, so you can use it without losing 2.6. There’s an installation script, but honestly, you don’t need it; you can run it straight out of its bin directory, which is what I’m doing.

First impressions are really good. Latency is lower. I’ve had a little list of features I’ve wished Ardour had, and suddenly it has them. There are a lot of UI changes, most of which I like, some of which I love, a couple of which… I’m not as happy about, but nothing I can’t get used to. It has updated project formats; I’m figuring out how much that matters, it seems to maintain double root files now, one for Ardour 2.x use, one for Ardour 3.x use, but I haven’t tested that.

I love love love the new project view window.

It’s a lot smarter about use of screen space; I can fit all the tracks of, say, Voiceless usably into the editing window now, and even have a bit of room to spare. “Maximise editor space” is now actually worth using; it’s much smarter about use of screen real estate. Plug-in management in tracks is much better – that was one of those things I’ve been wanting. Click track now lets you set files for both emphasis note and basic notes, and it has an exposed level control. (You could do that before; it was just difficult.)

One way in the past to crash Ardour has been to get freaky with editor zoom controls while the transport is running on a complex project; 2.6.8 would crash pretty easily that way; I’ve only seen 2.6.14 do it once. 3.1 hasn’t yet, despite trying – but the night is still young.

Anyway, those are all just some first impressions. I’ve already made a scratch project for the soundtrack album in 3.1; if things continue to go well, I’ll do the whole album in it, and post new impressions as I have them.

a small case of srmd

We haven’t done a proper postmortum on the Leannan Sidhe album project yet, partly because of time, and partly because it’s not through mastering. We’re pretty much done, though; principal recording is over, and Alec has done all or nearly all the mixing; I just ran a set of 50 pre-mastered discs for Shanti this weekend, to take to Arkansas for a festival.

Despite that, I have made a few notes and workflow changes. For one thing, I’ve always known regions – which are windows onto recorded tracks, like snippets of tape, but adjustable – had names, could be renamed, and those names were somehow inherited. But it’s only now I’ve actually started using that, naming them by take numbers and such. It’s made compiling composite takes much less confusing.


But hang on, this is a DIY post, promise

But we did have one problem that cost us seven or eight takes during the process.

We do all the recording in isolation headphones. The performer hears the playback in them, as well as what they’re doing, and none of that gets into the mics. Every so often we stop and listen to what we’ve done on the studio playback speakers. (The “monitors.”) Then we’ll go back to recording.

And all this works great… unless, of course, you forget to turn the monitors off, which we did. Several times. In isolation headphones, we can’t hear the speakers, so we don’t necessarily catch it.

Meanwhile, speaker selection has been a little weird – the amp has “A” and “B” buttons, and “B” went to a three-way box, because I had four total speaker sets. And there aren’t any indicator lights.

Or, rather, there weren’t any indicator lights.

My first idea was “can I make something that’ll flash when there’s speaker activity?” I wasn’t planning on changing the speaker setup or any of that; I just wanted to piggyback onto what I already had. I came up with a simple solution – literally just a resistor and a diode, pulling off 0.8% of the output circuit to cause lights to flicker at loud volumes. It’s not everything I’d like but it’s as close as I’m getting at the moment.

Separately, I’d decided I didn’t like the “amplifier on” light I’d jury-rigged up before, with those little green rectangle nightlights on an extension cord, and figured I could put both of those into one box with like four cords running to it. Seemed a bit excessive, but worth doing anyway.

So I went looking for an experimenter’s box to hold all that. I wasn’t really finding a good-sized one, when I stumbled across an old Radio Shack audio-video selector box.

I found a picture of the same model, elsewhere online:


Switches audio left, audio right, and composite video

The left side of the box is just blank space. The box is that wide only so there’s enough room on back for all the plugs. While I couldn’t find a “before” picture of the insides online to show you, there’s just not a whole lot inside, either; it’s four switches on a single circuit board.

And that’s when I decided I could change the speaker setup so all four speakers went through one box. No more A/B and external switcher: one box. And that box could have a couple of indicator lights on it for signal. Perfect!

Except this is one of those projects that turned into kind of a science-related mimetic disorder episode. I had an idea, I came up with a circuit, I figured out I could make a way simpler version… then I fiddled with that and improved it again… then I realised I could add another bit of functionality over here… then I realised I could add another piece of functionality… until I ran out of parts. Then I got more parts and realised I could add something else… and I didn’t take any pictures for quite a while. But I have a couple.

In this photo, I’ve already done some work; those resistor pairs are replacements for lower-watt resistors of the same value. I didn’t really need to do that; they’re just buffers to prevent capacitance buildup in disconnected pins, and are out of the signal path.

It’s right about here that I really realised this wasn’t an audio switch, it was an audio-video switch. And I wasn’t using the video. And if I could isolate the video portion of the box… I could run a few volts of power indicator on those connections.

Which can also mean lines for speaker select indicators, because these switches are switching both audio and video circuits….

And that’s how these cascades get started. Follow along, eh?

Now, before you try to do this, it’s really, really important that you know you’ve isolated all parts of the video circuit from everything else. Including the ground line. Even if you’re only running three volts of DC on it, the speaker signal is AC, and speaker circuitry does not like DC. You can and will damage your speakers. I had to scrape away part of the circuit board to isolate the ground half of the video circuit; you probably will too!

Now by the time I’d started taking pictures, I’d already done a fair bit of work. Here’s the faceplate, with holes drilled for power, left signal, right signal, and speaker selection lights:

I thought I was done here, but that was a lie; I was just out of parts.

Here’s the faceplate, back on the board, with most of the LED lamps mounted. (See again: out of parts.) Here, I’ve also isolated the video circuit from all the others, while still leaving it connected to the switches. That resistor on the lower right is attached to what had been the video ground, and it’s the buffer resistor for the LED power circuit:

Now, with my multimetre, I’d figured out that the lower two posts on the left side (as seen in these photos) were the posts for completing the video circuit on each switch. Now they’re power switches, so let’s start connecting them to the LEDs!

Now here, I’ve built a return rail. Each switch is connected to an LED input, then all the LED outputs are connected together on that rail, and the rail connects back to the ballast resistor. If you’ve seen this circuit before done in isolated wires like this before, well, welcome to vacuum tube amplifier construction, circa 1956.

You might notice that we don’t have the power light attached, yet – because, again, out of parts.

Next up was to put in my tiny signal detectors. It’s nothing more than a high-value resistor and an LED. Remember: LEDs are diodes. You don’t need two separate parts (diode and lamp) if you have enough ballast to let the LED itself do the diode job:

The ballast resistor and LED are connected in series, picking off the signal line from the inputs, and going back to the grounds. I wired left and right grounds in parallel here… really just for symmetry’s sake. They’re the same ground. But as long as the signal side of the diode is isolated, you won’t get any signal intermix.

Note that I’m picking up the audio signal from the switches, like with the DC power. This is just for ease of access – there wasn’t a good place to pick up the signal anywhere else. Those were the input pins for each channel, so always on.

Now, overnight, that LED pickup bothered me. I couldn’t complete the box without the extra parts – this is when I was tweeting WHY ISN’T THERE A 24-HOUR RADIO SHACK IN THIS TOWN? SCIENCE DOES NOT CARE ABOUT YOUR NEED FOR SLEEP! – so the design was still foreground in my brain. And while it isn’t a big signal hit, every time that LED lights up, I’m picking off a little bit of output signal.

So I decided that I needed to add a “defeat” switch, to be able to have those LEDs out of the loop for ordinary listening.

I did that by taking the two returns from the signal-detect LEDs – the leads heading towards ground – and running them through an on/off switch. Easy-peasy. The most difficult part was a switch that would fit – I wanted to use a rocker switch I have several of, but it simply wouldn’t physically fit on the faceplate. Instead, I went with a push on/push off.

As soon as that ground is lifted, the circuit is isolated, and we’re all done.

To be honest, I don’t really hear any difference one way or the other, but I still feel better about having included it. ^_^

And, separately, I ran leads for the power indicator light. The way I wired it, it dims when a speaker is enabled. That was an accident, but I like it.

Finally – this piece of Radio Shack kit was built for line level signals, not speaker level signals, and I wanted more metal on the rails for the thicker signal. I’ve already been using a piece of kit a lot like this, but it bothered me more here. I ran that on the opposite side instead:

I was a little nervous about having the parallel rails – a tiny one on the top of the circuit board, a proper one underneath – but I did the time math and the difference is going to be inaudible to anyone. We’re talking less than microseconds.

So here’s what it all looks like before being put back in the case, with no power:

And here it is all connected up. One video connector is used for +3V input. The other video connects are filled with hot glue, to make sure nothing ever accidentally gets plugged in there. The left amber light is amp-has-power. The two red LEDs (which are brighter and less red in this photo than in real life) indicate strong speaker signal. The green LEDs indicate which speaker is selected. It is possible to have none selected, which is nice:

So. The old speaker-selector box is pulled; this replaces it. The old blue-rectangle amp-is-on power indicator is gone; this replaces that, too. The “A” and “B” switches on the amp can mostly be ignored. There are now lights to indicate which speakers are on, and there are loud-signal lamps which flicker as an additional layer of warning.

Hopefully, now, we’ll finally not have to worry quite so much about accidentally leaving the monitors on.

 


This post is part of The DIY Studio Buildout Series, on building out a home recording studio.

ddrescue to the rescue

ddrescue has completed! I’m about to let this image to a new drive to recover the non-system files which were unreadable. But I do want to compare-and-contrast something. Here’s ddrescue’s completion output. Note in this list:

  • 5.49 gigs of errors (recovered, tho’ it took four days of processing
  • 21261 read errors.

About to copy 320072 MBytes from /dev/sdb to /home/kahvi/Archives/clearbrook-image.img
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 128 sectors
Sector size: 512  bytes
Max retries: 0
Direct: yes    Sparse: no    Split: yes    Truncate: no

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:   314584 MB,  errsize:   5488 MB,  errors:   21261
Current status
rescued:   314584 MB,  errsize:   5488 MB,  current rate:        0 B/s
   ipos:         0 B,   errors:   21261,    average rate:        0 B/s
   opos:         0 B,     time from last successful read:       0 s
Finished


Yikes! Clearly the drive is on its last legs! What does Hitachi’s SMART firmware think?

smartctl 5.41 2011-06-09 r3365 [i686-linux-3.2.0-39-generic-pae] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

oh.

THANKS GYES.

a cheap microphone

A heads up: today’s Tech Woot looks to be a quality microphone for the price. I didn’t even know Blue – who are a quality maker – made a USB microphone, or, for that matter, much in this price range. (I think they had a cheap ribbon mic at some point? But mostly their ribbons are pretty high end. And this is a large-can condenser, anyway.)

I wouldn’t want to move it around a lot – it’ll be too fragile to take out – but anyone wanting to muck around with home recording for as little cost as possible, just wanting to learn the concepts? You could do a lot worse. Particularly given that it’s a USB mic, and you won’t need to buy an external interface.

Here’s the URL: http://tech.woot.com/offers/yeti-usb-microphone-12

And, for the record, I have no connection or financial interest in either Woot or Blue, other than losing in a bidding war for a Blue Woodpecker ribbon mic once on eBay. XD

(h/t Stickmaker for the callout.)

Return top

The Music

THE NEW SINGLE