As far I know Wavelength Wavelink works with Thesycon driver. This driver already includes ASIO support.
re: pcm5102, I'm seeing some very annoying and nasty clipping going on when the spdif (translated to i2s input of course) hits 0db. sadly, with 'internet radio' running full at clipping on many stations, you'll see the red clip indicator going off very often, sometimes even regularly on any given song.
some dacs seem to tolerate this better than others.
sadly, I'm seeing the 5102 NOT being very graceful in this manner ;(
I first thought there was a bass clip problem or psu issue but I'm more and more convniced this dac chip does not tolerate '0xff' (so to speak) as its max binary input.
send in normal spdif, from a normal (old style) cd and things sound fine. but as you get the normalized signals from modern cd's and 'radio', this harsh clipping in the dac is going to be an issue.
anyone else witness this on the 5102 chip?
I have a dcx2496 and its known that its lights come up (yellow and red) when its close to 0, not even at 0. and when I see the red or even yellow come on on my dcx, the pcm5102 is clipping *badly* at that point. my other dac (the dc2496, itself) does not sound harsh and gracefully deals a lot better with this near-zero and at-zero value problem.
there's a higher end wolfson dac chip that also has a switch to deal with this (anti-clipping switch). I never really understood why it was there, but maybe I'm getting some insight, now, on this problem.
yes, the stream is at fault, but I'm not sure I'm into using a dac that only works on 'spare headroom' streams.
can anyone else check to see if your 5102 also has this behavior?
some dacs seem to tolerate this better than others.
sadly, I'm seeing the 5102 NOT being very graceful in this manner ;(
I first thought there was a bass clip problem or psu issue but I'm more and more convniced this dac chip does not tolerate '0xff' (so to speak) as its max binary input.
send in normal spdif, from a normal (old style) cd and things sound fine. but as you get the normalized signals from modern cd's and 'radio', this harsh clipping in the dac is going to be an issue.
anyone else witness this on the 5102 chip?
I have a dcx2496 and its known that its lights come up (yellow and red) when its close to 0, not even at 0. and when I see the red or even yellow come on on my dcx, the pcm5102 is clipping *badly* at that point. my other dac (the dc2496, itself) does not sound harsh and gracefully deals a lot better with this near-zero and at-zero value problem.
there's a higher end wolfson dac chip that also has a switch to deal with this (anti-clipping switch). I never really understood why it was there, but maybe I'm getting some insight, now, on this problem.
yes, the stream is at fault, but I'm not sure I'm into using a dac that only works on 'spare headroom' streams.
can anyone else check to see if your 5102 also has this behavior?
Hi,
what you are probably seeing is Gibbs phenomenon - Wikipedia, the free encyclopedia. The peaks of the impulse response add up so that the output of the digital filter inside the DAC chip is larger than what the analog part of the DAC can handle.
With the ES9023 this is particularly bad. Give it a 0dB square input, and even the internal counters will overflow. I.e. 0x7E + 0x02 = 0x81. 0x7E being a valid signal near full-scale positive, 0x02 being a contribution from the impulse response, and 0x81 being near full-scale negative.
Are you seeing phase-reversal like this or mere clipping? Try a software signal generator for a 0dB square wave or the .wav file export in Octave.
Børge
what you are probably seeing is Gibbs phenomenon - Wikipedia, the free encyclopedia. The peaks of the impulse response add up so that the output of the digital filter inside the DAC chip is larger than what the analog part of the DAC can handle.
With the ES9023 this is particularly bad. Give it a 0dB square input, and even the internal counters will overflow. I.e. 0x7E + 0x02 = 0x81. 0x7E being a valid signal near full-scale positive, 0x02 being a contribution from the impulse response, and 0x81 being near full-scale negative.
Are you seeing phase-reversal like this or mere clipping? Try a software signal generator for a 0dB square wave or the .wav file export in Octave.
Børge
interesting! that sounds like it could be it.
this is all by ear, not on a scope yet; but I hear a popping that I thought was in the source; but turns out on my other dacs it plays fine. when I get a chance I'll try to put a software wave into it and see what comes out.
but at this point, I'm a bit sour on this dac chip ;( I just can't 'demand' that people put so-called proper numbers into its digital inputs. the more they compress and normalize (on radio or cd or even file!) the more we are going to see this, I guess.
if this is an internal numbers issue, then no amount of power supply 'strength' is going to help me here, is it? I was thinking maybe the charge pump was being overtaxed but you think its internal value overflows? yikes. that's unsolvable then, isn't it? at least at the chip-user level.
this is all by ear, not on a scope yet; but I hear a popping that I thought was in the source; but turns out on my other dacs it plays fine. when I get a chance I'll try to put a software wave into it and see what comes out.
but at this point, I'm a bit sour on this dac chip ;( I just can't 'demand' that people put so-called proper numbers into its digital inputs. the more they compress and normalize (on radio or cd or even file!) the more we are going to see this, I guess.
if this is an internal numbers issue, then no amount of power supply 'strength' is going to help me here, is it? I was thinking maybe the charge pump was being overtaxed but you think its internal value overflows? yikes. that's unsolvable then, isn't it? at least at the chip-user level.
are you thinking I have the 'AIF' interface between the spdif receiver and the dac set wrong? I picked 24bit i2s which I thought would be correct. if 16bits comes in, 24 bits are still sent (?) but just padded with zero, right?
if things were shifted even 1 bit, I'd hear overflows on everything, wouldn't I? ie, half volume would be max volume and every single cd today has averages well over half-scale sample values.
if things were shifted even 1 bit, I'd hear overflows on everything, wouldn't I? ie, half volume would be max volume and every single cd today has averages well over half-scale sample values.
close-up of how I wired things (not sure if this is enough detail or not, I can reshoot again if needed):
the settings on the wolfson are: MS=1 (master mode), txsrc=0, aifconf0=1, aifconf1=0. that should set it to 24bit i2s mode if I read the specs correctly.
note that I did leave master clock off and only wired 3 i2s wires. I doubt that giving that master clock would affect this (?) but I could add that 4th wire if its worth doing and retesting.
An externally hosted image should be here but it was not working when we last tested it.
the settings on the wolfson are: MS=1 (master mode), txsrc=0, aifconf0=1, aifconf1=0. that should set it to 24bit i2s mode if I read the specs correctly.
note that I did leave master clock off and only wired 3 i2s wires. I doubt that giving that master clock would affect this (?) but I could add that 4th wire if its worth doing and retesting.
hang on - just to clarify, I'm NOT driving the pcm5102 from the usb dac and hearing this problem (per se). I have a standalone dac with wolfson 8804 receiver driving the pcm dac chip. the 8804 is in hardware mode (foolproof for me, lol) and I know its i2s is not funky or due to any software or driver issues.
sorry if that was not clear. this has nothing to do with the usb i2s stuff; its a pcm5102 problem.
Half-scale is only 6 dB down, and sounds a lot louder than half volume, due to the logarithmic nature of human hearing. But you're right, you'd probably hear overflows on just about everything.
Last edited:
I was going to say that the DAC chip isn't really 100% responsible for what you hear. A common problem is that the analog section between the DAC output and the RCA jack can be overloaded.
However, I took a quick look at the PCM5102 data sheet, and I see that their recommended circuit is nothing but a resistor and capacitor. It's really difficult to clip passive parts (other than inductors), so the problem seems to be the responsibility of the PCM5102, as you said. Personally, I think this makes the PCM5100 series look like a really bad choice for audiophile.
VBus would be fine. Its a dedicated DIT that supports all of the standards. I believe it can be hard programmed so no CPU requirements. It can drive SPDIF or AES/EBU directly. If its not sharing power with any sensitive circuitry then it won't affect them. The AES/EBU drive requires 5V (8V P-P output, the real reason AES can sound better than SPDIF, more signal to noise).
ha! I had one of those chips, too, in my parts bin. not even opened and still in its mouser pkg.
soldered one up:
and I'll connect it to the audio widget's i2s tomorrow and see how it flies.
the lead pitch was MUCH easier to deal with than the wolfson. its a larger part but I prefer easier-to-solder over smaller size.
I'll connect her tomorrow and see if bits come out
soldered one up:
An externally hosted image should be here but it was not working when we last tested it.
and I'll connect it to the audio widget's i2s tomorrow and see how it flies.
the lead pitch was MUCH easier to deal with than the wolfson. its a larger part but I prefer easier-to-solder over smaller size.
I'll connect her tomorrow and see if bits come out
It is not possible to run a 5 V chip directly from Vbus. That's because nearly all 5 V chips have an absolute minimum voltage requirement of 4.75 V, but Vbus can legally drop to 4.35 V or even 4.01 V in certain situations such as when attached to an unpowered hub.
What is needed is a boost regulator. Inductive boosts can create noise, but Maxim has parts like the MAX1595 that only need capacitors and thus run quieter.
Of course, if you want external power for isolation reasons, then 5 V is no problem, or even 18 V.
From the spec:
Also, while the output can't be guaranteed to meet the Vout high spec its unlikely that the chip will stop functioning at 4.74V or even much lower since its all digital. The prop delays may change and it would not have the full AES drive at 4V but I would not be surprised to see a decent signal at the far end of a cable. Just don't do this if you are planning to make 10,000 units.
The AB1.1 draws more than 2 unit loads. If this were a USB product headed for certification these would be valid issues to address but a DIY audiophile device can be expected to have more stringent power requirements than the worst case USB spec. Eliminating a regulator actually reduces parts count.
Also, while the output can't be guaranteed to meet the Vout high spec its unlikely that the chip will stop functioning at 4.74V or even much lower since its all digital. The prop delays may change and it would not have the full AES drive at 4V but I would not be surprised to see a decent signal at the far end of a cable. Just don't do this if you are planning to make 10,000 units.
I'm looking at the 8406 schematic you recently posted, now.
you are going to talk to that chip in software mode? it seems so (?)
you have a circle labeled 'spdif' on pin4/rxp. that will set the serial input format I think? is there a reason to not just set this chip to i2s mode?
I'm going to try to config and test the chip in hw mode since I consider this a pretty 'dumb' function and I'd rather not have to chat with the chip if I don't have to
you are going to talk to that chip in software mode? it seems so (?)
you have a circle labeled 'spdif' on pin4/rxp. that will set the serial input format I think? is there a reason to not just set this chip to i2s mode?
I'm going to try to config and test the chip in hw mode since I consider this a pretty 'dumb' function and I'd rather not have to chat with the chip if I don't have to
Hi guys,
I'm not going to put in a boost converter for the digital output! There are plenty 3.3V parts out there which will run from the same LDO as powers the DAC today.
Quoting page 38 of the CS8406 data sheet: "The AES3 and IEC60958-4 specifications call for a balanced output drive of 2-7V peak-to-peak into a 110 Ω ±20% load with no cable attached."
So 3.3V supply shouldn't be an issue.
I have set it ut in SW mode because that is more flexible and because there is an available I2C bus. I agree that it would be easy to set it up for straightforward I2S. The only thing is table 4 on page 29 to set the sampling frequency relative to MCLK. That looks to me like two GPIO pins coming from the MCU, so - I thought - it might be just as good to configure the whole thing in firmware.
The SPDIF pin on the MCU doesn't really do anything. But for the future I want to be able to use a module which has a CMOS-level SPDIF line. So this is only about reserving a GPIO line for future use.
Børge
I'm not going to put in a boost converter for the digital output! There are plenty 3.3V parts out there which will run from the same LDO as powers the DAC today.
Quoting page 38 of the CS8406 data sheet: "The AES3 and IEC60958-4 specifications call for a balanced output drive of 2-7V peak-to-peak into a 110 Ω ±20% load with no cable attached."
So 3.3V supply shouldn't be an issue.
I have set it ut in SW mode because that is more flexible and because there is an available I2C bus. I agree that it would be easy to set it up for straightforward I2S. The only thing is table 4 on page 29 to set the sampling frequency relative to MCLK. That looks to me like two GPIO pins coming from the MCU, so - I thought - it might be just as good to configure the whole thing in firmware.
The SPDIF pin on the MCU doesn't really do anything. But for the future I want to be able to use a module which has a CMOS-level SPDIF line. So this is only about reserving a GPIO line for future use.
Børge
I'm looking at the 8406 schematic you recently posted, now.
you are going to talk to that chip in software mode? it seems so (?)
you have a circle labeled 'spdif' on pin4/rxp. that will set the serial input format I think? is there a reason to not just set this chip to i2s mode?
I'm going to try to config and test the chip in hw mode since I consider this a pretty 'dumb' function and I'd rather not have to chat with the chip if I don't have to