Reading through the datasheet of the ALC892 HD-Audio chip that is used on my Linux HTPC's motherboard there were two things that caught my eye:
First thing is the built in microphone preamp. It amplifies up to 30dB and I have successfully used it with my measurement mic. It's by no means high end but I remember being surprised at how usable it actually was. HD-Audio codecs seem to have improved a lot over the years and the ALC892 is not even realtek's best.
Then there was the input impedance, specified as 40K. That's not too far off from the 47K that a phono MM cartridge needs...
So could it be that I can just plug my turntable in to the line-in jack of my PC and do all the required signal processing in software?
I got a 3.5mm TRS to stereo cinch adaptor and connected it to a short cable. The combination measured as 115pf. Not good but OK-ish. The cinch cable was connected to my turntable, the turntable ground was connected to the sleeve of the TRS jack.
I captured a frequency sweep of my elipson test record and used 'dsp' by bmc0 to apply the 96kHz biquads from the linear audio article on digital RIAA.
The result (as visualized in REW) was not as bad as I had expected: It looked quite usable aside from a treble bump that was bound to show up as a result of my cartridge's 600mH inductance, the cable capacitance and the slightly off 40KOhm loading.
So I thought I'd have some fun: As 'dsp' can do a lot more processing than just biquads I started to optimize the systems frequency response, measuring my results with REW. I ended up with a frequency response that is flat within +-0.08dB between 30Hz and 19.5KHz. My hearing stops at 16KHz so I have no need for much accuracy beyond this point. Of course the limiting factor here is the test record but for the sake of this little experiment I'll assume it is accurate.
Some casual listening tests showed that while the amplification in the realtek chip is not noise free, any playing record's surface noise will drown out the audible hiss from the preamplifier. As the amplification is before the RIAA EQ the hiss is only audible in the low frequencies and therefore it's not that annoying. I did not notice any mains hum at all.
My conclusions so far are:
1) Yes, ALC892 based onboard soundcards can be used for digital RIAA (there are better ones, like ALC898, ALC1150 and ALC1220 - these should work at least as well)
2) The frequency response needs some correction, even after the usual de-emphasis
3) Hiss is by far not as big a problem as I suspected.
I'm pleasantly surprised so far. I had expected my results to be in line with how stupid the whole idea actually sounds. I will keep on playing with this setup and will report any interesting discoveries I make along the way (if there are any that is).
The 25Hz-20KHz logarithmic sine sweep recording, no de-emphasis
The 25Hz-20KHz logarithmic sine sweep recording, after de-emphasis and additional EQ
First thing is the built in microphone preamp. It amplifies up to 30dB and I have successfully used it with my measurement mic. It's by no means high end but I remember being surprised at how usable it actually was. HD-Audio codecs seem to have improved a lot over the years and the ALC892 is not even realtek's best.
Then there was the input impedance, specified as 40K. That's not too far off from the 47K that a phono MM cartridge needs...
So could it be that I can just plug my turntable in to the line-in jack of my PC and do all the required signal processing in software?
I got a 3.5mm TRS to stereo cinch adaptor and connected it to a short cable. The combination measured as 115pf. Not good but OK-ish. The cinch cable was connected to my turntable, the turntable ground was connected to the sleeve of the TRS jack.
I captured a frequency sweep of my elipson test record and used 'dsp' by bmc0 to apply the 96kHz biquads from the linear audio article on digital RIAA.
The result (as visualized in REW) was not as bad as I had expected: It looked quite usable aside from a treble bump that was bound to show up as a result of my cartridge's 600mH inductance, the cable capacitance and the slightly off 40KOhm loading.
So I thought I'd have some fun: As 'dsp' can do a lot more processing than just biquads I started to optimize the systems frequency response, measuring my results with REW. I ended up with a frequency response that is flat within +-0.08dB between 30Hz and 19.5KHz. My hearing stops at 16KHz so I have no need for much accuracy beyond this point. Of course the limiting factor here is the test record but for the sake of this little experiment I'll assume it is accurate.
Some casual listening tests showed that while the amplification in the realtek chip is not noise free, any playing record's surface noise will drown out the audible hiss from the preamplifier. As the amplification is before the RIAA EQ the hiss is only audible in the low frequencies and therefore it's not that annoying. I did not notice any mains hum at all.
My conclusions so far are:
1) Yes, ALC892 based onboard soundcards can be used for digital RIAA (there are better ones, like ALC898, ALC1150 and ALC1220 - these should work at least as well)
2) The frequency response needs some correction, even after the usual de-emphasis
3) Hiss is by far not as big a problem as I suspected.
I'm pleasantly surprised so far. I had expected my results to be in line with how stupid the whole idea actually sounds. I will keep on playing with this setup and will report any interesting discoveries I make along the way (if there are any that is).
The 25Hz-20KHz logarithmic sine sweep recording, no de-emphasis
The 25Hz-20KHz logarithmic sine sweep recording, after de-emphasis and additional EQ
Last edited:
The only thing that really surprised me was how well it worked. I had expected to deal with a lot more hum and hiss, especially considering that onboard PC audio solutions have such a bad reputation. Back in the days of AC97 this was well deserved. I had blindly assumed this to still be the case with modern HD-Audio solutions.
Reading the ALC892 data sheet left me sceptical as well. Realtek uses A-weighting in all of their SNR specs and with their ADCs they only guarantee a bandwidth of up to 19200Hz@48KHz sampling rate. To get full 0-20KHz audio you therefore would need to sample at 96KHz. These quirks didn't exactly inspire confidence in this little $1 chip.
Instead I find that this way of record playback sounds really good (after EQ). Before, my NE5532 based preamp sometimes picked up some interference from my LAN cables. With the realtek solution this is not a problem, even though there is not even an inch between the line in jack and the LAN port.
I also find the minimalism of this solution quite appealing. This might be a keeper.
While playing around with my software phono-preamp I noticed that the stereo image was subpar. Earlier I was using the Denon PCC 1000 crosstalk canceller to good effect. I wondered whether I could replicate it's effect entirely in software.
I recorded the Denon PCC setup disc: A 45 RPM 7" with two tracks. Each contain a wobbly 1KHz sine on either left or right and silence on the opposing channel.
As the record had never been cleaned it had some ticks and pops. I cleaned up the recording in Audacity with the declick plugin and band-passed the signal at 1KHz so only the desired signal was left.
Looking at the waveforms it was obvious that the left channel's crosstalk on the right channel was in anti-phase to the left channel's signal. It was the same thing going from right to left.
The left-to-right crosstalk was at -36.2dB, right-to-left was -32.2dB.
In Audacity I created a second track with the stereo recording of the test disc and swapped the channels. Now I could play both tracks at once, reducing volume on the second track until crosstalk was minimized.
The optimal values I arrived at were -36dB level reduction for the L-to-R reduction signal and -33dB for the R-to-L reduction signal.
Crosstalk now measured at 45.6dB L-to-R (previously 36.2dB) and 43.0 R-to-L (previously 32.2dB).
Adding this to the 'dsp' processing chain was a simple one-liner:
remix 0 1 0 1 :2 gain -36 :3 gain -33 remix 0,3 1,2 :
A quick listening test clearly showed the desired effect: The soundstage extends beyond the speakers. Before I found the stage to be confined to the space between speakers, like a really narrow and minimal stereo effect. Now when playing LPs I have the same wide stage as I have with digital sources.
Because inter-channel crosstalk is just another form of distortion, reducing it by more than 9dB per channel yields better sounding individual channels as well.
I recorded the Denon PCC setup disc: A 45 RPM 7" with two tracks. Each contain a wobbly 1KHz sine on either left or right and silence on the opposing channel.
As the record had never been cleaned it had some ticks and pops. I cleaned up the recording in Audacity with the declick plugin and band-passed the signal at 1KHz so only the desired signal was left.
Looking at the waveforms it was obvious that the left channel's crosstalk on the right channel was in anti-phase to the left channel's signal. It was the same thing going from right to left.
The left-to-right crosstalk was at -36.2dB, right-to-left was -32.2dB.
In Audacity I created a second track with the stereo recording of the test disc and swapped the channels. Now I could play both tracks at once, reducing volume on the second track until crosstalk was minimized.
The optimal values I arrived at were -36dB level reduction for the L-to-R reduction signal and -33dB for the R-to-L reduction signal.
Crosstalk now measured at 45.6dB L-to-R (previously 36.2dB) and 43.0 R-to-L (previously 32.2dB).
Adding this to the 'dsp' processing chain was a simple one-liner:
remix 0 1 0 1 :2 gain -36 :3 gain -33 remix 0,3 1,2 :
A quick listening test clearly showed the desired effect: The soundstage extends beyond the speakers. Before I found the stage to be confined to the space between speakers, like a really narrow and minimal stereo effect. Now when playing LPs I have the same wide stage as I have with digital sources.
Because inter-channel crosstalk is just another form of distortion, reducing it by more than 9dB per channel yields better sounding individual channels as well.
In Audacity you'd have to apply the "invert" effect, in 'dsp' it's a matter of setting the "multiply" effect to -1 before mixdown.
I have a few things I could try to get some insight into this. I'll report back.
Thank you phofman! I only recently read your thread on virtual balanced inputs and outputs. Great work and very inspiring!
As the ALC892 I'm using has four ADC channels, I was wondering whether configuring the soundcard in a virtual balanced configuration could help bring down the noise floor a little.
The front panel audio connector seems like it might work nicely. As the Linux HDA driver and this chip allow jack retasking, I think I should be able to reconfigure all four channels on the connector as line inputs. There are also four channels of preamplification available on-chip.
What do you think? Could this be something worth looking in to? As far as I understand, MM cartidges are inherently balanced. The front panel audio header even shows 22K resistors between the inputs and ground. For a stereo input used as balanced this would effectively become 44K. Now that's really getting close to the required 47K loading.
The fact that every one channel would only see half of the cart's inductance might also be beneficial for high frequency extension. I measured my cart at 600mH, practically halving that seems worthwhile.
Using the regular line in and mic in jacks at the back is also a possibility. But here, the 100pf between the input and ground worry me. With each half of the cart loaded with 100pf I'm afraid that I'll lose too much treble response.
Yeah that nasty thing has been showing up in all of my measurements. I have it EQ'd out so it doesn't show in the frequency response graphs, but it's still there. Looks like resonance to me, but I have no idea where it comes from. I'm still using the AT132EP with the ATN152LP from Goldring. Might change that one for the ATN440MLb I have to isolate the problem.
If I switch to using the front panel audio header then all I have to deal with is 22K between the input and ground. In a virtual balanced setup this would add up to 44K but still too far away from 65K. With the front panel header there are no capacitors between signal and ground as these are supposed to be on the breakout board that connects to the header. I could just build my own breakout board and leave out the extra capacitance.
Right now I'm using the line input that is soldered to the back of the motherboard. If it was build according to realtek spec there is 100pf between signal and ground. The ALC892 PDF mentions 64K input impedance. These values are only educated guesses based on the chip specs. Whatever they are I have no way to change these, I can only measure them.
My cable plus TRS adapter is 115pf so that is already more than enough,
Right now I'm using the line input that is soldered to the back of the motherboard. If it was build according to realtek spec there is 100pf between signal and ground. The ALC892 PDF mentions 64K input impedance. These values are only educated guesses based on the chip specs. Whatever they are I have no way to change these, I can only measure them.
My cable plus TRS adapter is 115pf so that is already more than enough,
ariendj: IMO there is no reason the virtual balanced setup should not work, provided you can get to all the four ADC channels in alsa. Trying is simple - just find the calibration params with a same signal to all the four inputs and configure the .asoundrc ttable params appropriately. I am really curious about your results 
My HTPC runs LibreELEC so I have a very minimal environment to work with. LE is so stripped down that it doesn't even come with arecord.
The proc filesystem came to my rescue: I have /proc/asound/card1/pcm0c which is my line input that I'm using right now. There is also /proc/asound/card1/pcm2c.
Alsamixer offers me controls to select the "Input Source" and "Input Source 1". These can be toggled between "Front Mic" "Rear Mic" and "Line". Each of these has a separate control for "Boost", this offers either 0, 10, 20 or 30dB of extra gain. Then I have separate volume controls for "Capture" and "Capture 1".
From the paths in /proc I'd guess that one input is hw:1,0 and the other is hw:1,2.
The next thing I need to find out is whether LibreELEC even ships the necessary ALSA route plugin. If not I'll have to set up ubuntu on a different machine or find a way to achieve the same thing in PulseAudio.
The proc filesystem came to my rescue: I have /proc/asound/card1/pcm0c which is my line input that I'm using right now. There is also /proc/asound/card1/pcm2c.
Alsamixer offers me controls to select the "Input Source" and "Input Source 1". These can be toggled between "Front Mic" "Rear Mic" and "Line". Each of these has a separate control for "Boost", this offers either 0, 10, 20 or 30dB of extra gain. Then I have separate volume controls for "Capture" and "Capture 1".
From the paths in /proc I'd guess that one input is hw:1,0 and the other is hw:1,2.
The next thing I need to find out is whether LibreELEC even ships the necessary ALSA route plugin. If not I'll have to set up ubuntu on a different machine or find a way to achieve the same thing in PulseAudio.
One thing I have concluded from these experiments is that because channel separation quickly drops off to nearly zero from 100Hz down to 20Hz it makes sense to just discard separation below about 100Hz. As a test I split the L and R signal into mid (L+R) and side (L-R) signals. Then I implemented a LR4 highpass at 100Hz on the side signal and a LR4 highpass at 20Hz plus a few strategically placed notches between 8 and 12Hz. The filter on the side channel catches most of the low frequency noise while the filter on the mid channel is mostly concerned with the tonearm resonance - mine is at 12Hz and has been squashed to -80dB. From a subjective point of view I can say that bass sounds excellent. There is nothing missing down to ~30Hz (the lower limit of my system) while there is hardly any low frequency garbage left.
ariendj: IMO there is no reason the virtual balanced setup should not work, provided you can get to all the four ADC channels in alsa. Trying is simple - just find the calibration params with a same signal to all the four inputs and configure the .asoundrc ttable params appropriately. I am really curious about your results
All four channels are there. My PC splits them up between hw 1,0 and hw 1,2 (hw 0,0 seems to be HDMI).
The command
Code:
pactl load-module module-alsa-source device=hw:1,2 tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yesI considered going the ALSA route (pun intended) but every time I come near an asound.conf file I get a roaring headache. As documentation is notoriously weak or absent I cannot for the life of me figure out the most basic details, like for example: How do I combine the two stereo inputs without touching anything else? The ttable aspect I can grasp. What I don't understand is how asound.conf/asoundrc differentiate between capture and playback devices. I do not need a four channel full duplex setup, I'd prefer to leave the playback path as it is and have only a four channel capture device.
I'll have a try with pulseaudio first, with pulseaudio I more or less know what I'm doing. Should that fail I'll have another go with ALSA. I'm still really curious to find out what the virtual balanced setup does to the noise floor.
Another thing on my list to play with, Although I was considering using calf audio plugins for a visual interface (and have an analog M-S chain I have yet to build)
Very cool! I was recently using my USB soundcard to do the same thing, however it has 1meg input impedance so frequency response was not very flat. I did some fixing in software. It never occurred to me to try the line input of the laptop. 
FWIW, I use crosstalk to adjust stylus azimuth. When crosstalk is equal in left and right, azimuth is good.
FWIW, I use crosstalk to adjust stylus azimuth. When crosstalk is equal in left and right, azimuth is good.