Hi,
About the gui I agree with George, it does not need to be so complicated.
Moreover it can evolve.
So the first step, a simple gui which interpret a config file, which is basically a model representing the parameters of the dac and an expression of the associated gui (text, integer, combo box with enum values).
Then it can be easily extended with some validator which again based on contstraints expressed in the config file validate the current setup before submitting to the usb controller.
For example, I can do it based on the groovy language, which is a simplification of java. I can make a dsl (domain specific language) to express this config file. Then you can express easily any conditions, processing in simple code in the constraints part of the config file.
That part I am really confident with it.
About the gui I agree with George, it does not need to be so complicated.
Moreover it can evolve.
So the first step, a simple gui which interpret a config file, which is basically a model representing the parameters of the dac and an expression of the associated gui (text, integer, combo box with enum values).
Then it can be easily extended with some validator which again based on contstraints expressed in the config file validate the current setup before submitting to the usb controller.
For example, I can do it based on the groovy language, which is a simplification of java. I can make a dsl (domain specific language) to express this config file. Then you can express easily any conditions, processing in simple code in the constraints part of the config file.
That part I am really confident with it.
I have not read that other people had it working without firmware updates, but by adding an USB interface that talks to the PCI bus.
Did you also do that?
If so, how?
Hugs,
Sandra
Audio Widget GUI
I may be confused here but I think the GUI is meant to be a GUI on the Host PC platform. A local GUI can be supported through the local display if implemented. And with it local and hardware specific, it can be part of the specific firmware with no USB interactivity. In many ways this makes more sense. Filter and output selection being local to the hardware will fit how most people use the boxes.
If its something accessed through USB I would caution that the project is potentially much larger that it seems. USB audio is expanding in use and we can expect to see UAC2 on 6(?) platforms soon: OSX, Linux, Windows (Windows 8?), Android, IOS and Windows Mobile. UAC1 has a mechanism for volume control at the device. Since its standardized it is commonly supported on the platforms supporting UAC1. Alex informed me that UAC2 does not have this mechanism. (I hope I got that right.) That means volume control would require drivers on everything. I would expect this to change over time but for now it means custom drivers for each platform, something this effort is trying to get away from.
Adding other device specific features gets far more complex. Looking through the driver implementations in ALSA can give some perspective on the issue. There are even conflicts over presentation of volume control adjustments since not all devices (or developers!) think in dB. Adding filter options, sample rate conversion options or who knows what makes support quite a handful.
I may be confused here but I think the GUI is meant to be a GUI on the Host PC platform. A local GUI can be supported through the local display if implemented. And with it local and hardware specific, it can be part of the specific firmware with no USB interactivity. In many ways this makes more sense. Filter and output selection being local to the hardware will fit how most people use the boxes.
If its something accessed through USB I would caution that the project is potentially much larger that it seems. USB audio is expanding in use and we can expect to see UAC2 on 6(?) platforms soon: OSX, Linux, Windows (Windows 8?), Android, IOS and Windows Mobile. UAC1 has a mechanism for volume control at the device. Since its standardized it is commonly supported on the platforms supporting UAC1. Alex informed me that UAC2 does not have this mechanism. (I hope I got that right.) That means volume control would require drivers on everything. I would expect this to change over time but for now it means custom drivers for each platform, something this effort is trying to get away from.
Adding other device specific features gets far more complex. Looking through the driver implementations in ALSA can give some perspective on the issue. There are even conflicts over presentation of volume control adjustments since not all devices (or developers!) think in dB. Adding filter options, sample rate conversion options or who knows what makes support quite a handful.
It looks like A.Ciuffoli is making some comparison between the Audio Widget and the m2tech solution: http://www.diyaudio.com/forums/digi...chronous-usb-i2s-interface-7.html#post2868704 post #310
Is there such thing as an recommended 'official' upgrade path for the widget? Like, decouple the usb-signal and make a dedicated, linear psu, insert a tent clock, make a discrete analogue output stage and stuff like that?
We made a dac shootout last weekend with a weiss dac and something from lake people (among others) and, well, I'd say the widget spares room for further improvement...
Rüdiger
We made a dac shootout last weekend with a weiss dac and something from lake people (among others) and, well, I'd say the widget spares room for further improvement...
Rüdiger
AFAIK not quite, only reports from various experimenters.
Some small improvements over the standard version are definitely possible, but I'm afraid not much more than that. As long as it will use cheap DACs with low-voltage, single-rail power supply and internal I/V (such as the ES9023), I see no hope to approach the SQ level of the best commercial (or DIY) DACs. Given its intrinsic limits, AB1.1 is sounding even too well as it is...
Anyway, to improve existing (ES9023-based) widgets, apart from the already recommended caps and regulators replacement (and better yet external PSU too), something to try is to replace the clocks with new ones that not only have the lowest possible jitter / phase noise, but also are 2x or 4x the frequency of the current ones (you'll need to adjust the divider to keep providing the right clock freq. to the uC).
This is because of the peculiar way Sabre DACs (including the 9023) works. They do not work well with "slow" clocks: the higher the clock, the better they works - and sounds (in async mode many use clocks >=100MHz...).
no doubt...We made a dac shootout last weekend with a weiss dac and something from lake people (among others) and, well, I'd say the widget spares room for further improvement...
Unfortunately, to really move on to the next level and be able to compete with such beasts does require much more than just some tweaks on the current design.
You (WE) would need a completely new AB based on much better DAC(s), with several independent mains powered PSUs, etc.
Last edited:
indeed.Well, this is what the AB-1.12 is about. With it we (you
BTW: as said, from other people experiences, using ESS "Sabre" DACs with clock(s) at the frequencies currently used by the widget is highly detrimental to their performances and SQ.
Using the expensive top-end ones with "slow" clocks would simply make no sense. People willing to try the ES9012/9018 on the AB1.12 must definitely use higher freq. clocks.
It would be very useful to try to identify and list here suitable clocks (at 2x and/or 4x the frequency of the ones currently used on the AB1.1) which can be used on AB1.x boards with ES9012/9018 or ES9023 DAC (among other things with "suitable" I mean available, low jitter, low phase noise, reasonably priced and possibly pin-compatible with the current ones).
It would also be nice to add detailed instructions on how to modify the widget (clock divider) to use such clocks.
Last edited:
Thanks, Unixman.
Yes, I love the widget for its easyness and quality and its many positive design decisions. And now, after a few month, I need more
I would appreciate that diskussion which features the new board should have and which options it should provide.
From what has been said here that might be:
1) higher clock rate(s)
2) easy implementation to psu upgrades
3) usb decoupling (there were debates whether this would worsen jitter performance, though)
4) tbc
Rüdiger
Yes, I love the widget for its easyness and quality and its many positive design decisions. And now, after a few month, I need more
I would appreciate that diskussion which features the new board should have and which options it should provide.
From what has been said here that might be:
1) higher clock rate(s)
2) easy implementation to psu upgrades
3) usb decoupling (there were debates whether this would worsen jitter performance, though)
4) tbc
Rüdiger
USB decoupling is not an option, there are currently no affordable practical solutions to do that for USB 2.0.
What can be done (Børge is already thinking about that) is to "decouple" the uC board from the AB, acting on the I2S lines from uC board to AB and the clock line from the AB to the uC (which IMHO is probably also better than acting on the USB).
Yes, after AB-1.12 the next prototype(s) could be an insulating go-between for the USB-I2S module.
I suggest optos on I2S (from module) and MCLK (to module). Note that this would require external power for the analog parts, and that IO functionality would be reduced to a minimum. Let me know if you have thoughts on this.
Børge
I suggest optos on I2S (from module) and MCLK (to module). Note that this would require external power for the analog parts, and that IO functionality would be reduced to a minimum. Let me know if you have thoughts on this.
Børge
Personally, I think soundquality should be the final arbiter, so i would live with some inconvenience and additional diy-efforts, but ymmv, of course.
Rüdiger
Today the module supports I2C, SPI, display, UART, GPIO, buttons etc. Forwarding all those through galvanic isolators would take up a lot of board area and possibly power.
I2S is obvious, as is the bare minimum of GPIO for DAC control. UART and display can be moved to the USB power domain.
Hm, this kind of go-between will take some thinking....
Børge
I2S is obvious, as is the bare minimum of GPIO for DAC control. UART and display can be moved to the USB power domain.
Hm, this kind of go-between will take some thinking....
Børge
I2S and I2C (SPI) need galvanic isolation.
The remaining can as you indicate be moved to the USB power domain or a separate power domain.
There can be put one galvanic isolation chip where the I/O are not connected - then the user can solder the chip if needed and connect the I/O to / for what he / she wants...
AB-1.12 Easer Egg
Hi guys,
inspired by Demian I have made two last-minute changes to the AB-1.12.
The first is to add synchronous binary counters to divide down MCLK from the XOs. Divisions from /2 to /256 are now available on SOIC packages. More relevant divisions are available on 100mil headers. These may find a role in synchronous power supplies, alternative XOs etc.
The other addition is the most significant one I decided to put in a whole 'nother prototype board, the AB-1.13. It is identical to the AB-1.12 except for the primary audio DAC being AKM's AK4430. Demian likes the sound of it. And I'm pretty happy with the way the layout turned out. This DAC has a charge pump like the PCM5102 and ES9023. But the pinout lends itself beautifully to star-gnd / star-power.
AB-1.12 and AB-1.13 will be sold as two naked boards in one bundle. One front plate and one back plate will also be part of it.
As it stands right now, the $50-60 price I guessed at first seems to stand. That price includes shipping and ONE of each of XOs at 22.5792 and 24.576MHz. It is easy to throw in TWO of each XOs, but that will jack up the price a little bit.
At the same time as I receive the AB-1.12/13 proto boards, I hope to also get a new batch of assembled+tested USB-I2S modules. I will open up for orders for those after I'm comfortable with the quality.
Cheers,
Børge
Hi guys,
inspired by Demian I have made two last-minute changes to the AB-1.12.
The first is to add synchronous binary counters to divide down MCLK from the XOs. Divisions from /2 to /256 are now available on SOIC packages. More relevant divisions are available on 100mil headers. These may find a role in synchronous power supplies, alternative XOs etc.
The other addition is the most significant one
I decided to put in a whole 'nother prototype board, the AB-1.13. It is identical to the AB-1.12 except for the primary audio DAC being AKM's AK4430. Demian likes the sound of it. And I'm pretty happy with the way the layout turned out. This DAC has a charge pump like the PCM5102 and ES9023. But the pinout lends itself beautifully to star-gnd / star-power.AB-1.12 and AB-1.13 will be sold as two naked boards in one bundle. One front plate and one back plate will also be part of it.
As it stands right now, the $50-60 price I guessed at first seems to stand. That price includes shipping and ONE of each of XOs at 22.5792 and 24.576MHz. It is easy to throw in TWO of each XOs, but that will jack up the price a little bit.
At the same time as I receive the AB-1.12/13 proto boards, I hope to also get a new batch of assembled+tested USB-I2S modules. I will open up for orders for those after I'm comfortable with the quality.
Cheers,
Børge
Last edited:
Isolation is nice but doing it well is not easy.
Passing I2C across a barrier may be harder since its bidirectional. The I2S is pretty straightforward, but the clocks should be on the isolated side so you need a tag line to communicate which clock to pass across the barrier (another opto). Transformer isolation of the clock and optos for everything else would be pretty simple. You do need the supply on the far side. You may need some software smarts in the widget to prevent lockup if the isolated side power is missing, meaning no master clock. I would use a latch in the isolated side for the data lines clock from the master clock to ensure they all will meet the appropriate setup times. If the DAC were on a separate pcb (better for isolation from the USB connected junk) I'm not sure where the isolation circuit should reside. Instinctively I would put it on the DAC board actually. That would keep the timing sensitive lines shortest.
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si840x.pdf is a one chip I2C isolator that may work. If so this whole thing could be pretty easy. I'll look at the other silabs isolatiors as an alternative to optos. The clock will need transformers. Should the divider live on the isolated side (nothing on that side actually needs it) or on the USB side? We can use a fast divider so the clock could be up to the 98.304 MHz needed for the ESS stuff. Transformers are easy.
Clearly this is not for a mobile application. I could use it to convert some of the DAC stuff I have to USB.
Would this cover all the requirements?
Passing I2C across a barrier may be harder since its bidirectional. The I2S is pretty straightforward, but the clocks should be on the isolated side so you need a tag line to communicate which clock to pass across the barrier (another opto). Transformer isolation of the clock and optos for everything else would be pretty simple. You do need the supply on the far side. You may need some software smarts in the widget to prevent lockup if the isolated side power is missing, meaning no master clock. I would use a latch in the isolated side for the data lines clock from the master clock to ensure they all will meet the appropriate setup times. If the DAC were on a separate pcb (better for isolation from the USB connected junk) I'm not sure where the isolation circuit should reside. Instinctively I would put it on the DAC board actually. That would keep the timing sensitive lines shortest.
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si840x.pdf is a one chip I2C isolator that may work. If so this whole thing could be pretty easy. I'll look at the other silabs isolatiors as an alternative to optos. The clock will need transformers. Should the divider live on the isolated side (nothing on that side actually needs it) or on the USB side? We can use a fast divider so the clock could be up to the 98.304 MHz needed for the ESS stuff. Transformers are easy.
Clearly this is not for a mobile application. I could use it to convert some of the DAC stuff I have to USB.
Would this cover all the requirements?