DAC chip test board

[Børge Strand-Bergesen]

Hi guys,

I'm thinking about putting together a test board to compare DAC chips. The whole thing will be open source and based on the Audio Widget code base.

Do you think it sounds like a good idea or not? Do you feel like teaming up to make this? If we're enough guys I can have them assembled.

The board will have the same MCU and clocks as the Audio Widget. The power supply will have breakouts to allow for batteries, lab powers, magic DIY regulators etc.

Initially, I thought about using these chips:

* AK4430 (to compare with today's AW that I sell)

* PCM1794 (current out, for the fun of it)

* ESS9038Q2M (unfortunately, the controls are not O.S., you'll need NDA to code it :-(( )

* CS4398

* AK4490EQ (The '97 is super expensive)

You probably have another few candidates. And that is before we speak about IVC and output drivers. I imagine adding straps for all sorts of creative activities in that area.

Cheers,
Børge

[Christian Viller]

Hi Borge,

That sounds like a great idea. How are you planning on integrating the various chips? All on the same board muxing them in via software or are you planning more of a hardware/selective soldering solution?

Christian

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.
To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[George Boudreau]

Borge,

The ESS chips are not that bad to work with.  Although covered by an NDA some have squeezed blood from the stone and created an Arduino driver for manipulating some of their chips.

https://hifiduino.wordpress.com/category/arduino-code/

https://hifiduino.wordpress.com/2014/06/30/es9018k2m-code-fully-tested/

Quite accurate and easy to port.

George

[Børge Strand-Bergesen]

Hi Christian,

I thought about putting all of them on one board and then use jumpers to be able to select one at the time. I2S, clocks and I2C can be shared so that all are able to play at the same time. This analog board can be made with an on-boad MCU or with the USB-I2S module that used to be in the AW some time back.

Some of these chips will be -hard- to solder without heavy equipment, so a ready-made board is probably the best, with plenty of DIY opportunity at the IVC and PSU sides of things. DAC chip decoupling will be tight with planty of QFNs and 0603s.

Børge

[Børge Strand-Bergesen]

Thanks George,

i did think about making it into an Arduino shield but the processing power is probaly not enough. Plus I don't want to start with a new code base.

The ES9038Q2M can do a few fancy things (which I can't tell you about, unfortunately), but if there are files for the '18 we can use without ticking off ESS I might as well throw in boht chips :-)

Børge

[Jaroslav Dohnal]

Hi guys,

I've already worked with ES9038Q2M, of course I'm under NDA, but maybe I can provide "some help" if needed :) It's a very good chip BTW. It can be used in master mode, so the AVR32 doesn't have to generate clock...which is much better for obvious reasons. 

CS4398...nope, its a trash, sorry. Use WM8741 instead (40 is also trash, 41 is much better, dual-die inside the chip for digital and analog). PCM1794 in external flter mode/NOS why not... 4490 is a very decent chip for the price. Its all about the implementation tho... Powersupplies and output stage. 

[Jaroslav Dohnal]

Also, what would be great is to get DSD working on AVR32, or move the project to SAM3U or something... 

[Alex Lee]

It will be a very interesting project Borges!

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

[Børge Strand-Bergesen]

Thanks guys,

Jaroslav, generating clocks on the AVR32 isn't really that much of a hassle, at least as long as we don't go above 192ksps. A port to another core makes sense in terms of cost and power supply. But porting the IO functionality scares the pants off me. With Microchip now owning Atmel obsolescence will hopefully be even further out.

Actually, I have been toying with one more thing which I wanted to throw onto the same board. I have worked with the WM8805 SPDIF receiver and hooked it up to the AVR32 I2S port used for the ADC in the original SDR Widget project. The purpose is to buffer audio data in the AVR32 and play it back on the clean XO MCLK. This far I have it working on 44.1. I have pretty much identified where in the code I need to reconfigure clocks in order to have all 6 sample rates from SPDIF supported, and at the same time have the AW present itself to the computer as a fully functional USB DAC. Obviously, the clocks slide. So eventually there has to be a clever sample skip/insert method too. This is my present software yoga project :-)

There's nothing stopping us from putting this as well on a DAC chip test board. The code base is pretty messed up now. I commit to local repo and will push when things look neat and the same code is verified to also work on stock AW.

DSD support: Great! I'm all for it. All the chips on the list except PCM1794 support DSD. Two of them also buffer DSD over the I2S interface. That probably saves us some clock meddling. I won't have the capacity to work with DSD for a long time. But if you decide to do, PLEASE keep me posted on where code changes go so that SPDIF buffering and DSD devel projects may run on the same code base.

Børge

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Ti Kan]

I'm all in favor of adding DSD support. In my mind this is the most
important item because everyone else has it now, and makes the audio widget
uncompetitive. More people are using the Amanero, for example. I am
still with audio widget because I like its fully open source aspect,
and hoping that DSD will happen sooner than later. DSD is not just
a fad of the month. It's here to stay, so we should put the effort into
making it work. I'll help in any way that I can, but I'm not an expert
in AVR32 programming by a long shot...

-Ti

[Børge Strand-Bergesen]

I haven't really studied the details of DSD playback. I assume that some USB descriptors must be rewritten, and that received data must be verified as DSD and then reformatted. Can anyone confirm this? Is there a need for DRM with DSD?

What is the driver situation for DSD? Recently, MS added UAC2 support and published a Win10 version locked to 44.1. It came right up and worked like a charm on a stock AW. I have no idea how DSD works with Windows drivers, or on other OSes for that matter.

Recently, I have also investigated MQA. Their decode is closed source. Any attempt to remind their people that permitting VHS rentals didn't kill movie theaters, has thus far failed. IMHO they should open the decode and only close the mix and distribution. But we're not yet there without a closed co-processor or entirely different USB controller. If our lives depended on it, MQA support might be "loaded" and not "linked" with the o.s. code to make it co-exist with GPL, but it's just too much hassle and beyond my C skills.

Børge

[Ti Kan]

I think DoP (DSD over PCM) would be the easiest solution. Have a look
at this article. It describes what needs to be done.

http://dsd-guide.com/dop-open-standard

On Windows, foobar2000 can already do this on the OS side of things
(with the right add-on components). The ASIO driver shouldn't care
because as far as it's concerned it's just passing PCM data. The
audio widget firmware needs to snoop the data to recognize it as
DSD rather than PCM, and to take appropriate action.

Most modern DAC chips have a "DSD enable" pin (or via software control)
to turn on DSD mode. Then the I2S lines are interpreted differently
than with PCM. For example, with the AK4399 DAC in DSD mode, the SCLK pin
becomes DSDCLK, LRCLK becomes DSD_RIGHT and SDATA becomes DSD_LEFT.
Other DACs are similar but with the DSD_LEFT and DSD_RIGHT reversed,
and WM8741 uses the LRCLK pin for DSD_LEFT and the OSR pin for DSD_RIGHT.

We just need to assign an unused I/O pin on the audio widget for
DSD mode control, and just send the DSDCLK, DSD_LEFT and DSD_RIGHT
data out the same wires as SCLK, LRCLK and SDATA, respectively,
and then let the DAC board provide the glue logic to make the proper
routing to a particular DAC.

-Ti

> > email to audio-widget...@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
>

> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

[Ti Kan]

On Sun, Nov 27, 2016 at 04:03:03AM -0800, Ti Kan wrote:
> On Windows, foobar2000 can already do this on the OS side of things
> (with the right add-on components).

Here is info about how to play DSD files on Windows with foobar2000:
http://www.psaudio.com/ps_how/how-to-play-dsd-files-on-foobar/

-Ti

[Børge Strand-Bergesen]

Hi Ti,

Synchronous DSD output will probably require serious reconfiguration of the PISO blocks currently responsible for PCM. Worst-case we add an external mux to rewire the interface. DoP looks much more promising and easy to implement but limits the selection of DACs (no CS4398 and no AK4490EQ).

I personally don't know these chips so it may not be a large loss over the AK4399. I haven't yet listened to any of them.

Børge

P.S. Any group members going to CES? We could meet for lunch one day.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Ti Kan]

AK4490EQ is just like AK4399 in that it uses SCLK for DSDCLK, LRCLK for
DSD_RIGHT and SDATA for DSD_LEFT when operating in DSD mode.
CS4398 has independent input pins for DSD mode. Both of these
can be handle DoP with some external logic.

I say we do DoP.

-Ti

> > email to audio-widget...@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
>

> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Sent from Main Mission

[Børge Strand-Bergesen]

Hi Ti,

The AKMs are a bit confusing. Scratching the surface I see:
- The AK4399EQ is being EOL'ed

- The AK4490EQ has a very good price and better THD+N spec than the AK4495EQ

- Neither AK4490 nor AK4495 seem to have DSD over PCM

I haven't dug deep into matters here, and I have certainly not listened to these DACs. Have you? On the surface the AK4490 seems quite attractive.

Børge
 

[Børge Strand-Bergesen]

Hi Ti,

Personally, I'd like to optimize PCM performance first and then take anything else as a bonus. Now, I'd like to avoid having to put things like CPLDs in to convert the DSD formats. In any case, this will be a test board with multiple DACs on it, so that we can evaluate many options.

As for the AK parts there shouldn't be a reason to include both the '90 and the '95? In their EOL notes they list the '90 as a replacement for old parts, not the '95.

Børge

[Ti Kan]

Hi Borge,

I think you misunderstand DoP.

The DAC doesn't have to "do DSD over PCM". It's done in the audio widget.
What the DAC will see is raw DSD data after being processed by the audio
widget. By the way, there is no conversion between DSD and PCM in this
scheme. All that's happening, is that on the player software, DSD data
is being wrapped in a PCM-like stream (not actual PCM), so that nothing
need to be done in the driver or transport interface (USB, etc). The
receiver (ie. audio widget) need to snoop the fake PCM stream, recognize
it as DSD and simply extract the raw DSD payload from this stream and
send it out. The audio widget I2S output pins can be used to transmit DSD
data. External glue logic redirects these to the appropriate DAC pins.

-Ti

> >> email to audio-widget...@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>

> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Børge Strand-Bergesen]

Gotcha!

Now, some DAC chips can receive DSD data on the I2S interface and not just the every-bit-counts synchronous interface which would require more glue logic or IO module ninja coding. The WM8742 has that.

So "DoP" can mean no extra drivers in the Host, and it can also mean no MCU-unfriendly interface. Good to know.

Børge

> >> email to audio-widget+unsubscribe@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Sent from Main Mission

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Jaroslav Dohnal]

We want to use DSD over PCM...definetely... There is no point doing native DSD as it needs driver support (and thesycon is the only one supporting it AFAIK). DSD header decoding is not that hard, have a look how XMOS is doing it...its actually very easy. The problem I see is different buffering. I suggest in DSD mode, that we configure SSC into 16 bit mode, send one DSD channel thru it and then we need to get SPI working in 16 bit synchronized to SCK to send another DSD channel over. That is the only way I know that can work. I just worry about the feedback and everthing... Can someone please explain in detail where exactly and with what is the feedback for UAC2 calculated? I've got the 384khz working, so we can have a platform that can run DoP/DSD128, which is PLENTY enough. Just native DSD64 is such a huge step from PCM...even with our own PCM digital filters we are using in ESS chips. 

CES...I was thinking about going there, I dont know how my colleague and I will be about time, so...but one more reason to go :)

I know you are worried about IO support on SAM3U or something...its just the price of this AVR32 is huge, but OK, its not that brutal. What is kinda showstopper for me in lot of designgs is the size of the chip, as its only available in TQFP144 and some BGA...and I don't like BGAs :D

> >> email to audio-widget...@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Sent from Main Mission

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

[Ti Kan]

Hi Jaroslav,

How well is 384KHz working? Is it stable with no artifacts or glitches?

-Ti

> > On Sun, Nov 27, 2016 at 10:45 PM, Ti Kan <t...@amb.org <javascript:>>

> >> > > On Sun, Nov 27, 2016 at 1:06 PM, Ti Kan <t...@amb.org <javascript:>>

> >> wrote:
> >> > >
> >> > >> On Sun, Nov 27, 2016 at 04:03:03AM -0800, Ti Kan wrote:
> >> > >> > On Windows, foobar2000 can already do this on the OS side of things
> >> > >> > (with the right add-on components).
> >> > >>
> >> > >> Here is info about how to play DSD files on Windows with foobar2000:
> >> > >> http://www.psaudio.com/ps_how/how-to-play-dsd-files-on-foobar/
> >> > >>
> >> > >> -Ti
> >> > >>
> >> > >> --
> >> > >> You received this message because you are subscribed to the Google
> >> Groups
> >> > >> "Audio-Widget" group.
> >> > >> To unsubscribe from this group and stop receiving emails from it,
> >> send an

> >> > >> email to audio-widget...@googlegroups.com <javascript:>.

> >> > >> For more options, visit https://groups.google.com/d/optout.
> >> > >>
> >> > >
> >> > >
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups "Audio-Widget" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send

> >> an email to audio-widget...@googlegroups.com <javascript:>.

> >> > For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >> Sent from Main Mission
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Audio-Widget" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to audio-widget...@googlegroups.com <javascript:>.

[Jaroslav Dohnal]

Without any problems at all. Under linux, mac and windows with thesycon...windows with Nikolays drivers is kinda...not working lets say, dont really know why. 

[Børge Strand-Bergesen]

It's cool that 384 works :-)

The feedback mechanism is not explained in just a few moments. Before we go there: Do you have an oscilloscope available? I have brought out some important sync signals on GPIO. With a scope it is easier to explain how things work.

Børge

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Ti Kan]

Indeed it's very cool!  If the win-widget ASIO driver doesn't work at 384k (or 352.8k) then it should be fixed.  I wonder if it's just something trivial.

-Ti
-- 

Sent from my commlock

[Børge Strand-Bergesen]

Nikolay's code is fairly straight-forward. It is easy to make a new .dll and copy it into the project. If we retouch the code and make a new installer, it should also support 64-bit drivers. I'm struggling with that because ASIO drivers don't follow the ordinary 32/64 bit divides in Windows.

Børge

[Ti Kan]

Borge, Ok, I might find some time to look at Nikolay's code and look for something obvious.

Jaroslav, I recall that you changed the clocking to remove the divide-by-2 (so that audio widget gets the full 24.576mhz or 22.5792mhz clock). Was there any other hardware change needed for 384k?  I think you also made some firmware changes, correct?  Are the firmware changes backward compatible with old hardware (with divide-by-2 in place)?  If so then maybe these changes should be pushed into the experimental branch. Or is it too premature? 

If the firmware isn't backward compatible with old hardware, maybe we could use a gpio pin to tell the widget whether it's getting a full speed clock or a divided-by-2 clock, make the firmware sense the logic of this pin, and auto-adapt?  I would like a single firmware code base and binary image to support old and new hardware.

-Ti
-- 

Sent from my commlock

[Børge Strand-Bergesen]

Nik's code can be built with a debug option and DebugViewer. I don't remember exactly which version of VisualStudio builds it. It used to be 2008 but I changed that to be able to build 64-bit binaries.

Ti, I agree with the clock divide comment. Running it without the external /2 means an internal /2 must probably be added. I'm going to put the clock division setup in a separate function to cater for the SPDIF buffering. Using a fixed GPIO is a good thing. 0603 pull-up/down with only one of them mounted is quite feasible. May I suggest re-allocating PA03, DAC_0N. This pin is brought out on the old module on TP15, and I haven't assigned it for any new crap I'm toying with. We probably won't need the internal DAC section of the MCU.

Børge

[Ti Kan]

Borge,

About DAC_0N (and other GPIO pins), do they have an internal pull up
or pull down? In yours and my current analog board implementations,
this pin is left to float. So if there is a pull up or down, we could
establish the default logic level as "with external divide-by-2", and
use the opposite logic for "use full clock speed".

This way, the widget will run with 192k max sampling rate on old
analog boards but can support 384k on new analog boards that sets
the DAC_0N pin to the appropriate level.

-Ti

[Børge Strand-Bergesen]

Hi Ti,

It looks like gpio_enable_pin_pull_up() is well defined in the software framework for the UC3A3. That means we can let float (= future fw pull-up) indicatehardware  /2 and GND (through 47-ish R for safety) indicate software /2.

Børge

> >>> an email to audio-widget+unsubscribe@googlegroups.com.

> >>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Audio-Widget" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to audio-widget+unsubscribe@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Audio-Widget" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to audio-widget+unsubscribe@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Audio-Widget" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to audio-widget+unsubscribe@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Audio-Widget" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to audio-widget+unsubscribe@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Ti Kan]

Great! Thanks Borge.

With Jaroslav's 384k stuff, we won't even need a software /2, right?

-Ti

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--

Sent from Main Mission

[Børge Strand-Bergesen]

.. doesn't matter, it is easy to put in and easy to work around in hw.

I'll put in an effort to test my latest code on stock AW and push to repo. I've been flying solo for a few months, so we may have to get a bit verbose on code mergers. Hope you can live with that. I really, really want to keep one code base for AWs. If need be we can finalize the fork from the SDR Widget code base. The two haven't really been compatible for a long tome.

Børge

> > > >>> an email to audio-widget+unsubscribe@googlegroups.com.

> > > >>> For more options, visit https://groups.google.com/d/optout.
> > > >>>
> > > >>
> > > >> --
> > > >> You received this message because you are subscribed to the Google
> > Groups
> > > >> "Audio-Widget" group.
> > > >> To unsubscribe from this group and stop receiving emails from it,
> > send an

> > > >> email to audio-widget+unsubscribe@googlegroups.com.

> > > >> For more options, visit https://groups.google.com/d/optout.
> > > >>
> > > >> --
> > > >> You received this message because you are subscribed to the Google
> > Groups
> > > >> "Audio-Widget" group.
> > > >> To unsubscribe from this group and stop receiving emails from it,
> > send an

> > > >> email to audio-widget+unsubscribe@googlegroups.com.

> > > >> For more options, visit https://groups.google.com/d/optout.
> > > >>
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Audio-Widget" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > an

> > > > email to audio-widget+unsubscribe@googlegroups.com.

> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Audio-Widget" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > an

> > > > email to audio-widget+unsubscribe@googlegroups.com.

> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups "Audio-Widget" group.
> > > To unsubscribe from this group and stop receiving emails from it, send

> > an email to audio-widget+unsubscribe@googlegroups.com.

> > > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Audio-Widget" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to audio-widget+unsubscribe@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Sent from Main Mission

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Ti Kan]

Yes, I agree that we should have one code base for all audio widgets.

-Ti
-- 

Sent from my commlock

[Jaroslav Dohnal]

Yes, I do have osciloscopes :) As I said, I'm HW guy...I don't really like SW :D 

AMB: yes, I removed the divide by two flip flop...I think there is no other HW change and the whole thing is backwards compatible. I added macros for defining if the external divider is used, e.g. what is the incoming masterclock...and then if you want to enable 384 kHz. Its all somewhere here on Google Groups. 

Also, how hard do you guys think would be to get two PCM data outputs, clock and latch? I want to use PCM1704 and some sigma-delta DACs in external filter mode...and now I'm using like five shift registers...which is not ideal. I whould be very similar to DSD at the end...so maybe we can start with that. 

[Ti Kan]

Hi Jaroslav, Borge, et. al,

On Wed, Nov 30, 2016 at 02:26:23AM -0800, Jaroslav Dohnal wrote:
> AMB: yes, I removed the divide by two flip flop...I think there is no other
> HW change and the whole thing is backwards compatible. I added macros for
> defining if the external divider is used, e.g. what is the incoming
> masterclock...and then if you want to enable 384 kHz. Its all somewhere
> here on Google Groups.

OK, I think I found where your code is:
https://github.com/dohnalik/sdr-widget-experimental-384

Looks like it's a fork from an older version of audio-widget firmware
without some of the changes Borge and I had subsequently added.
So in order to push that back in to the experimental branch,
we need to go through the changes and back-port them.

Do you guys want me to do this work? I can add the code to
make the /2 vs. not /2 GPIO pin detection done at startup time too.

> Also, how hard do you guys think would be to get two PCM data outputs,
> clock and latch? I want to use PCM1704 and some sigma-delta DACs in
> external filter mode...and now I'm using like five shift registers...which
> is not ideal. I whould be very similar to DSD at the end...so maybe we can
> start with that.

Maybe Borge or Alex could answer this. I'm not familiar enough
with AVR32 to know this.

At any rate, I found some old discussions about DSD, they are here:

https://groups.google.com/forum/?hl=en#!topic/audio-widget/PyjAU1Fmyhg

Go into the "Audio-widget now can do 384 kHz 32 bit" thread and
then search for "DSD". We had already talked about some of this
in the past. We should pick up the DSD discussion based on that.

-Ti

[Børge Strand-Bergesen]

Hi Guys,

I have a code base where I've been experimenting with SPDIF in on the ADC port. It has all my latest hacks. I'll check if it works on stock AW and then push it. I hope we can port things into that one. My hacks for non-stock-AW are wrapped in #ifdef HW_GEN_DIN10 and HW_GEN_DIN20, those are two Digital INput test boards I've been working on.

Here's what I have on my list:

- SPDIF buffering on ADC, includes wrapping pm_gc_setup() and friends in its own functions

- With time some really clever sample skip/insert method for incoming SPDIF

- Make *_buffer_* global and rename them with postfixes IN and OUT for the USB side and ADC and DAC for the I2S side

- Make reads of DMA *_buffer_* atomic so that there is no source of confusion as to where we are in the split ring buffers

I'll try to find time over the weekend to verify stock AW and then push. Maybe I'll even put in some of the easier changes.

With an oscilloscope you can monitor PX30 and PX33 to see which halves of the split ring buffer are being written to by the sequential USB OUT code and which are being read from by the real-time DMA DAC side. Very, very useful for feedback debug. Basically, you don't hack the feedback system without scoping those two.

Børge

[Børge Strand-Bergesen]

OK, the audio_widget_experimental branch now contains firmware which is functional on standard AW. I testet UAC1 and 2 on all sample rates on Win10. I hope this works for you as well and that we can use this as a starting point for the DSD and 384 stuff. I

If you have any questions about what is going on in the branch, let me know! Please, don't hesitate to ask if there is something that doesn't make sense or something important I may have overwritten. And please commit often. I may need a hand with git when we have more hands on the wheel. But I'm excited to work with you on 384 and DSD!

I haven't come very far on the list in my previous mail. The variable renames and atomic wrappers are probably what I'll do next.

The biggest changes are around the global variable input_select, its write-permit semaphore input_select_semphr and in the selective compilation decided by the definition of HW_GEN_* in Makefile. Search for those three things and you'll see the major areas where I've been coding lately. The schematics (and PSU in particular) for this stuff is still a giant mess. I will of course open source it, but for now the hardware is to fragile to be worth replicating.

Børge

[Børge Strand-Bergesen]

OK, so I had a productive evening :-) Found what was probably the bug that's been messing with my amplifier, and threw in the *_buffer_* renames and 1st attempt of RTOS-atomic read of DAC_buf_DMA_read. Functional code pushed to audio-widget-experimental.

Børge

Chg log:

spk_buffer_out ->
DAC_buf_DMA_read
Where does DMA read head fetch the DAC data

spk_buffer_in ->
DAC_buf_USB_OUT
Where does sequential USB write head put the DAC data

audio_buffer_out ->
ADC_buf_USB_IN
Where does sequential USB read head fetch the ADC data

audio_buffer_in ->
ADC_buf_DMA_write
Where does DMA write head put the ADC data

[Ti Kan]

Great work! I'll do some testing of the current experimental code
this weekend.

-Ti

> >>> an email to audio-widget...@googlegroups.com.

> >>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >>
> >>
> >
>

> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--

[Børge Strand-Bergesen]

Hi guys,

Ti, please keep us posted. I don't mind some verbosity here, as long as it reduces github mess-ups.

I have some boxes where I can try to omit the hw /2 and see what that does to the clocking scheme.

Crazy idea: do you think it is feasible to convert DSD to PCM in the AW firmware? I've done a fair share of sigma-delta modulator design and simulation in my earlier professional life, and believe it should be feasible. But could it possibly be any good?

Do you have a suggestion for some tracks and a Windows based playback method so that I could start joking around with this?

Børge

> >>> an email to audio-widget+unsubscribe@googlegroups.com.

> >>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >>
> >>
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Børge Strand-Bergesen]

I got a little inspired by Ti and Jaroslav and decided to put in support for selectable external /2. This paves the way for hw support for 384 and 352.8.

The code currently in the audio-widget-experimental branch looks at PA03 to see if it is pulled up by new fw or pulled down by external resistor (56R tested OK). The fw pull-up is backward compatible with unmodded stock AW hardware. New AW hardware which omits the external /2 must insert a GND resistor on PA03.

In new hardware we should check whether MCLK should be inverted or not on its way into the MCU. I don't want to give that precious signal a larger load than required, and I'd like to check which I2S phase is most friendly to the DAC chip.

I have tested the code in UAC1 and UAC2 at all common sample rates. The PA03 test takes place in the new function mobo_clock_division() which now holds all calls to pm_gc_setup() involving the outgoing DAC I2S clock.

This is convenient since the wm8805 frequency detect code will also call this function once the SPDIF buffering via ADC I2S port starts to take shape. That in terms means that mobo_clock_division() must also be called every time USB playback resumes in the HW_GEN_DIN10 and 20 boards I work on. For that purpose I tend to give current_freq.frequency a USB-centric name. (More of a note to self, that was.)

Another "convenience" is that all numerical sample rate references are replaced by "FREQ_44", "FREQ_48" and so on. There are not yet any defined controls for 352.8 and 384ksps. But that should be easy to put in following the same pattern.

Børge

[Ti Kan]

Wow, Borge! :)
I'll pull the latest code and test it this weekend.

-Ti

> >> > >>> an email to audio-widget...@googlegroups.com.

> >> > >>> For more options, visit https://groups.google.com/d/optout.
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups "Audio-Widget" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send

> >> an email to audio-widget...@googlegroups.com.

> >> > For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Audio-Widget" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to audio-widget...@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

[Børge Strand-Bergesen]

Hi guys,

Progress is slow but tangible on the DAC test board. AK4490 is on its way in. This IC has boht DSD and external oversampler interface. I'm thinking about using the latter for NOS operation. But both ext and dsd use two data bits, one for L and one for R. Do you know if this can be done on AVR32 hardware? If not a small CPLD should be able to convert from I2S.

A little while ago I made some code changes with atomic buffer accesses. That actually made the feedback system less stable. So I took it out. But I replaced that by a double read of DAC_buf_USB_OUT, with a single read of "spk_pdca_channel->tcr" in between. These variables are written to by interrupts and DMA hardware. So the sequential RTOS code can risk ending up with an old version of one and a new version of the other. Think of DAC_buf_USB_OUT as the MSB and tcr as the less significant bits of what is essentially one counter, and you'll understand how important it is to read the two in one step.

The verification seems to be gentler on the system than disabling and re-enabling interrupts. If both copies of DAC_buf_USB_OUT are equal, that qualifies it and spk_pdca_channel->tcr which was read in the middle. If they differ (which actually happens now and then), that particular gap calculation is discarded.

The newest code is in github and seems to be quite stable on stock AW. I have mainly tested UAC2/44.1.

This stuff has been running stable for some time. The reason I'm changing variable names and tweaking the buffer indexes, is that I will try to use the buffer toggle mechanism to determine timing mismatches in SPDIF buffering. For the same reason buffer lengths are now 2^n long.

Next I'll build for the digital input hardware with WM8805 and try to get some more progress on data buffering.

Børge

> >> > >>> an email to audio-widget+unsubscribe@googlegroups.com.

> >> > >>> For more options, visit https://groups.google.com/d/optout.
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups "Audio-Widget" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send

> >> an email to audio-widget+unsubscribe@googlegroups.com.

> >> > For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Audio-Widget" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to audio-widget+unsubscribe@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Jaroslav Dohnal]

Hi, I think SSC perifery can be multiplexed with SPI, so you can use that for DSDL...and then DSDR I would connect to another SPI and MUX it with LRCK. Thats the only way I can imagine DSD working on AVR32. CPLD is obviously easy workaround...but then for most people unusable, unless we find a way to upload bitmap to it from the AVR32. People usually dont have JTAG for altera/xilinx and I really like the integrated USB bootloader for DIY community.  

> >> > >>> an email to audio-widget...@googlegroups.com.

> >> > >>> For more options, visit https://groups.google.com/d/optout.
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups "Audio-Widget" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send

> >> an email to audio-widget...@googlegroups.com.

> >> > For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Audio-Widget" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to audio-widget...@googlegroups.com.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

[Jaroslav Dohnal]

Or maybe you can just configure to SSC into 16 bit mode and us it for left DSD and then for the right one use SPI and hope the synchronization wont go to shit on the SPI. 

[Ti Kan]

Can this be experimented easily?  I think no added CPLD, and no other changes to the widget hardware should be a goal.  The only added hardware would be on the "analog board" (in Børge's terminology), simple logic to steer the DSD lines to the appropriate DAC pins.

-Ti

-- 

Sent from my commlock

[Børge Strand-Bergesen]

Ti and Jaroslav,

I was hoping for the same thing. While CPLDs can be configured from the AVR32 at bootup, it's still a hassle to maintain another code base and tool chain. (And chip cost and assembly etc. etc.)

DSD has a lot in common with the formats used for interpolator bypass in some DAC chips. I'm working on the AK4490 now, and it has a bypass which also uses separate data for L and R.

Ideally, we only have external MUX, although I wouldn't consider it a huge loss if a couple flip-flops went in as well, so that we multiplex the LR bits, not the LR words coming out of the MCU. Then again splitting up samples that way will require quite a bit of shifting. If that doesn't work, then 32-ish flip-flops is something I'd consider a bit sad, and I'd rather opt for a CPLD.

I'm not enough of an AVR32 ninja to say if such a use of the SSC can be done.

Børge

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.