Building the ultimate NOS DAC using TDA1541A

My best guess is that this might be caused by thermal issues.

Dielectric distortion?
(distortion caused by the dielectric material)

We have talked previously about the increase in clarity with our magnet or enamelled "Litz" wire interconnects. I suspect at least a fraction of it comes from the very thin enamell (even if its own dielectric constant is poor) compared to better but wider dielectric coating.

Nudity, in your case, proved healthy. :D

I look forward to see your new DI4 (it should be very boring to build compared to my own DIDACs :D :clown: ) because I only own 4 DACs, but at present, I am on an "analog" phase, using my father's Lenco L75 ;) ...which reminds me, could you compare your DI4 with a good analog source... :angel:


All the best,
M
 
Hi oshifis,

The naked Vishay resistors are readily avilable. I tried them and they proved to be very good sounding indeed:

I know, they are available from Texas Components Corporation (TX2352), there is also an improved Z-foil version (TX2575).

Percy Audio sells so called Vishay VSH versions with yellow epoxy coating, similar shape like multilayer capacitors. I plan to test / compare these soon. I am also going to test Vishay 1280G bulk metal foil trimmers for the TUBEDIF module balance adjustment.

The reason why I removed the S102 housings was that I already bought a lot of these resistors at Farnell, and wanted to use these instead of buying new ones. The sound quality from the standard S102 resistors wasn't convincing, they seem to perform best when placed in series with the audio signal, they don't seem to perform optimal when placed in parallel with the signal.
 
-ecdesigns- said:
The sound quality from the standard S102 resistors wasn't convincing, they seem to perform best when placed in series with the audio signal, they don't seem to perform optimal when placed in parallel with the signal. [/B]

I have noticed this as well with the TX resistors, and find that Caddock MK132 sound best in the shunt/parallel configurations.
 
Hi nicoch46,

I have red PRP on i\v 1541s2 , are good ?

No, they aren't the best for passive I/V conversion.

Passive I/V resistors need to have lowest possible noise, in order to fully retrieve low level detail, as LSB changes are in the microvolt range (.160 / 65536 = 2.4uV). The majority of metal metal film resistors are unsuitable for achieving best results, this includes PRP. The most common problems are too bright sound, "edge" on vocals, sound smearing, and sound coloring.

One must also differentiate between "good sounding" resistors, and resistors that are basically "inaudible" by remaining fully neutral, providing optimal transparency. Neutral resistors (like bulk metal foil and non-inductive wire-wound resistors) will confront one with the sum of all flaws present in an audio set, this usually isn't very pleasant to hear. So "good sounding" resistors are used to color the sound, covering-up these flaws.

If you plan to go the route of transparency, it will be a difficult one, as it could take a lot of time to properly tune an audio set.

Since there isn't a single resistor that's fully transparent, it's best to mix different neutral sounding resistor types in a design, in order to avoid ending up with the specific sonic signature of one resistor type. Usually choices have to be made anyway, depending on resistance value, wattage, and specific application.

I currently use home-made non-inductive (mobius loop) copper wire resistors (20 Ohms) for each of the 4 passive I/V resistors in the DI4T. They are soldered directly to the grid connections of the tube socket in order to minimize noise. These easily outperform bulk metal (Z) foils with or without housing, when it comes to transparency. The copper wire resistors sound exceptionally transparent, neutral and analogue. The nice thing is, you can make these yourself with minimal cost.

The following resistors should also be quite good performers:

- Caddock TF020, MK132
- Mills MRA-5, MRA-12, and MR-200
- Vishay S102, VSH1, TX2352, TX2575 (Z-foil)
 
-ecdesigns- said:
The copper wire resistors sound exceptionally transparent, neutral and analogue. The nice thing is, you can make these yourself with minimal cost.

Hi ecdesigns,

I think that I have already seen yours Cu resistors in this thread, but I can't remember how they are actually build. So, could you (once again) explain how to build them with all the math (and images, if there is any), thank you?

-ecdesigns- said:
The following resistors should also be quite good performers:

- Caddock TF020, MK132
- Mills MRA-5, MRA-12, and MR-200
- Vishay S102, VSH1, TX2352, TX2575 (Z-foil)

Is that your order of preference for I/V resistor type?
 
Hi aparatusonitus,


I think that I have already seen yours Cu resistors in this thread, but I can't remember how they are actually build. So, could you (once again) explain how to build them with all the math (and images, if there is any), thank you?

post #1954

Attached photographs, left mobius loop construction, center, twin non-inductive resistor (two mobius loops twisted together), right a practical twin non-inductive resistor used in the DI4T. Bobbins are available from Farnell.


Is that your order of preference for I/V resistor type?

No they are just in alphabetical order.

I am very pleased with the modified S102 resistors (housing removed and the black glue trace at the back of the resistive element interrupted). The Vishay VMF475-VSH1 resistors, supplied by Percy Audio are also very good performers, these seem to have a yellow epoxy coating.
 

Attachments

  • cwres.jpg
    cwres.jpg
    36.9 KB · Views: 1,622
Mac OS X - exact playback

Hi John,

do You know if the current OS X does bit and sample exact playback?

I have to buy a new computer and I am afraid of loosing sound quality with the newest Leopard. Is there an easy way, besides Airport Express, to ensure exact playback under Mac OS for the USB DAC ?

best Regards

PS: waiting for DI4T imression ;-)
 
Hi omainik

do You know if the current OS X does bit and sample exact playback?

This has little to do with the OS X version, but the way it's used together with applications like iTunes. Max OSX Panther, Tiger and Leopard can provide bit-perfect playback.

iTunes7 now has an integrated 24-bit digital processor for mixing, adding effects and volume control. This task was previously performed by core-audio (16-bit processor), and it could be disabled when no volume control or mixing was required.

In short it's (no longer) possible to get bit-perfect playback from mac OSX / iTunes7 when using the on-board audio interfaces (USB & mini-Toslink).

There is no easy way to solve this, well except for using an external Airport Express module.

This is caused by the fact that all audio data streamed to these on-board interfaces has to pass the 24-bit mixer. This mixer cannot be switched-off for the on-board digital audio interfaces. Setting volume control to maximum and disable other sound sources won't help either.

Processing means upsampling the original 44.1/16 digital audio data to 48 KHz, perform 24-bit processing (volume control / mixing / filtering), then downsample it to 44.1/16 again. The degradation in sound quality (even with 24 bit processing) is clearly audible.



The Apple Airport Express module (also supports iTunes for windows) simply receives a file over the (wireless) computer network including full error correction.

The file does not pass the 24-bit processor (check-box in iTunes allows for completely blocking the 24-bit processor). This also means that the volume control slider is grayed-out (disabled), and no effects or sources can be mixed. It's only possible to play the digital audio file in iTunes.

The AE module only handles (fixed) 44.1/16 format.
 
ECDesign,

iTunes7 now has an integrated 24-bit digital processor for mixing, adding effects and volume control. This task was previously performed by core-audio (16-bit processor), and it could be disabled when no volume control or mixing was required.

Were did you come up with this idea?

First off there is no Mixer in iTunes. Heck for that matter what in the world would it mix? It can only handle one task at a time.

Second all data inside iTunes, CoreAudio, and for that matter Vista and XP are handled in 32 bit floating point.

CoreAudio as in Vista does have a MIXER that is true. Not like the XP KMIXER which would manipulate the data but basically the application feeds the interface 32 bit floating point which is then converted to the playback size required for the device.

Processing means upsampling the original 44.1/16 digital audio data to 48 KHz, perform 24-bit processing (volume control / mixing / filtering), then downsample it to 44.1/16 again. The degradation in sound quality (even with 24 bit processing) is clearly audible.

WHAT??????

Look the only time a unit is resampled is if the setting in Audio Midi for that device declares a rate other than the Fs rate of the song it's playing back. iTunes keeps a static variable when it loads to the rate declared in Audio Midi settings.

If that is 24/48 and it's plays a 44.1/16 bit track the data will be upsampled to 24/48.

If it is set in Audio Midi to 24/44.1 the sample would not be touched and the data would be padded with 8 zero's.

If the user changes the rate while iTunes is running then the problem occurs. iTunes would say upsample as in the first example to 24/48 and then CoreAudio would resample to the new set rate.

I have a USB analyzer hooked up too my USB dac development platform along with the Prism dScope III and serveral other testing devices so I can see exactly what data is sent from the computer at all times.

Thanks
Gordon
 
Gordon.

Good to see you over here .;)

Just to explain for the others around here: I opened up a thread at Audio Asylum
asking about the subject because I knew that Gordon is sneaking around.
In the past he posted solutions over there to get bit-perfect data from OSX.

http://www.audioasylum.com/cgi/t.mpl?f=pcaudio&m=33960

Now my 2 cents:

OK it is not a or "the" mixer. Perhaps it is the 32 bit processing, which is probably not done if you route the data to the Airport Express.
Or it might be the API which just uses the Core Audio mixer and can't get passed by. No idea how they're doing it.

Processing in 32bit float will for sure have a negative impact on the signal.
Of course this also depends on what you actually gonna do with the signal.
A conversion will for sure impact the signal. It won't be bit-perfect.

Running my Brutefir at 64bit float is quite an improvement over 32bit. 32bit DSP is an absolute NoGo for me.

Anyhow. You might want to let us know how to get a bit-perfect stream out of OSX.

I had a chance to listen to the difference at John's place. These were evident.



Cheers
\Klaus
 
SC,

OK it is not a or "the" mixer. Perhaps it is the 32 bit processing, which is probably not done if you route the data to the Airport Express.

Remember the AE is kind of different than all other Audio devices. This is the only device that iTunes actually talks to. Remember all outputs will be 16/44.1 for the AE no matter what. Therefore the AE does not fall into the same relm as other devices which have setting in Audio/Midi.

In iTunes it will always convert to 32 bit floating point. It will then go to the DSP part of the application if the EQ is on or Sound Enhancer. If the vol is set to 100% (and SoundCheck is off) it multiplies 1xsample = sample. It then goes to the output which forks to either CoreAudio or AE output.

Thanks
Gordon
 
Hi Gordon,

Good to see you on this thread :)


First off there is no Mixer in iTunes. Heck for that matter what in the world would it mix? It can only handle one task at a time.

Try this, play a CD track in itunes, and open some Flash content in the safari browser, or play a movie. The sounds sources will be mixed (you hear both sources simultaneously).

This doesn't happen when using the AE module, and disabling volume control (check box in iTunes). The AE module provides consistent better sound quality when compared to my iMac on-board USB and mini-Toslink interfaces. It also matches the sound quality from my reference CD player with Toslink output.

The connected DI4T uses an advanced jitter blocking system, the Toslink twin-VCXO receiver. I added a block diagram of this system. When testing USB sources I use a USB to Toslink converter, based on a PCM2706.

There are no audible differences when connecting sources with different jitter amplitude and spectrum. It makes no difference if I use a 1 meter interlink or a 10 meter clear plastic interlink. Sound quality doesn't even change when I add an optical repeater and extend the clear-plastic interlink to 20 meters.


WHAT??????

Look the only time a unit is resampled is if the setting in Audio Midi for that device declares a rate other than the Fs rate of the song it's playing back. iTunes keeps a static variable when it loads to the rate declared in Audio Midi settings.

Just a quote from an article in stereophile, discussing iTunes7

quote "Also, the end user should not hesitate to use the volume control in iTunes 7.x, as it is very well designed and operates at 24-bits for audio devices that support 24-bit operation."

The link is here:

http://www.stereophile.com/news/121707lucky/


and this:

quote "2) OSX still does not have the ability to follow sample-rate changes. We consider this a nuisance for most users and a show-stopper for users who want to play a mixed list of 44.1kHz and 96kHz material. An OSX sample-rate mismatch will invoke the very-poor-quality sample-rate conversion that is built into OSX. The iTunes 7.5 bug seems to be locking on this sample-rate conversion at all sample rates other than 96kHz. Until this is fixed, OSX is not the operating system of choice for audio playback.
[...] After extensive testing and communicating directly with the engineering team at Apple, some of these initial observations have been explained. We now know the reason for the poor performance observed in the initial tests, and we have conclusive information about the operation of iTunes 7.x on Mac OS X.

[...] If the user changes CoreAudio's sample-rate in AudioMIDI Setup to something different than what iTunes is locked to, CoreAudio will convert the sample rate of the audio that it is receiving from iTunes. In this case, the audio may be undergoing two levels of sample-rate conversion (once by iTunes and once by CoreAudio). (The SRC in iTunes is of very high quality (virtually inaudible), but the SRC in CoreAudio is horrible and will cause significant distortion.) If the user wants to change the sample rate of CoreAudio, iTunes should be restarted so that it can lock to the correct sample rate.

—Elias Gwinn, Benchmark Audio

The link is here:

http://lists.apple.com/archives/coreaudio-api/2008/Jan/msg00272.html

It specifically states the possibility of two levels of sample rate conversion, once in iTunes and once in core audio. It also mentions a SRC integrated in iTunes.


I have a USB analyzer hooked up too my USB dac development platform along with the Prism dScope III and serveral other testing devices so I can see exactly what data is sent from the computer at all times.

Ok, then it would be interesting to compare the output of 44.1/16 material between the AE output and iMac on-board audio interfaces.

AE output (that gives by far best sound quality on my set) is verified to be bit-perfect:

Quote from a Stereophile article,

quote "Some audiophiles have dissed the AirPort Express on the grounds that its digital output is not bit-accurate. However, I found that this was not the case, that the data appearing on the AE's digital output were identical in the original file. To check this, I compared a WAV file with a duplicate that I had captured on my PC from the AirPort Express's S/PDIF output. I used iTunes on my PowerBook playing a version of the file encoded with Apple Lossless Compression to feed data to the AE. The files were bit-for-bit identical, proving that the AirPort Express is transparent to the music data (as is ALC, for that matter). "

Link:

http://www.stereophile.com/digitalprocessors/505apple/
 

Attachments

  • twinvcxo.jpg
    twinvcxo.jpg
    64.4 KB · Views: 1,091