if there is truly better performance in software mode vs hw mode, sure, it would be worth the effort, then.
has this been PROVEN, though?
I'm hoping to have some software to drive an 8804 or 8805 but its not on my very short term radar. then if there is a way to compare the two, we can put it to a real test.
isn't 176k 'really hard' to implement properly in software, though? and, does anyone care about such an oddball samplerate?
has this been PROVEN, though?
I'm hoping to have some software to drive an 8804 or 8805 but its not on my very short term radar. then if there is a way to compare the two, we can put it to a real test.
isn't 176k 'really hard' to implement properly in software, though? and, does anyone care about such an oddball samplerate?
Hi guys,
I have started reading up on the WM8804 datasheet. For hardware mode it looks like the pins have one function right after power-on reset and other functions after that. That is not too convenient. But then again, I haven't understood the full thing yet. SW mode will give the most flexibility.
I'm not all that keen on jumpers....
The jitter rejection, isn't that for SPDIF reception? I don't want to send SPDIF -> I2S -> DAC. Only USB -> I2S -> SPDIF. So then, does it really matter how the clock is configured?
Børge
I have started reading up on the WM8804 datasheet. For hardware mode it looks like the pins have one function right after power-on reset and other functions after that. That is not too convenient. But then again, I haven't understood the full thing yet. SW mode will give the most flexibility.
I'm not all that keen on jumpers....
The jitter rejection, isn't that for SPDIF reception? I don't want to send SPDIF -> I2S -> DAC. Only USB -> I2S -> SPDIF. So then, does it really matter how the clock is configured?
Børge
Last edited:
I can't see myself ever needing 176k mode, either. but its also a marketing check-off box and if you can cover all samplerates, might as well.
its not clear to me (yet) how to support 176k well in software mode. it seems to parade as 192k and the receiver chip has to play some kind of game to see if 192k actually locks or 176k locks. even then the data sheet talks about 'knowing ahead of time' what the sr is. how aburd! this is one reason I opted to go direct to hw mode.
can you give some insight on where, in their dataheet or app notes, do they say that software mode will give lower jitter on output?
I can see that locking on time (pll time) is faster but so what. no one cares about how long it takes to lock as long as its under a second or so.
now, I'm mostly a software person and I'm not 'afraid' of firmware (lol) but I evaluate each project and decide if its WORTH the time and effort to develop and debug firmware vs just using the hardware black box as the vendor designed. so far, I'm not seeing WHERE we benefit from software in this application and by HOW MUCH we gain, if any at all. wonder if its worth trying to contact wolfson?
on the receive side (if you are receiving spdif) I see GREAT value in software mode simply because you can query the registers and find out the transmitted samplerate, the wire rate (the 2 could be different; one is the wire speed of the data and the other are just info bits in the header which are just set by the sender and could actually be incorrect). you can get word size (16,20,24) and some other goodies, too. I'd love to see that on incoming spdif streams; but the job of taking i2s and making spdif from it seems as blackbox as you can get. what value-add is there in taking the software approach here?
its not clear to me (yet) how to support 176k well in software mode. it seems to parade as 192k and the receiver chip has to play some kind of game to see if 192k actually locks or 176k locks. even then the data sheet talks about 'knowing ahead of time' what the sr is. how aburd! this is one reason I opted to go direct to hw mode.
can you give some insight on where, in their dataheet or app notes, do they say that software mode will give lower jitter on output?
I can see that locking on time (pll time) is faster but so what. no one cares about how long it takes to lock as long as its under a second or so.
now, I'm mostly a software person and I'm not 'afraid' of firmware (lol) but I evaluate each project and decide if its WORTH the time and effort to develop and debug firmware vs just using the hardware black box as the vendor designed. so far, I'm not seeing WHERE we benefit from software in this application and by HOW MUCH we gain, if any at all. wonder if its worth trying to contact wolfson?
on the receive side (if you are receiving spdif) I see GREAT value in software mode simply because you can query the registers and find out the transmitted samplerate, the wire rate (the 2 could be different; one is the wire speed of the data and the other are just info bits in the header which are just set by the sender and could actually be incorrect). you can get word size (16,20,24) and some other goodies, too. I'd love to see that on incoming spdif streams; but the job of taking i2s and making spdif from it seems as blackbox as you can get. what value-add is there in taking the software approach here?
in software mode, its worse. you have to apply logic levels to pins at startup and then remove them for actual use.
in hardware mode, you never have to remove things. I didn't! you set some pins, tie them up or down and leave them there. I liked that quite a lot. I've had to 'pulse' some pins on other chips before and I hate that concept.
in hardware mode, you never have to remove things. I didn't! you set some pins, tie them up or down and leave them there. I liked that quite a lot. I've had to 'pulse' some pins on other chips before and I hate that concept.
Jitter rejection is for externally-clocked DAC systems. Ideally, a USB DAC system will be internally-clocked. For that reason, I'd suggest completely avoiding SPDIF input, since SPDIF is a member of the flawed "push clock" design paradigm. SPDIF output is fine since it doesn't really affect the DAC chip clock source, but SPDIF output should certainly not be a priority - just a convenient option.
I wouldn't say that it doesn't really matter how the clock is configured, because the clock is the most important aspect of the circuit affecting quality. There could be side-effects to certain clock configurations that cause quality to suffer.
Hi Borge et al,
I am still not clear what the advantages are to have an SPDIF interface on the AW.
You will not get better than 50ps jitter with SPDIF so if you really want good SQ you should stick to the clock at the DAC and forget about SPDIF.
If you have an existing DAC that only accepts SPDIF then u can buy a commercially available USB->SPDIF converter. Granted there may not be many that can use uac2 ti go up to 192khz but uac1 up to 96khz are plentiful.
If you really care about 192khz etc then why stick to SPDIF?
Alex
I am still not clear what the advantages are to have an SPDIF interface on the AW.
You will not get better than 50ps jitter with SPDIF so if you really want good SQ you should stick to the clock at the DAC and forget about SPDIF.
If you have an existing DAC that only accepts SPDIF then u can buy a commercially available USB->SPDIF converter. Granted there may not be many that can use uac2 ti go up to 192khz but uac1 up to 96khz are plentiful.
If you really care about 192khz etc then why stick to SPDIF?
Alex
I care about a high end usb->spdif converter since I demand that the dac and the digital feed to it be 2 separate (upgradable) boxes.
tying the dac to the usb stuff seems like a loss to me. to me, personally. others may want a 'usb dac' but all I ever wanted was a good way to send 16 thru 24 bits at 44 thru 192, out of my pc and into the dac of my choice.
at the dac end is where I care about low jitter. and that's where I see the critical issue.
it seems more 'mechanics' to me to be able to send out 192k with usb. it should all just be bits at that point and the 'assembly' of the bits at the dac is what is critical.
since I don't love the idea of i2s single-ended going external between boxes, spdif seems the way to go. as long as the data is cleaned up before the very final d/a stage, I see nothing wrong with spdif as a data transport. getting 192k from usb was always vendor-locked; until now
but the onboard dac is just a frill to me. the spdif out was what I wanted all along. and I doubt I'm alone in that need, but only time and sales will tell, I suppose.
tying the dac to the usb stuff seems like a loss to me. to me, personally. others may want a 'usb dac' but all I ever wanted was a good way to send 16 thru 24 bits at 44 thru 192, out of my pc and into the dac of my choice.
at the dac end is where I care about low jitter. and that's where I see the critical issue.
it seems more 'mechanics' to me to be able to send out 192k with usb. it should all just be bits at that point and the 'assembly' of the bits at the dac is what is critical.
since I don't love the idea of i2s single-ended going external between boxes, spdif seems the way to go. as long as the data is cleaned up before the very final d/a stage, I see nothing wrong with spdif as a data transport. getting 192k from usb was always vendor-locked; until now
but the onboard dac is just a frill to me. the spdif out was what I wanted all along. and I doubt I'm alone in that need, but only time and sales will tell, I suppose.
you just listed the point of it, to me!
I don't want another vendor-specific usb/spdif box that uses a closed source vendor driver. I'm sick and tired of vendor drivers! and good usb/spdif boxes that work at this rate are not cheap.
are there cheap usb/96k boxes that are NOT vendor-locked in the driver?
I'm getting friendlier with the WM8804. Should be able to tie together an sch in a day or two. HW-mode SPDIF TX only, with a copy of the 12MHz osc design at the MCU to keep it happy in HW-mode. HW reset controllable from MCU. SPDIF TX driven by our MCLK, not 12MHz osc.
Personally, I don't need SPDIF output. But I'm all for attracting more interest to our project.
Børge
Personally, I don't need SPDIF output. But I'm all for attracting more interest to our project.
Børge
There are usb/spdif converters based on TE7022 found in ebay which can do 24bit/96KHz like SMSL SD-022 DAC USB input /coaxial optical output /TE7022 24Bit 96K | eBay.
not much. To integrate a good USB input (the widget) with a good existing DAC, I2S output would be much more useful.
Having also an s/pdif out sometimes could come handy, but that's it. I'd add it only if it's easy & cheap to implement AND it does not compromise in any way the overall quality of the "main function" of the device (that is analog and/or I2S output from USB).
Eventually, in a more complete future design (larger, mains powered, etc) I would consider multiple optional s/pdif and Toslink inputs & outputs to allow the unit to be used as a single D/A source and "digital control box" in more complex audio & A/V systems (as I currently do with my multi-input DAC).
Basically, in the digital era that should replace what once used to be the analog preamp.
In any case, I would not ever bother too much about the quality in s/pdif mode. IMHO bare functionality is all that's required. S/PDIF is fatally flawed by design and will always produce lower quality. It just can't be an alternative for "top-SQ" audio use. Thus it should be meant only as a way to integrate (connect from/to) existing "mid-fi" devices (such as TV, DVB, DTS/DD decoders, etc) with a main audio system.
dacs change a LOT. people call it the 'dac of the month club' and this is one reason why i want to keep the dac and all that leads up to the dac, separate. in 6mos, perhaps, some killer new dac chip could be out. you won't be able to benefit from it if you embed the dac on the 'transport' board. otoh, by giving spdif you now open the door for people to use ANY dac they want.
there are some very nice discrete output stage dacs (whole systems) that this system will never be able to compete with. why even try? export spdif and let the user take it from there.
anyway, there's good use for both and at least the spdif export function won't cost an ARM and a leg; not even an arduino and a leg
there are some very nice discrete output stage dacs (whole systems) that this system will never be able to compete with. why even try? export spdif and let the user take it from there.
anyway, there's good use for both and at least the spdif export function won't cost an ARM and a leg; not even an arduino and a leg
I'm not fond of the push-clock paradigm, but see the wish for flexibility.
It'll be fairly easy to add a CAT5 connector to the AB-1.12 prototype board. But like SPDIF I don't own any mating equipment. So if this is a feature you wish to play with, feel free to suggest a pinout.
I know there are a couple of them out there, so make your pick and we'll turn it into the I2S-Widget Standard CAT5 Connector (r) (c) (whatever).
Børge
It'll be fairly easy to add a CAT5 connector to the AB-1.12 prototype board. But like SPDIF I don't own any mating equipment. So if this is a feature you wish to play with, feel free to suggest a pinout.
I know there are a couple of them out there, so make your pick and we'll turn it into the I2S-Widget Standard CAT5 Connector (r) (c) (whatever).
Børge
update on the cirrus transmitter chip problem I had. I took my test board over to demian's place and we looked at things together (amb/ti kan was there, too, with us). my initial build had the voltage out of the spdif port being a tiny bit low. we had an apogee on the bench to test our signal with (it has handy leds to show the actual samplerate and that was a nice bit of test gear, just on its own). after we increased the voltage out a bit (changed a series resistor) we got lock-on; but we found that it showed 88 when we were putting a 44 signal in (or vice versa; I forget the details). we tried various input samplerates and the leds didn't match what we should have seen. we got 44.1 to lock on, once, correctly, but the others were all wrong. I rewired the clock programming pins (2 of them) and we tried again. we got other samplerates to lock on, but then lost 44.1. we tried 2 or 3 times, I think, and didn't get all SRs to be working. via hardware mode, it didn't seem obvious that we could get the existing i2s lines to 'just plain work' on the cirrus chip.
we switched back to the wolfson and re-ran our tests. each time demian played a new data file, the leds on the apogee agreed with what the source file was at. we found that the hardware mode of the wolfson 'just plain works'. the output jitter was also pretty low, visually, at least. this was on the informal frankenstein build that I glued to the base of the audio widget I paid no attention to proper wiring and kind of wanted to see how bad a 'bad build' would end up testing. it tested ok, I think. I'm not a jitter expert, but it appeared that its spectrum curve was quite acceptable.
we switched back to the wolfson and re-ran our tests. each time demian played a new data file, the leds on the apogee agreed with what the source file was at. we found that the hardware mode of the wolfson 'just plain works'. the output jitter was also pretty low, visually, at least. this was on the informal frankenstein build that I glued to the base of the audio widget
I paid no attention to proper wiring and kind of wanted to see how bad a 'bad build' would end up testing. it tested ok, I think. I'm not a jitter expert, but it appeared that its spectrum curve was quite acceptable.
my actual use-case: my speaker system is all digital up until the very final stages (behringer deq-2496, dcx-2496). I really love the fact that I can send aes3 or opto into my deq, do math on the data, send it OUT via aes3 to my dcx crossover, continue to do math on it, split it into 3 bands, then run those thru 3 dacs and onto your vol control and amps.
I need spdif. sorry, but its not practical to open that damned behringer and make it an i2s input device. going to an analog-in is a step backwards (it would just use its local a/d, which may not be the best one I would have around) and so the only digital audio import I have that is worth anything is good old spdif.
for this use-case, you can see that having a local dac chip on the audio widget is 100% useless to me. its great for demo'ing the board, but in operation, it will be a usb-in and spdif-out device.
finally, the core of my selector switch is spdif. I have many spdif audio sources and I need to select from them. they all deserve (lol) to benefit from the same dac. if you embed your 'good dac' into a usb device, its now private and no other digital source or transport can make use of it. by having the data sources all speak spdif, then you select them via an 'easy' spdif switch, THEN reclock, then feed to a dac, this gives much more system flexibility and i/o routing.
1. It will be instructive to see a measurement of the J-test of an AW->SPDIF>DAC.
2. I can now see the value proposition of the AW->SPDIF :
(a) 176/192 capable
(b) uac2 compliant - native support under Linux and OSX and open source Windows ASIO uac2 driver availability.
And add to that:
(c) also super low jitter analog out with 32 bit PCM5102
(d) also remote I2S out with MCLK out with CAT5
(e) also footprint for ES9012
At a reasonable DIY price !!!
Alex
2. I can now see the value proposition of the AW->SPDIF :
(a) 176/192 capable
(b) uac2 compliant - native support under Linux and OSX and open source Windows ASIO uac2 driver availability.
And add to that:
(c) also super low jitter analog out with 32 bit PCM5102
(d) also remote I2S out with MCLK out with CAT5
(e) also footprint for ES9012
At a reasonable DIY price !!!
Alex