A new version of Drum8 supporting 8 simultaneous sounds and multi-channel audio output has been released.
The other evening I cranked my somewhat old HT system to test out a new USB optical audio interface. Next day I noticed a lack of treble in the left speaker. Hmmmm.
The main speakers are Yamaha NS200s, over 15 years old. At first I thought I’d blown the tweeter but continuity was OK and swapping with the right speaker’s was conclusive. Pulling the woofer from the bad speaker, I discovered a capacitor in the crossover had blown its end off. I cut it free.
Its a 160VAC 2.7uF paper capacitor. Without getting all fancy, I figured a 250V 2.7uF metal film polypropolene should be a suitable replacement. At my age I’m hardly a golden ear and modern polys seem to have a good reputation in crossovers.
I didn’t want to take the crossover out, its glued and stapled in place and mechanical things give me the shits. So I left a lot of the original leads in place and used barrier screw terminal blocks to attach the replacement cap, which is smaller and has radial instead of axial leads. Glued everything down (including the terminal block screws), with two screws per connection I figure it will be adequate given the speaker isn’t doing the deep bass anyway.
This shows the front of the HT setup, the room is huge so the 40″ TV (6 year old LA40B650) looks comically small but we usually watch TV from beanbags so its adequate.
The TOSLink SPDIF interface is a Turtle Beach Audio Advantage Micro II.
Its working extremely well feeding 5.1 audio to my Yamaha RX-V595 amplifier. The amp only supports standard AC3 and DTS, none of this modern 24bit 96kHz stuff. When that becomes a problem I’ll set up an external decoder or get a new amp, instead of downconverting it in the HTPC.
One note with the Audio Advantage – you need to install the driver from Turtle Beach’s website as the default that Windows 10 installs doesn’t offer the digital out. You can force Win10 to use the TB driver and that creates a separate digital out sound device. With that selected for my media player, all I had to do was enable SPDIF passthrough in my audio decoder (LAV Audio Decoder) and my amplifier’s display and AC3/DTS test files absolutely confirm that each speaker is being individually driven.
[EDIT:January 2018 Drum8 now supports 8 voices and stereo!]
Finally finished some software I started nearly 30 years ago, and I don’t mean Planimate!. Drum8 is a drum machine written in assembly language for Apple IIs with a DAC board.
When I bought an Apple //e in the mid 80s (replacing a very hacked Apple ][+) it came with a small card with a speaker on it called “SAM – Software Automatic Mouth” which allowed the Apple to talk.
The SAM card was an 8 bit DAC, implemented with a latch, DAC chip and amplifier for the speaker. I’d connected it to my sound system and discovered I could get pretty good crunchy 8 bit sound playback (less noisy than the Mac+ I also had at the time, no dither noise).
Around the time I’d written a drum sequencer that triggered a real 70’s era analogue drum box through the 4 game port annunciator outputs. One of the Mac music programs had some drum samples and I tried playing them using the SAM card. It worked great and in 1987/88 I ended up writing a 16 channel / 4 simultaneous voice mouse driven drum machine for the Apple II+ and //e.
Unfortunately the SAM card got left behind in a move and its a rarity on eBay. Recently after researching a few DACs and even an R-2R ladder option, I found an interesting chip that had promise, the AD558. This is pretty much a one chip solution. Internally calibrated, running on a single 5V supply, direct CPU bus compatibility and with a buffered output, it can be configured for a 0 to 2.8V output, perfect for a line level audio out.
From the AD558 datasheet and Apple II reference manual, I came up with this circuit:
The only additional passive components are:
- 0.1uF power decoupling capacitor – unpolarised greencap, 25V rating would have been enough, the one I had was double that.
- 6.8uF electrolytic capacitor. This blocks the DC offset in the 0-2.8V output, giving a ±1.4V output, which should be plenty as its going into my mixer.
- 20kΩ resistor, this is there to let current charge the blocking capacitor if the output isn’t connected (avoiding a transient on connection), I’d originally thought 10kΩ but settled on it after finding it first, its value is not critical.
I used an Apple II prototyping board which are still available here, an Apple II slot card which includes solder pads yet breaks out all the port pins to a wire wrap header. I initially planned to wire wrap it all, but I hadn’t ordered a wire wrap socket (and the pins might not have easily fit through the plated-through holes anyway), so I used one of the spare 20 pin sockets I’d recently bought to fix my mouse card, carefully ignoring the extra holes as the AD558 has 16 pins!
With the 8 data inputs on the AD558 arranged neatly in a sequence that corresponds to the data bus on the Apple slot connector, I directly soldered them to the connector using stripped wirewrap wire which, being silver plated, is a breeze to solder. For me it involved a lot of bright lights, looking through a number of magnifying glasses and some patient assistance from my wife, Oak.
Keeping the solder from running up the length of the slot connector was not easy, I eventually discovered that gravity can be your friend. For each of the 8 data bus wires I attached the slot end first then stretched the fine wire to its pin on the socket, (which I’d soldered in first) so it was just a case of heating a pin up so its corresponding wire could be slipped next to it, then the remaining wire cut off.
I took these photos as part of inspection, you can see the 8 fiddly data wires at the bottom right. Ignore the solder along the top edge of the board, its just strain reliefs for the line out cable.
On the row opposite the data pins on the AD558 (pins 9-16), a few adjacent pins need to be bridged. I ran a wire across them, trying to avoid touching the board itself as all the slot pin have traces criss-crossing to the wire wrap header (on the right on the photo below). If the thin insulation on the board was breached by solder, things would get unpleasant. I took particular care to keep away from the 12V line (pin 50 on the slot connector) as really bad things happen if that gets into TTL chips. I know from childhood experience.
Looks real classy doesn’t it.
The proto board’s half solder/half wire wrap design is really not ideal for building much on the board itself. I think it was intended to have a daughter board (eg: Arduino) hang off it. I would have preferred either bigger holes just for wirewrapping or a board without the wirewrap header and associated traces across most of its area, other proto boards have little pads for soldering to at the slot connector.
I did use wire wrap and the wire wrap header to connect to the device select, read/write and power lines. I’d bought the tool and wire after all, and wanted to stay away from the slot connector after my experience with the data lines.
Mounting the capacitors and resistor was uneventful and I ran the audio to the shielded audio cable at the top of the board with little consideration for what its crossing along the way, fully expecting I’d deal with noise later, once I’d tested the board.
With the card in slot 5, writing alternating 1, 0, 2, 0, 4, 0, etc to $C0D0 generated progressively louder clicks. Both the SAM software and my drum machine worked perfectly first time.
The audio output is surprisingly quiet given the unshielded wires and cross-crossing bus on the board. Plus I’m running without any special power supply regulation for the DAC, the AD558 has its own internal reference. What a great chip, glad I bought a few as I’ll have to do something for the Arduino with one or two.
The ASRock ION 330 HTPC had been a faultless performer for nearly three years but in late December, the combination of a hot summer, a warm amplifier underneath it and a flaky case fan caused it to cook itself, leading to it becoming prone to lock up for periods of time. I changed the hard drive, reseated cables and replaced the fan. None of this helped (EDIT: Both 320GB WD drives were faulty), It seemed to have lost the ability to control the case fan properly unless I kept it on maximum fan speed, making it intolerably noisy.
After a few attempts at fixing it I decided to replace it and was pointed to the Shuttle series of totally silent fanless PCs by work colleagues. I bought the Shuttle XS35GS V3 which promised a totally silent home theatre PC experience.
I’ve not been disappointed.
I thought I’d be adventurous and gave OpenElec a try,. This is a very optimised XBMC Linux distribution. I found I had to use a more “generic” build as there wasn’t a build for the V3 hardware. After struggling with networking and messed up graphics for a day, I decided to go back to the flexibility of the software set I’d used previously, that being: TV Scheduler Pro for TV recording, Zoom Player for playback and EventGhost for IR remote control.
I started with XP and it was “ok”, but Zoom Player (now at version 8.5 vs. version 6 on the ION) had moved on to using the excellent LAV Video Decoders that offered GPU accellerated playback of hi-def content, something I’d achieved using MPC Video Decoder.
I really liked the quality of the LAV Decoder (DScaler is now obsolete for me) but I couldn’t get it to work with acceleration. I discovered it needed the use of the EVR Video Renderer under Windows 7, at least.
I decided to skip Windows 7 and bought an upgrade to Windows 8. Installing it went pretty smoothly, I had to “forcibly” install the drivers for the KWorld Dual DTV USB Tuner and the LinkSys Dual Band USB WiFi (the onboard WiFi of the XS35GS is 2.4G only).
Application wise, everything ran well and the much maligned start screen was a non-issue, I’ve set up buttons on my harmony remote to take me straight to Zoom Player’s navigator for either TV Recordings or my media library. Most importantly though, GPU accelerated playback using the LAV Video Decoders and DXVA2 seemed to work.
It wasn’t until more critical viewing that we realised that *every* video played had a tear in the centre when there was horizontal motion. It was as if it was switching frames at precisely the wrong time. This started a big investigation for the cause.
The problem occured when using the EVR Renderer with either LAV Video Decoder (DXVA2 or software decoder) or the FFDShow. decoder. With the Shuttle using a Radeon 7410M, there wasn’t much choice in drivers to try as its a custom mobile chipset. The video driver did not have the usual option for VSync and I tried both RGB and YCbCr pixel formats, and setting the display framerate to match the video (something which fixes typical tearing).
I tried what drivers I could get to load on it and was at my wits end as everything else was great including smooth low CPU DXVA2 playback of 50FPS 1080P.
Then I tried a slightly older Zoom Player EXE (8.50 instead of 8.51) and the problem went away! Yet when I renamed the older EXE to the regular ‘zplayer.exe’ name, the problem came back. What the…
Looking at the Explorer options on the EXE, the cause soon became clear.
Zoom Player had been installed with the Explorer compatibility option “Disable display scaling on high DPI settings” enabled. This option helps older apps run on the new very high resolution displays.
I’m not sure why, but switching this option off caused the tearing to completely disappear. Playback is now smooth and after some colour calibration, I am very satisifed with the results.
Here is the newly installed Shuttle sitting next to my amplifier.
The not so new EEE PC was experiencing intermittently stuttery audio when playing a Flash based radio stream. This was strange as it coped fine with MP3 and WMV streams, even with video. It wasn’t a buffering issue. The audio had very short glitches – the kind of thing that happens when a device driver locks the bus too long (he says, having worked on a Linux audio driver a few years back).
The wireless drivers were up to date and the wireless hardware configured to use CAM mode (a problem that plagued the ION HTPC when I first installed XP on it). Power management settings were set for high performance.
I also determined it was no where near running out of CPU, sitting at only 10% when playing the stream. After updating drivers, firmware and minimising the configuration as much as I could, I started thinking it might be network related.
I set up a regular ping of length 8192 bytes from my workstation to the EEE so I could see what network performance was like. I was only half surprised to find that ping times were all over the place, with some peaks in the 100s of ms. With the audio streaming, the high peaks corresponded with glitches in the audio.
With it happening even when close to the WNDR3700 wireless AP, it wasn’t a signal level problem. It was connecting at 130mbit (N speed) on the 2.4GHz band.
I switched the router to limit 2.4GHz to 54mbit and the audio problem went away. Ping times to the EEE became a solid 4ms.
Looks like its a combination of crappy behaviour for the EEE’s wireless driver in “N” mode and the Flash Player using a very short audio buffer, making it easy to underrun audio playback. Fortunately I can handle the slower 2.4GHz network since I run a separate 5GHz network for the HTPC.
I’ve discovered a unique hack with my Samsung Galaxy Note phone.
It was playing an audio podcast and sitting next to an AM/FM clock radio (in AM mode). I tried tuning the radio around just to see what the phones digital interference sounded like.
To my amazement I found I could tune in the audio playing on the phone, very clearly, in multiple places on the dial. Testing with a radio with a digital tuner, I found 855KHz was a good spot.
It works best if the audio level on the phone is quite low and the screen is off. The AM radio makes a nifty audio power amp. Its not perfect, if the charger is plugged in things get really noisy … and when the phone polls the GSM network it makes the radio buzz, as you’d expect if you’ve ever left a digital phone next to a radio.
I’m guessing the phone uses a switchmode audio power amp which happens to make an effective very short range transmitter.
The ION 330 HTPC I put together at the beginning of the year is going quite well. Here are some follow up items of interest on it.
I had a DVICO IR receiver that had come with one of my previous HTPC’s tuner cards. I found that the open source software EventGhost works quite well with it.
For my remote to be reliable I found it best to run the HID plugin for the DVICO receiver in raw mode, and only used “initial button press” events.
NVIDIA ION driver leak
I was bemused to find a process was using over 50000 handles after only a few days uptime! It ended up being an NVIDIA component used for stereoscopic 3D display, nvSCPAPISvr.exe. This page has a good tear down of the problem. Its probably fixed but I just set the “NVIDIA Stereoscopic 3D Driver Service” to “Manual” start, what a waste running something so specialised on every install.
I initially connected the ION to my tele using VGA and a separate audio cable. I upgraded to a HDMI cable and its worked great for both sound and picture. There is a slight delay in audio starting so short sounds in explorer get missed but this isn’t a problem at all once in ZoomPlayer.
Its over 4 years since I built the HTPC to record and watch DTV and given it was P4 based, an upgrade was well overdue. I bought an ASRock ION 330 to serve as a replacement. As if it knew, within a few days of acquiring the ION, the 300GB WD HDD on the old HTPC started reporting CRC errors.
I decided to go with a low power solution rather than eusing the nice Accent HT400 HTPC case (and its iMon remote control), mainly because power saving is a bit of an issue now. This meant buying a new DTV TV tuner solution. I went with the KWorld Dual DVB USB tuner. It is based on the ITETech AF9015 and even comes with a worthless remote control that looks like a calculator.
I was already forewarned that the application software (tvMe) that come with the KWorld (a version 1.0) was bad, but I had to install it on a test system just to see how unbelievably bad it was. It needed dotNET – this should have been a warning. The software looked like someone’s second programming attempt, you know the program you write after “Hello World”. It was badly broken but did indicate the tuner was working. The software stayed installed only long enough for me to notice that the tray icon it installed had the tool tip “My App”. Hello World indeed.
All I wanted from the KWorld TV stick was a functional BDA driver, and after a few days running under XP32 with WebScheduler 4.0.14 I was convinced it would be a viable DTV device (actually, a pair of them since its dual tuner).
Next it was time to setup the ION. I’d bought 4GB of RAM for it so I thought I’d give Windows 7 x64 a go. Whilst XP would have suited my needs, I thought the EVR rendering in Windows 7 would be useful.
The Atom 330 which powers the ION is not exactly a powerhouse but having the NVidia ION able to accellerate video rendering is what makes the ION 330 a winner for HTPC purposes.
My favorite video player after all these years is still ZoomPlayer so the next step was establishing how well a 32 bit app with all its 32 bit codecs would work under Window 7 x64. It turns out that ZoomPlayer 7 works fabulously, but now time came to get the codecs set up right.
Firstly, MPEG2 TS playback. I’ve yet to top the combination of Haali Media Splitter and DScalar for playback of raw TV recordings (TS files). It gives me silky smooth playback of off the air interlaced TV. Other splitters/decoders work but either have laggy response to fast forward/rewind, horrible seeking delays or bad video quality especially for motion. I dont think DScaler is doing acceleration, but it copes with hi-def MPEG2 at about 30% CPU utilisation.
Next was testing some H264 1080P trailers. FFDshow woeked but was maxing out all 4 “processors” on the Atom 330 (its actually two cores each with hyperthreading). So it was time to choose an accelerated video decoder. Supposedly Win7 provides one but the video decoder from the Media Player Classic Home Cinema (MPC-HC) open source project trumps everything else out there for quality.
Downloading MPC-HC codecs, I was faced with the decision of 32 or 64 bit. Given my application is 32 bit but my operating system is 64, I wasn’t exactly sure what I wanted, but my guess of using the 32 bit codec paid off.
The process involved just the file MPCVideoDecoder.ax, put it somewhere and register it with “regsvr32”. This worked, once I learned the Win7 trick of opening an administrative console with ctrl-shift-enter when you type cmd into the search field.
Back in ZoomPlayer, in the Smart Play video decoder configuartion for “H264”, I had to select advanced editing and manually browse the list of codecs to select it. It comes up as MPCVideoDecoder. I selected the EVR renderer as well.
With this in place ZP plays 1080P H264 with 10% CPU utilisation, amazing.
Its worth noting, I’m looking at XBMC as well, either as the front end to ZP or standalone once video acceleration support becomes mainstream for the Windows version.
I have a couple of old Technics tape decks, both which feature “dbx” compression. Most everyone who has used cassettes would have heard of Dolby, “dbx” was an alternative approach to achieving the same thing; tape noise reduction. Unlike Dolby, it worked across the full audio spectrum.
I recently found a stash of my old 80s tapes whose time for binning was well overdue. Amazingly, they still play very well! I would have thought they’d have faded to oblivion. I found a couple of tracks worth keeping.
Most of the old recordings are dbx encoded and I’ve found a neat way to make them more vibrant.
First I play & capture them with dbx off. This yields a very “flat” sounding recording because the dynamic range was squashed by the dbx encoder during recording.
I give a little low and high boost to the track, then gently denoise it. It still sounds “flat” because its dbx encoded. No amount of EQ can fix that.
Now I dont have a software dbx decoder, but one of my old decks (RS-M235X) has a “dbx disc” mode for decoding dbx encoded records. Those must be a rarity.
So I play the processed track back through the deck’s line in. It dbx decodes the cleaned up audio and I end up with a surprisingly better result than if I’d just played the tape through the decoder and EQ’d it after.