Categories
Tech Explorations

Fast Track C600: Faults and Fixes

A few years ago, one of my high school music teachers came to me with a deal that was too difficult to pass up. He had just replaced his audio interface, and he wanted to get rid of the old one, which was of course faulty. Having known each other for a while, he knew that I was into that sort of thing and had decent chance of making it work. The device in question was a M-Audio Fast Track C600, a fantastic USB audio interface featuring 4 mic or line inputs with gain control, 6 balanced audio outputs, 96kHz 24bit crystal clear audio, low latency, and S/PDIF and MIDI I/O, along with many other tidbits and little details that make it a joy to use. It was way out of my price range, there was no way I could afford such a high-end device, and yet it was now mine. That was, of course, provided I could make it work in the first place. Today, we’ll delve into the adventure that was fixing it. Unfortunately, I didn’t take any pictures of the process, so you’ll have to take my word for this.

When I got home, I decided to plug it in and give it a shot, not expecting much. Instead of the usual greeting of flashing lights I was met with darkness. It was completely dead. My computer didn’t detect anything either, so clearly there was a hardware issue lurking inside. After opening it up, I was greeted with a myriad of cables routing lines back and forth from the two printed circuit boards that were inside, which looked pristine. No charring, no blown capacitors, no components rattling inside the case. the C600, or as the PCB ominously shouted at me (what I can only assume was the internal project name) in all caps, GOLDFINGER, looked as neat and tidy as the day it left the factory. A bummer it seemed. It wasn’t going to be an easy fix.

A breakthrough

And so it sat on my desk, half disassembled, for months. For one, I was still learning the basics of electronics, so there wasn’t much for me to do at that point. On the other hand, I was just getting into the world of digital sound, and my little Berhinger Xenyx 302USB was more than enough for what I was playing with back then.

Then one day, I decided to remove the lower board entirely (this is the one that holds all the important electronics, the upper one just has the display elements, knobs and buttons, along with the preamps for the inputs, which weren’t really necessary at this point), plugged the AC adapter (which I didn’t have, but an old 5V wall wart coming from an old Iomega Zip drive matched the jack and voltage perfectly) and the USB port, and started looking around the board.

At first, nothing really seemed to stand out, until after a while, when a smell of flux and solder caught my nose. For those who have never worked on electronics before, it’s a very pungent and characteristic smell, usually indicating a component that is way too hot. I started feeling around with my finger until I found the culprit; a tiny 10-lead MSOP package only slightly bigger than a grain of rice. I didn’t know what it was at first, but it had some big capacitors around, so I assumed it was some sort of voltage regulator, but the writing was tiny, and I couldn’t read the markings on the chip. After much squinting, I came to the conclusion that the markings read “LTABA”, which didn’t sound like a part name to me. A preliminary Google search came inconclusive, as expected, even after adding keywords and switching things around.

But then it dawned on me. a few weeks ago while hunting components on AliExpress, I noticed that most sellers usually wrote the complete markings of the chip on the listing, unlike other vendors like Mouser who just stick to the official part name. so I searched our magic word and lo and behold, there was my answer. Our mystery chip was, as expected, a regulator, the LTC3407 600mA dual synchronous switching voltage regulator from Analog Devices. The mystery was not complete however, as the regulator was of the adjustable type, and as such, I had absolutely no idea what voltages I was looking for.

But Goldfinger had me covered. etched on the silkscreen just a few mm away from the regulator, I saw three test pads, labeled “5V, 3V3, 1V8”. I assumed that the 5V was coming from either the USB socket or the AC adapter, while the 3.3V and 1.8V (voltages very common for powering digital microelectronics) were being handled by the dual-output regulator, stepped down from the 5V rail. After a quick continuity check, my assumptions were confirmed. The pieces were starting to come together.

A (not so) temporary fix

For a regulator to get that hot, usually one of two things need to happen. Either a short circuit on the output rail, or an internal fault that requires replacing of the chip. I discarded the short theory fairly quickly just by measuring the voltages. When a short occurs, the regulator usually switches off the output automatically and gives us a voltage very close or at 0V. In our case the output voltages were jumping around erratically, nowhere near the stated voltage on the board. While this was a relief in the sense that there was no problem with the board, it now posed an ever tougher question; what was causing this issue?

For a while I poured over the datasheet looking for an answer. At first I thought it was a problem in the feedback circuitry (the design of this circuit is what sets the output voltage and allows it to correct it as the load changes), but that would only affect one of the regulator subsystems, as each leg had a different feedback circuit. I also thought that the external components of the regulator (capacitors and inductors mostly) were faulty, but again, this didn’t explain why both rails were bust.

So I decided to quit. I’m not an electrical engineer (yet) and without a proper schematic of the board there was no way I could troubleshoot this PCB with my available tools in my house’s washing room. So I ripped the regulator out (It was slightly brutal, as this package has a massive solder pad beneath the package to dissipate heat, that is pretty much impossible to desolder amicably without a hot air rework station, which I don’t have) and went to my local electronics store and bought a 10-pack of LM317 linear adjustable voltage regulators. This million-year-old component, being a linear regulator, although trivially simple to install, has a massive disadvantage; unlike the original regulator which relied on switching the input voltage on and off really quickly, this one lowers the voltage by straight up dissipating the excess power as heat, which in turn means a greater power consumption. This meant both hoping that the USB port didn’t trip its overcurrent protection and adding heat sinks (salvaged from an old TV) inside the case with duct tape and wishing for the best. At least in my mind, this was all temporary. after soldering wires into the board, adding the passives for setting the voltage, and admiring my horrendous creation, we were ready for a test run.

First light, second problem

As I plugged it in, I saw das blinkenlights flashing at me for the first time. I was overjoyed when my computer recognized a new USB device. It was alive at last, but the battle was only halfway through.

For one, it turns out that Goldfinger doesn’t look kindly to USB hubs or USB 3.0 plugs. Both official and unofficial documentation warns the user to get away from both these apparent evils and stick to strictly USB 2.0. Luckily, my workhorse laptop does still include a USB 2.0 port which has given me no issues so far.

I had installed the “latest” (version 1.17, dated mid-2014) drivers available officially from the manufacturer’s website, which gave me issues since the beginning. Unstable on Windows Sound API, clicks and cutouts on ASIO, bluescreens if unplugged, bluescreens for no reason at all, poor hardware detection, you name it. After gouging through what’s left of the M-Audio forums, I found a post with the suggestion of rolling back to a previous version of the driver, which unfortunately went unanswered. So I gave it a try, downloading the 1.15 version (also available from the drivers site) and installing the old version. And at last, it worked.

A quick review, finally

So I’ve been using this interface for about a year now, give or take, and it has been a dream to work with. I’ve used it to record both live gigs and snippets and experiments of my own creation, and even used it a few times for livestreaming.

For me, it’s a perfectly adequate device for the kind of work I do, especially for free ninety nine. The user experience could use a tweak or two, especially the squishy knobs and the weirdly sensitive gain pots, but the build quality is solid, the connectors are a joy to use, and the included software is finicky, but powerful if you’re willing to respect it’s quirks.

Closing thoughts

While this turned out to be a massive project, both in time and scope, many important things were learned. First and foremost, never turn down free stuff, even if it’s broken. Turns out most people throw out things even if the fix is simple. Also, repairing things is good for the environment and usually cheaper than buying new. Second, just because the device you’re trying to fix uses some high-speed component doesn’t mean a 50-year-old component won’t replace it.

Categories
Tech Explorations

RTMP systems for multistreaming

Given the current events, livestreaming has become an enticing alternative for giving some continuity to many activities that otherwise would not be possible during these difficult times. However, creating a professional quality setup for broadcasting live events is quite a challenge, especially because until just about a decade ago, the idea of creating a live TV studio in your bedroom was ludicrous to say the least. If you’re working with large groups of people, consider it a powerful tool to reach out to your audience.

This post is going to narrate the hoops I went through in the process of creating such broadcasts with professional quality and a relatively friendly budget in mind, as well as explaining a bit how livestreaming works, and how everything ties together for creating both creative and functional livestreams.

I: The gist of it all

Pretty much every social network worth its salt has some sort of livestreaming capability built in, ranging from the gimmicky to studio quality. For the purposes of this article, we’re going to be focusing on three: Facebook, Instagram, and YouTube, as they’re the ones I usually broadcast in.

  • YouTube is pretty much a pioneer on the subject, introducing one of the first livestreaming services available for everyone to use, and has pretty much everything nailed down at this point, providing a stable and reliable platform for pretty much every scenario.
  • Facebook also has a pretty solid platform for livestreaming, and it’s a personal favorite of mine because it will process and transmit pretty much everything you throw at it.
  • Instagram is the most frustrating one to work with, as it does not officially support broadcasting outside of its mobile app, and as such provides plenty of head scratching and hair pulling during the setup process.

Regardless of platform, pretty much every livestreaming service out there works using the Real-Time Messaging Protocol (RTMP), originally developed by Macromedia and now maintained by Adobe. The standard is (mostly) open and it works great, so it’s to be expected that everyone is using it. However, it does not specify a video standard per se, so you can send pretty much anything you want (this will be a problem later). RTMP works by using a streaming server address and a streaming key to connect and begin the transmission, which are different for each platform and are provided by them when you begin a livestream. Depending on the site, the stream key changes for each stream or after a set time, be mindful to keep them up to date.

For any livestream, there are four basic links in the chain that make it work. The chain is only as strong as its weakest link, so all of them must be reasonably balanced to get good results; these are Capture Hardware, Video Processing, Restreaming and Internet Connection.

II: Capture hardware

This is the first link of our broadcast chain, and involves everything needed to capture video and audio data that will go in your livestream. Integrated webcams are the default (and sometimes only) option for many people, but I decided against them mainly because of their poor quality; low framerates, issues with exposure, noisy output, etc. Modern external cameras like the ones offered by Logitech are a good alternative -ignoring the cheaper ones which often suffer from the same issues- you can easily get 1080p at 60fps with them, but since I don’t own one, I went with my preferred method, a video camera and a capture card.

For this method you can use whatever camera as long as it has a clean video output (avoid the ones that show all the controls and menus through the video output) and whatever capture card capable of processing the desired resolution. In my case I used a Panasonic HDC-TM700 portable video camcorder and an Elgato Game Capture HD USB capture card (a beaten old warhorse, and a story for another time.). Both are over five years old at this point, but I can still get a clean and reliable 1080p/30fps video into my broadcasting software with no issues. Both companies offer newer products that can be used instead, and as long as you have a compatible setup, you’ll be fine with whatever you can find.

For audio capture, you can use the audio straight from the camera’s microphone or, as I did, use an external audio interface to plug in dedicated microphones. I used a M-Audio Fast Track C600 audio interface (which I actually got for free, I’ll write about that adventure at some point) which works great, but requires a bit of a workaround, as probably most multichannel audio interfaces will. This gave me a clean sound and four mic channels for plugging whatever I want.

III: Video processing

Now that we have all the AV equipment set up its time to set up the software. I use good old OBS for it, because it’s light on system resources (a must for me running it on a laptop) and pretty much endlessly customizable. This is not a tutorial on how to use OBS, -and there are many of them out there who could explain it way better than I ever could- but it’s basically a video editor but live. you can have different scenes and switch between them, mix different audio sources, capture windows or screens, add text and graphics, and much much more. For me, I also had to install the Elgato Game Capture app which includes the drivers for my capture card, which work right out of the box with OBS as a video source. I also installed the OBS ASIO plugin to connect to my audio interface, as it provides low-latency and stable performance (drivers for de C600 are a bit janky, and ASIO gave me the least glitches.). For multichannel interfaces this is a must, because while OBS supports 2+ channel audio, it will not give independent control of each channel without it. I also added a window capture, which worked perfectly too (although beware if you have switchable graphics when capturing screens/windows, they are known to be a pain to set up).

Before we move on, we need to talk about video resolution aspect ratio. Because RTMP does not specify said parameters, each platform works in its own way, and has its own set of rules. Facebook is the most forgiving of all, allowing pretty much any resolution at whatever aspect ratio, vertical or horizontal. YouTube on the other hand, will only work with horizontal 16:9 video, and will complain about any resolution other than 1920×1080 (although it will still work), filling the screen by scaling up the video stream if it doesn’t match with the widescreen aspect ratio. Instagram will do the same, only this time it exclusively supports vertical video, and will scale up the video if you give it anything other than 9:16 video, losing everything but a sliver of video. For my setup, horizontal video made the most sense, so we were careful to frame the most important parts on that small sliver, but we still lost some important parts of the video. It might be possible to reprocess the video to remediate some of these issues, but not having the entire frame on Instagram was a reasonable compromise for me.

IV: Restreaming

As the title implies, we want to do multistreaming -also known as simulcasting- which means to transmit to multiple platforms at the same time, a task which OBS does not handle natively (you can run multiple instances of OBS with the -multi argument, but video capture devices and webcams will not allow you to use more than one stream at a time). A few comercial alternatives are available to solve this issue, such as Restream.io which is free for some platforms (but not for Instagram, which was a dealbreaker for me) and a limited number of streams. This left me with the predicament of having to set up my own restreaming server.

For this task I used NGINX, a ubiquitous, open source web server software which is -depending on who you ask- the most used web server on the Internet. Fortunately for me, someone had already made an RTMP module for NGINX which worked perfectly (all credit goes to this amazing post on the OBS forums detailing how to make it work). I ran the server on a Raspberry Pi 3B+ which was more than enough to make it work (the restreaming server doesn’t do any sort of processing, it just forwards the incoming stream to the desired servers). In theory you could run it on the same machine used for video processing, but I found NGINX for Windows to be very confusing and difficult to install, whereas the Linux (Raspbian Lite) install and configuration was very simple and straightforward.

Remember when I said that every streaming server used the same protocol? Well, that’s not entirely correct. While it’s true that all three platforms use RTMP for moving the stream around, only YouTube uses the standard protocol on port 1935 (the default port for RTMP), while Facebook and Instagram use RTMPS, which is just the standard RTMP protocol over an SSL tunnel on port 443. This complicated matters a bit because the RTMP NGINX module does not support RTMPS natively, so we now need to encapsulate the Instagram and Facebook video feeds on a secure tunnel.

This is where STunnel comes in. STunnel works as an SSL/TLS proxy, grabbing whatever data we throw at it and encrypting it before sending it back on its way to the target servers. This page helped me get it up and running with NGINX. Now that all the protocols are in order we can actually attempt a connection with the servers.

V: Internet connection

Now that everything is set up on our side, we need to connect to the streaming platforms. Before that though, make sure you have a stable internet connection (Ethernet is your best choice here, Wi-Fi can be very unstable and low speed in certain scenarios), and that your upload speed is greater than the OBS transmit bitrate (2500 kb/s by default) times the amount of streams you are going to simultaneously stream to.

For exact instructions, follow the tutorials listed above or check de OBS forums for help. For Facebook and YouTube is just a matter of copying and pasting the stream keys from their respective streaming menus and you’re on your way, but once again Instagram is going to put up a fight. For one, as we said earlier, Instagram does not officially support RTMP streaming, so we need to use software like YellowDuck that will trick Instagram into believing that it is receiving an RTMP transmission from a phone, the actual supported and official way of doing it. A quick note on any software or website designed to to this: logging in is very finicky. Test the stream beforehand with the actual account you want to use, to avoid screw-ups when the real time comes.

VI: Closing thoughts

After reading all of this, you might feel livestreaming to be a near impossible task but remember, most of the setup required has to be done only once, weeks in advance. after that is just a matter of keeping the stream keys up to date and making sure everything is working.

In dire times like this, streaming often brings a sense of community that not many other technologies can provide. It allows us to see a face, to feel like we’re part of something bigger. If you are in charge of anything that deals with people, please try to introduce it as a new way of reaching out to people, even after all of this is over. Good luck and happy streaming!

Categories
Tech Explorations

An Introduction

Hi! My name is Benjamin, and I’m an engineering student and overall tinkerer, maker, and explorer from Chile. This blog is going to be a place for me to present to everyone my projects, workarounds, and other interesting tidbits of my journey of making things work.

It’s probably not going to get updated very much, I don’t get to do projects worthy of a write-up very often as I’m still pretty much on the meat grinder at university, so free time is scarce. I may also write about other subjects of my interest, as long as they are at least tangentially related to the topic of the blog.

I’m also very open to chat, so drop me a line at my contact page if you want to get in touch and/or ask questions about my projects. Expect the occasional typo and odd sentence, as english is not my first language, although I’m somewhat fluent.

Cheers!