[Jambo]

Thanks for the responses - glad you think it's a good idea.

I've pretty much finished up at uni now so going to get on with this. I have a couple of very small changes to make to the board, then I'm going to get a reasonable number of them made.

Currently working on a user manual and a couple of different versions of the micro code.

 

[pistolpete111]

Sounds like a great project. I'm interested in getting 2 kits!

 

[pistolpete111]

Jambo - I have a couple of questions about your DAC:

1) Is there any concern about going from USB->SPDIF->I2S? I guess there shouldn't be any disadvantage to this but you know more about this stuff than I.

2) Would it be possible for the boards to have a layout where using more of the inputs on the 8805 could be optional? So say, some day if I have a need for a few more TOSLink sockets, i could just add them to the existing board?

Sounds like a great project anyway - hope your work on it is coming along nicely

Thanks,

Pete

 

[Jambo]

Hi Pete,

1) Yes, some people find this a concern - they suggest that the SPDIF interface is more prone to jitter. Also, since the USB standard for audio is I2S (someone correct me if I'm wrong), it does seem odd to go from USB (I2S) to SPDIF to I2S again - it clearly can't do anything positive to the signal.

However, I wanted a USB input and coaxial/optical inputs and the WM8805 is a nice SPDIF multiplexer so this seemed the natural route. Also, the WM8805 is superb at recovering the I2S signals with very high jitter rejection, so I am quite confident that any impact on the signal will be small - it certainly sounds good to me. The only alternative that I can see is to have used an FPGA as a multiplexer between the SPDIF receiver and the DACs to switch the I2S signals around. I personally didn't feel that this would be worth the effort and extra cost.

2) I'll look into this - microprocessor pins may be the limiting factor assuming that we want an LED and switch for each source, but I'll see what I can do. I also need to check just how much space I have along the edge of the board where the connectors are.

Hope this helps,

Jamie.

 

[FrederikS|TPU]

This is going to be one killer DAC. And for under £100 it is going to be hard to beat. I am so looking forward to seeing a final version, perhaps with a nice enclosure as well!

 

[CountChoculaBot]

How much more does a kit cost with the WM8741 instead of the WM8740? Also, is the 8741 a significant SQ improvement over the 8740?

 

[pistolpete111]

Quote:

Originally Posted by CountChoculaBot /img/forum/go_quote.gif How much more does a kit cost with the WM8741 instead of the WM8740? Also, is the 8741 a significant SQ improvement over the 8740?

The overall kit cost has not been decided yet as far as I know. The current problem with the WM8741 is that it is generally not available yet. Some of them exist, but from what I can see, they are not available to order yet.

When they do go on sale to the general public, I think I read somewhere their price will be 3 times that of the 8740. Although I have not heard the 8741 yet, its spec sheet makes it look like a significant improvement over the 8740. Although, in practice I guess the improvement will be hardly audible. I guess it depends on the rest of the components in your DAC. The 8741 offers 128dB SNR as opposed to the 8740's 120dB SNR (and it has a few more advantages too). While that value sounds huge, i'd expect that unless your using the highest quality of PCB, and components on it, with a very careful design, and have a serious hifi setup, the difference will not be that big - I guess we'll have to wait and see. As the chip is not available yet, I'm really only guessing right now.

The two chips are pin-compatible, so if you went with the 8740's now, you could upgrade them in the future with no other changes required to the DAC.

Pete

 

[Jambo]

Spot on Pete - the Wolfson site lists the 8741 at around $15 while the 8740 is listed at around $5, so since the kit needs two the difference will be of the order of $20. Also as Pete correctly said, the problem at the moment is getting hold of these, but the kit will definitely work with them and has the ability to switch the switchable digital filters.

Interestingly the WM8741 actually has worse THD than the WM8740, but as we all know music is not a 1kHz sine wave... The filters do a nice job of reducing pre ringing but whether it's worth the extra cash is up to you...

 

[Marzie]

Jambo, this might be a little nit picky but I like the look of these panel jacks (the analog rcas) a little better,although the ones you selected may be fine, I see a little black in the first picture, I just don't like the plasticky white look. Actually the black pcb is pretty cool too, but that adds to the cost, I'm sure... anyway, how are things coming?

 

[Jambo]

Hi Marzie,

Thanks for the suggestion. As you say though, there is actually some black on them and you could easily make a case capable of hiding the white altogether. Also I really don't want to change this aspect of the PCB as knowing my luck I won't get it right first time and I've spent enough on prototype runs so far! I've got a better pic of the jacks for you:

As for how things are going, I'm currently trying to resolve a small software issue. When changing source, about 1 time in 10 the DACs fail to mute and there is a horriffic noise through the outputs. The other 9 times, the DACs mute nicely and the source changes and they come back up again. If anyone with some software knowhow has any ideas why this may be, they'd be gratefully received!

Here is a sample bit of code for looking at the switches:

Code:

[left]if (bit_is_clear(PINB, 3) && (current_src != 3)) { for (counter = 0; counter <= mute_time; counter++) { PORTD &= ~(1<<1); // Mute DACs } //SPDIF source = 011 i2c_start(WM8805+I2C_WRITE); i2c_write(0x08); // write address = 08 i2c_write(0x1B); // data = 1Bh i2c_stop(); // stop, release bus current_src = 3; //put on corresponding LED: PORTB = 0x8f; // source 3 - output 3 on; inputs with pullups. for (counter = 0; counter <= mute_time; counter++) { PORTD &= ~(1<<1); // Mute DACs } PORTD |= 1<<1; //unmute DACs } else {//no change in source, move on... counter = 0; //do something useless }[/left]

I know I haven't done a lot to deal with switchbounce, but my feeling is that the opening 'if' means that this is only ever executed once and the 'if_bit_is_clear' decision decides that the switch is or is not pressed, after that it should be immaterial. Oh, also, the two 'for' loops is just me trying stuff to try and make it work, there was originally only one.

I have considered that it may be due to the optimiser removing what it considers to be useless instructions, but then I think the mute would fail every time.

As I have said, my C and, in particular, microprocessor knowledge is limited so any advice gratefully received!

A second issue is what looks on the face of it to be oscillation at the output filters. When probing the outputs with no music, I can see a sine wave of a few 10s of mV in the 10's of MHz region. I am convinced that this is being caused by the capacitance of my cheap 'scope probe - i.e. it isn't there unless I'm looking for it! It only happens with the AD797, not the OPA134. I am further convinced that it is caused by the probe since changing the probe to x10 mode (this changes the capacitance of the probe) changes the frequency and amplitude of the oscillation - the amplitude isn't changed by the factor of 10 expected, it is much less. Anyone got any views on this? As I say, I'm fairly sure it is caused by the probe so it isn't a problem, but I don't want to pass this problem onto other people until I'm certain!

 

[error401]

Quote:

Originally Posted by Jambo /img/forum/go_quote.gif Here is a sample bit of code for looking at the switches: Code: [left]if (bit_is_clear(PINB, 3) && (current_src != 3)) { for (counter = 0; counter <= mute_time; counter++) { PORTD &= ~(1<<1); // Mute DACs } //SPDIF source = 011 i2c_start(WM8805+I2C_WRITE); i2c_write(0x08); // write address = 08 i2c_write(0x1B); // data = 1Bh i2c_stop(); // stop, release bus current_src = 3; //put on corresponding LED: PORTB = 0x8f; // source 3 - output 3 on; inputs with pullups. for (counter = 0; counter <= mute_time; counter++) { PORTD &= ~(1<<1); // Mute DACs } PORTD |= 1<<1; //unmute DACs } else {//no change in source, move on... counter = 0; //do something useless }[/left] I know I haven't done a lot to deal with switchbounce, but my feeling is that the opening 'if' means that this is only ever executed once and the 'if_bit_is_clear' decision decides that the switch is or is not pressed, after that it should be immaterial. Oh, also, the two 'for' loops is just me trying stuff to try and make it work, there was originally only one.

Just a small comment: you really should generalize this function and have a separate function scanning the inputs and figuring out which SPDIF address to send to the WM8805. Then you just need a select_input(3) call, and one block of code that looks like this instead of 'n' blocks that are almost identical.

Otherwise your code seems fine to me. I believe you're probably just unmuting too soon. The receiver PLLs will take some time to lock to the new signal. There is an UNLOCK flag available in WM8805, it can be mapped to a GPO or read as a register. It can also generate an interrupt when lock is acquired.

If you're not monitoring the receiver status, you'll need to wait a while, definitely longer than 255 cycles - and I think the compiler is smart enough to simplify those loops to a single statement anyway. If you #include<util/delay.h>, avr-libc provides timed busy-waits for you in _delay_us(double) and _delay_ms(double). Read the manual for them because there are limits (max of 32ms delay with 8MHz clock), and make sure you set F_CPU properly. That'll be a little nicer than looping a bajillion times.

Finally, the compiler can generate assembly output you can read and make sure the optimization isn't doing anything funky.

As for switch debouncing, it shouldn't be much of a problem with this approach since so much happens between detecting the initial event and checking again. The I2C transfer alone probably takes long enough to deal with switch bounce. You need more robust switch handling if you're using interrupts for input or scanning the inputs quickly enough to catch the bounces; I don't think that will be the case here. Worst case, if you do have problems, just add a few ms delay after handling the input.

 

[sleepy dan]

Hi Jambo, looking at your schematics, I couldn't see any resistive buffering on the outputs of the AD797s. Adding an R of ~100 ohms may stop the ringing.

 

[Jambo]

Error401 - thank you for your helpful response once again.

You're quite correct - my coding style leaves a lot to be desired.

I have tried using the UNLOCK flag available as GPO1 to mute the DACs while the WM8805 is upset. Unfortunately however the noise still occurs sometimes - I guess that means it must be coming from the DAC....?

Using fixed delays, it usually works fine and the output is silent for an appreciable amount of time. But when the noise occurs the delay/mute just doesn't happen - the music starts straight away with the fuzz over the top.

I have tried to use delay.h already, but I found that (since it turns the optimiser off) the code then ended up far too big for the ATTiny2313.

I'm sure it'll be something simple once I eventually find it!

 

[Jambo]

Tidied it up a bit

Code:

[left]int spdif_select(int next_src, int current_src, int mute_time) { unsigned int counter; if (current_src != next_src) { PORTD &= ~(1<<1); // Mute DACs for (counter = 0; counter <= mute_time; counter++) { PORTD &= ~(1<<1); // Mute DACs } //I2C writes to change SPDIF source i2c_start(WM8805+I2C_WRITE); i2c_write(0x08); // write address = 08 i2c_write(0x18 + next_src); // data = 0x18h + next_src i2c_stop(); // stop current_src = next_src; //put on corresponding LED: PORTB = (0x0f + (1<<(next_src+4))); for (counter = 0; counter <= mute_time; counter++) { PORTD &= ~(1<<1); // Mute DACs } PORTD |= 1<<1; //unmute DACs } else {//no change in source counter = 0; //do something useless } return current_src; }//end spdif_select[/left]

It behaves the same as before but uses a good bit less of the memory, nice.

I'm going to get the scope out at some point and check if the mute pin is actually being pulled low when the filthy noise occurs, I can't help but feel that the DACs are choosing to ignore it!

sleepy_dan - thanks for the idea, I'd rather avoid this if possible though. As I say, I'm confident that it's the scope probe just wondering if anyone has seen this sort of thing before?

 

[willisv]

I am interested in a kit!