at least the wolfson works in hardware mode on TRANSMIT.
I'm finding out, today, that on RECEIVE, it won't work at 176.4k ;( locks on and plays at 192k but not 176.4. it seems that it is ONLY in software mode, as a receiver, for that rate. bummer!
but as a transmitter or spdif exporter, I think all SRs are supported.
I'm just bummed that on the decode side, I have to do software mode. have to; if I want 176k support. damn. wolfson, you were SO close... ;(
I'm finding out, today, that on RECEIVE, it won't work at 176.4k ;( locks on and plays at 192k but not 176.4. it seems that it is ONLY in software mode, as a receiver, for that rate. bummer!
but as a transmitter or spdif exporter, I think all SRs are supported.
I'm just bummed that on the decode side, I have to do software mode. have to; if I want 176k support. damn. wolfson, you were SO close... ;(
We're only going to use it for transmit. No way I will insert MCLK MUXes. The stray capacitance and extra routing will cause too much damage beteen XOs and DAC.
I agree about 176.4. Although it isn't very frequently used, it makes the table complete / dots all the i's etc. I have seen others who also downprioritize it. So I'm glad we don't!
Børge
I agree about 176.4. Although it isn't very frequently used, it makes the table complete / dots all the i's etc. I have seen others who also downprioritize it. So I'm glad we don't!
Børge
do remember that 176.4 pcm is being used as the defacto standard container for DSD over USB
I can understand the desire for a "do everything" device, but adding a spdif input to the AW seemed to me to be bypassing the value the AW brings to start with (UAC 2.0 USB connectivity)
I wasn't at all suggesting an spdif input to the AW.
I'm working on a project of my own (which is why I'm messing around with tx and rx spdif parts). for mine, I need to be able to receive and send spdif and at all rates. I thought I could get by with a receiver in hardware-mode but I learned that to get 176.4 on the 8804, it must be via a crazy software song and dance ;(
but to be clear, that comment was not meant to be directly related to the AW. this only needs spdif TX. and TX on the 8804 in hw-mode works just fine at all rates. seems to, so far, in what I've seen in my own testing.
hope that clears that up. no spdif receive needed in the AW
I'm working on a project of my own (which is why I'm messing around with tx and rx spdif parts). for mine, I need to be able to receive and send spdif and at all rates. I thought I could get by with a receiver in hardware-mode but I learned that to get 176.4 on the 8804, it must be via a crazy software song and dance ;(
but to be clear, that comment was not meant to be directly related to the AW. this only needs spdif TX. and TX on the 8804 in hw-mode works just fine at all rates. seems to, so far, in what I've seen in my own testing.
hope that clears that up. no spdif receive needed in the AW
in fact, my project is an spdif switch and I'd hate to see the AW compete with me, lol.
my simple little world view is that audio goes over spdif *when between boxes*. I simply want to migrate away from using line-outs to select which box I listen to or record; and use spdif as the audio transport, inter-box. that's why spdif switching or i/o selecting is so interesting to me. taking the analog interconnect and all it involves, out of the loop.
I know its a hot topic how 'bad' spdif is and whether you can fully clean-up audio data once its passed thru the spdif coding phase. but that's kind of a fight I don't want to fight; the reality is that boxes speak analog and spdif-out - and I'll usually prefer to pick the spdif-out if I have a choice. so much else is simpler when you defer the final conversion to analog, once, and in one box. spend all your dac magic and dejittering money there in that one box and let every source get its benefit. but to do that, you need to have spdif selection and it has to be done well. that's a space I'm trying to fill, with my own box.
my simple little world view is that audio goes over spdif *when between boxes*. I simply want to migrate away from using line-outs to select which box I listen to or record; and use spdif as the audio transport, inter-box. that's why spdif switching or i/o selecting is so interesting to me. taking the analog interconnect and all it involves, out of the loop.
I know its a hot topic how 'bad' spdif is and whether you can fully clean-up audio data once its passed thru the spdif coding phase. but that's kind of a fight I don't want to fight; the reality is that boxes speak analog and spdif-out - and I'll usually prefer to pick the spdif-out if I have a choice. so much else is simpler when you defer the final conversion to analog, once, and in one box. spend all your dac magic and dejittering money there in that one box and let every source get its benefit. but to do that, you need to have spdif selection and it has to be done well. that's a space I'm trying to fill, with my own box.
Hi guys,
here is an updated AB-1.12 schematic. As you see, WM8804 is now in. Any comments on the HW setup? I've added an optional reset by MCU. The output is trafo coupled. The WM sees a DC load while the AC coupling cap does not see a purely inductive load.
For CAT5 output I plan to use something like:
- Digi-Key - CAT5 con
- 74125 permanently enabled, NO D-flip-flop clocked by MCLK, 3.3V
- Header to patch from driver to connector
For the power I have changed the transistors to SOT223 packages MMBT4403 and MMBT3904. Available at DigiKey and capable of burning a bit more power.
Børge
here is an updated AB-1.12 schematic. As you see, WM8804 is now in. Any comments on the HW setup? I've added an optional reset by MCU. The output is trafo coupled. The WM sees a DC load while the AC coupling cap does not see a purely inductive load.
For CAT5 output I plan to use something like:
- Digi-Key - CAT5 con
- 74125 permanently enabled, NO D-flip-flop clocked by MCLK, 3.3V
- Header to patch from driver to connector
For the power I have changed the transistors to SOT223 packages MMBT4403 and MMBT3904. Available at DigiKey and capable of burning a bit more power.
Børge
Attachments
I've been a Nakamichi warranty servicer for decades, and love Nak gear in general, but will say that the MB100 was such a disastrously BAD design that the only good use for it is as a parts donor, such as to get a YM3436 digital input receiver chip out of it to fix a Monarchy 18B dac, which is exactly what I did two days ago with the MB100 that had been sitting on a shelf broken for the last year. Very handy, since those chips are impossible to get for less than 70euro anywhere. Even if you just wanted to use the dac unit of the MB100, it is so poorly laid out that there is NO hope of making it much better than it is.
If Linuxworks and I can get together this week I'll get jitter measurements of several different options I have and post them.
From the work I have done so far its clear execution is far more important than technology. The AB1.1 is very good actually. I think its limited by the ESS dac in it.
One of the best DAC's available uses an external USB to AES adapter as its preferred source (Berkeley Audio Alpha DAC).
From the work I have done so far its clear execution is far more important than technology. The AB1.1 is very good actually. I think its limited by the ESS dac in it.
One of the best DAC's available uses an external USB to AES adapter as its preferred source (Berkeley Audio Alpha DAC).
Agreed about the ESS, but the Berkley is special due to the proprietary DSP code in front of its AD1955. There is a common theme among true top level converters, used to be sectret OS/filtering algorimth FPGA + BB1704, now its secrete OS/Filtering algorithm AD Sharc + AD1955 that you find on high level products.
I still think good complement to this project would be a WM8804-WM8471 software controlled. With software control you can effectively choose from 5 filters x 3 rates (1x,2x,3x) and 3 noise shapes. Plus with the wm8804 in software you could have a 4x via computer with a filter like the Izotope 64bit SRC that is highly customizable. And the are other open source options.
A natural extension of the widget project is moving the entire digital "front end" of a DAC to the computer with the widget as the interface with high sample rate/flexibility as the AD Sharc's have as well as the flexible format conversion for compatibility with all DAC's from the TDA1541 to the PCM56/AD1865, to the PCM1704 as well as the new 32bit input DAC chips.
This would level the playing field for the hobbiest and allow the individual to build a converter he wants; be it NOS, apodising oversampling, dynamic filtering, possibilities are endless once the classic digital filter is moved to the computer.
I know nothing about their digital 'secret sauce' but it wouldn't be fair to attribute the whole of the success of this design to DSP. The layout also is worth studying carefully - note that they don't follow the traditional grounding approach of a single (sometimes partitioned) groundplane and take mains noise seriously through avoiding the fashionable choice of toroidal trafos.
Last edited:
Agreed 100%, but we diyers tend to dismiss proporetary digital oversampling/filtering algorithms as marketing but having heard the works of these guys from the PM1 to the Berkley and other good digital I believe a big part of good sound is the DSP. I mean to say we can all do layouts and pcb design. But there really is only a small group of folks who can program a sharc processor and even a smaller group who can program good filtering, and a smaller group who know good sound and have the above skills.
Move that to the computer with adjustemts , make a filter switch to a different impulse response prior to a quick dynamic, etc. Lot of creative things happen with open-source PC work. Lets face it a room with walls filled with CD's is just not practical, our music is moving to our PC's, so why not move the digital half of converters with it.
Wouldn't it be nice to hook up a TDA1545 DAC to a usb port without any glue logic, how about a PCM58k? Or a pair of AD1865K's, no glue logic needed, just select from a dropdown menu on your PC for the desired format.
Well I'm one of the skeptical DIYers - the temptation to inflate the prowess of one's proprietary algorithms (knowing their precise nature is going to stay hidden) is just too great for many marketing people. I've read plenty of too-good-to-be true claims for such efforts.
When you heard the Berkeley, how did you figure out how much of its sound was down to DSP and how much to layout?
I'd say its not so clear cut a distinction - while I see plenty of layouts and pcb designs, I see very, very few with the attention to detail evinced in that Berkeley DAC. I reckon that good layout skills are as scarce as good DSP skills.
I'd just like to point out that tablets have USB ports too
They tend to make better sources because they're lower power and generally have lower clock frequencies. Therefore they produce less digital hash. Hooking a DAC directly up to PC-sourced USB (without requisite filtering and/or isolation) sounds to me to be a recipe for distinctly mediocre sound.If you have a good digital audio recording that has been properly mastered, I do not see any way for DSP to improve upon that. DSP has its place when you want to modify the sound, but if you just want to reproduce the audio that is already there then DSP should really be skipped. If the DAC really needs DSP to sound good, then you probably should consider a different DAC.
I will agree with abraxalito on this topic. Not everybody can do layouts and PCB design properly. I've seen all kinds of horrible layouts for USB, and that's just the digital side where only a few considerations affect quality. On the analog side there is even more room for poor quality.
It is a very small group indeed who understand good sound and good layout and PCB design. I have talked to circuit engineers from major audio companies who admitted that they designed and released several products before they really understood how important the DAC clock traces were. No offense to DIY, but I really doubt that all DIY folks are better than professionally employed circuit engineers.
You should spend some time studying DSP. You would quickly learn that you cannot switch the impulse response of a filter in the middle of an audio stream without creating tons of aliasing and other artifacts that are totally wrong. If you have a magic impulse response, then it needs to be in place for the duration of your listening without any switching, unless you're willing to have a few samples of silence to clear out the prior impulse response.
It is impossible to connect a USB port with a DAC without glue logic. USB is a completely different protocol than I2S or any other DAC format. USB has tons of jitter in the clocks, and lots of non-audio data. Meanwhile, the DAC requires a perfect clock and pure audio data. By definition, glue logic is required 100% of the time to translate between USB and DAC control signals. If you have an MCU that handles both USB I/O and I2S I/O, then you can make the necessary connection complete with clock feedback to remove the USB jitter from the equation, and you might even be able to connect the MCU and DAC without additional glue logic. However, it's incorrect to talk about connecting a USB port and DAC without glue logic, because technically the MCU acts as an incredibly complex glue logic between the raw USB port and the DAC.