Request For Comment :: Audio-Widget 2.0 and software

[George Boudreau]

Borge Strand-Bergesen, Ti Kan, Jaroslav Dohnai, et al

I am throwing out a 'Request For Comment' on the future direction of the audio-widget hardware and code base.  I look at my files and I see original files dated 2009/2010. As everyone knows the audio-widget was a re-imagining of the hardware of the Amateur Radio SDR-Widget hardware I produced.  I stripped all the I/O and the ADC hardware from the design and created a platform that focused strictly on audio output. The original audio-widget card had the ESS ES9023 chip and then moved to the TI PCM5102 DAC.  I sold a number of DIY solder kits using both chips  The idea was to spur others to use the AT32UC3A3 USB audio engine a base for their designs. The hope was there would be enough interest from others that a Windows UAC2 driver might be written. An ASIO driver was created but that was as far as Windows support went. Borge Strand-Bergesen was the first to embrace the hardware and he eventually released a commercial product based on the Audio-Widget core.

From the code side the Auudio-Widget was a 'crippled' SDR-Widget. Some feature were disabled at compile time while others were set during runtime configuration.  The is done to take advantage of the evolving SDR-Widget code. Any improvements in the SDR-Widget audio change were available to the Audio-Widget with minimal effort.  While this was acceptable in the early days it has left a legacy support problem.  The 'experiment branch' of the widget code forked from the original SDR-Widget code base and focuses strictly on the audio chain yet there is still old radio control software in this branch. This makes life for the software maintainer a nightmare and needs to be changed.

I am proposing an 'Audio-Widget 2.0' hardware platform and a software tree that only supports the hardware as a USB audio engine driving DAC and/or ADC components with no backward compatibility with the older hardware.  I am soliciting ideas from the group as to what features you wish supported. Any idea that can be supported by the chip will be considered. Justification should accompany all ideas and if you have a solution to go with your suggestion you get bonus points.

The existing software is a dogs breakfast since there was no specification in the and the functionality evolved with minimal direction. I propose another fork of the existing code base that will support only those functions needed to support an audio controller and strip away all unnecessary radio focused code. A cleaner code base will allow for easier maintenance and feature enhancements.

Long winded explanation ended, now the formal requests for input. Some will seem obvious but better stated than forgotten.

HARDWARE:: What hardware features do you require

::Required::

• USB : UAC1 & UAC2  *** A 4-layer board: Yes, this should be used. I got lucky with the original SDR-Widget and Audio-Widgets by using a 2-layer board and short runs.  The PCB should have controlled impedance to support the full 480mbps.  Cost is greater but that is life.
• MCLK : support - div 2 and div 1 frequency select
• I2S : Out  ( DAC )
• I2S : In  ( ADC )
• I2C : Master for device control.
• SPI : Master with 1 or more CS lines for ???

::Nice to have:::

• S/PDIF :  Chip specific implementation. Who choses chip but if the pins are defined for input then all is possible.
  
• SPI : Slave (if possible)
• USART : Future functionality
  
• GPIO : hardware support for what???
• JTAG : How many people actually have a JTAG debugger for the AVR series

::Won't support::

• 4-bit parrallel LCD  (use SPI display is you want visual output)

::SOFTWARE:  Once stripped of all radio control functions what is left should be

::Required::

• Support UAC1 and UAC2 audio
• SPDIF library
  
• I2C library :
• SPI library:
• USART library :
• GPIO :
• DEBUG :

::Device configuration subsystem :  I suggest a standardized configuration language that would allow the runtime configuration of a chip. For example, power up configuration is different with each chip but in the end it boils down to I2C commands to the chip. It would be nice if there was a method in place where you only populated a table with startup commands which would be downloaded at power up.  You would only need to modify this external table and flash the chip for permanent storage. Troubleshooting would not require edit/compile/burn cycle of the code and would leave the code tree device agnostic. The alternative is each new device would need to be included in the master which would  add to the clutter.  Not everyone will have the tools or experience to modify the code but if the configuration system had enough features it would be usable to someone who leans to the hardware more than the software.

Obviously this needs serious design consideration for it to be useful. A badly implemented idea can make matters worse.

The Atmel chip has enormous pin assignment flexibility but is is not unlimited. Some multi pin services (SPI, I2C, USART functions could interfer with some function requests.

OK.. that is what I propose for an Audio-Widget 2.0 and supporting software ...  I have my rain coat on so you can fling all the crap at my idea you feel is necessary and it won't bother me.

Regards,

George Boudreau

[Børge Strand-Bergesen]

George,

I think the idea is great!

While I've been adding new functionality piece-wise through the years, I have frequently come across sections of code which I haven't understood and haven't dared modify.

The initial specification makes a lot of sense. A few comments:

- Backward compatibility. New code should work on old boxes. This can be done with hardware-dependent #defines.

- DSD support. I don't yet know how and if it can be done. But let's have it on the wish list.

- Whenever I make a new schematic I try to take care and put in comments which describe all signals historically used by a GPIO pin. I hope a lot of those can go away now.

- SPDIF input: I'm up and running with WM8805 (and WM8804) with I2S buffering in the MCU. Not yet elegant, but functional.

Eventually, we can drop UAC2 support. The only OS holding on to UAC1 is Windows. When everybody migrates to what is now being developed for Win10 there is no longer a need to maintain UAC1. There exists a UAC3. It is mainly UAC2 plus more complex power management.

Børge

--
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]

Hi Borge.

What I am hoping to do is to bring the work done by others back under a new roof.  It will take a while for the ideas to float to the surface both hardware and software.  For hardware i am looking to provide a clean core for others to extend with their ideas. Ti Kan put his MCLK off board but left the switching on the core board. Interesting idea that does not tie you to a hardwired clock but lets you quickly experiment without trashing the coare board.

::Backward compatibility::: oh I was hoping not to do legacy support. #DEFINES of not does make for ugly code. But I can see why you and others need to be compatible with existing boards.

Personally I was looking to strip everything out the tree but the bare essentials to drive a simple DAC (PCM5012 or AKM) from USB and drive the buffer LEDs.  Once that is done and rock solid you can add in the other features needed to support a usable board.  If we start from zero we can argue every choice and if needed how to implement the choice with flexibility.  I realize flexibility can be a pain to create but your heartache is once and then it becomes simple to use. I am thinking of the flexible DAC/ADC/SPDIF configuration subsystem.  Grief up front for joy in the future.  Eventually I would like to see the new software only need touching for maintenance and not fiddled with to add a new device(s).

We have the core routines in the existing experimental branch we only need to strip them of the unnecessary bits.

::DSD - If it is DOP then that is one thing. If you need hardware switches and software then more research is needed into the maping of the I/O pins.  Drag out the spec sheets and see how everyone does it with their chips, find commonality and go from there.

::SPDIF::  I assume you have taken control of a few pins to fiddle with the chip and patched the software to support the device.  I assume the WM8805 is doing the heavy lifting an you are only doing the decoding in the controller.  If the code is solid I do not see any reason not to add it to the new code.  Pin definitions would need to be mapped early in the Audio-Widget 2 board definition, first come first serve :-)

::UAC1/UAC2::  UAC1 is well defined and supported by everyone and if the code exists and not buggy I do not see throwing it in the garbage any time soon. Until Microsoft turns out a native UAC2 driver I would not turf it out.

George

[Ti Kan]

Hello everyone,

I like the idea of a specification and a cleaned up code base for USB audio only. While we're not completely rid of all the sdr-widget remnants, I think Borge has already eliminated a good chunk of unused stuff (at least in the experimental branch).  I note that the compiled binary size is now much smaller now.

I currently have the same audio widget module supporting three different DAC projects (with possibly more to come), and it will be costly and inconvenient to change them all, so hardware backward compatibility is a must. Physically, electrically, and functionally.

I currently use the audio widget purely as a USB to I2S converter, so I have no use for S/PDIF (input or output). On two of my DACs S/PDIF is handled by using separate chips. I also don't use the audio widget to control other hardware such as the DAC in software mode. I use a separate arduino-based processor for that.

New features can be added in firmware, DSD (DoP) is very high on my wishlist, with div/1 clock we should be able to support up to DSD256, and PCM up to 384khz sampling rate.  DSD/PCM signal routing will have to be external to the audio widget because it's DAC-specific. Look at the Amanero, and I believe we should do something like it.  But here again the software and hardware must remain compatible with existing implementations, new features can be "activated" at run time. 

I would like to have a single firmware binary to support all my devices.  I don't want to flash different firmware for each device type. That would make it very inconvenient for me because I ship audio widget modules.  Many users of my projects transfer the audio widget module from one device to another, and it shouldn't require a firmware change each time.

The UAC1/UAC2 capability should be retained. Many people are never going to run Windows 10 and there are myriad of legacy USB sources that does not support anything other than UAC1.

-Ti
-- 

Sent from my commlock

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

[George Boudreau]

Hi Ti Kan.

Thanks for the input.  My understanding of your needs means you want the status quo for the hardware but support any firmware upgrades including housekeeping of the git repository.

You said you  "would like to have a single firmware binary"  that is capable of supporting all your devices.  How do you currently support multiple devices. Given you drive the DAC configuration with an external Arduino chip and you only use the audio-widget as a USB->I2S module I do not see any changes impacting on your products.

Would you list the pins that you export and use to your products.  With a pin usage table we can easily spot conflicts and work on solutions.

As for div/1 and 384K I believe Jaroslav Dohnai is the only one with experience at this sampling rate. I do not know how stable the hardware and software is at this level but if Jaroslav believes the chip/firmware/ASIO will reliably support this then there is no real need for the div/2 we currently use.   To support existing boards there would need register manipulation that could be set during the build or ar runtime configuration.

Unless there is a code space issue UAC1 can hang around as long as needed.  The heavy lifting code wise has already been done and there is no need to chuck it away.

George

[Børge Strand-Bergesen]

Hi George,

If I remember correctly, Ti's module is a replica of the one I made, but only with one row of pinning. Ti, is that right?

My module had both 2.0mm and 2.54mm pin rows. It only used the 2.0 set.

It shouldn't be too hard to test 384k firmware. Descriptors, uac2_usb_specific_request.c, uac2_d_a_t.c would have to change. Testing on Linux makes sense, then we don't have to rewrite the ASIO driver at the same time. But I don't know if the firmware would actually be able to handle it.

Børge

[George Boudreau]

To start the software trimming without stomping on peoples toes I have created a spreadsheet with the I/O pins listed and their functions as currently used by Borge Strand-Bergesen and the proposed "Audio Widget 2.0".  Please populate the file with you current pin usage and return.  Once I have these pins I can see how new pin assignments will impact on existing boards.

One item I will be removing from the software will be the LCD parallel driver. I will be replacing the parallel system with a serial interface (hopefully)

Regards

George Boudreau

[Ti Kan]

George Boudreau wrote:
> Thanks for the input. My understanding of your needs means you want the
> status quo for the hardware but support any firmware upgrades including
> housekeeping of the git repository.

Yes and no, The hardware can evolve but as long as the code still
supports the existing hardware (even with some new features that
are optional or can be conditionally-compiled, then I'm ok with that.
The main concern here is that any work moving forward should not
obsolete the stock of audio widget modules and DAC boards that
I currently ship (and will for a long time to come).

> You said you "would like to have a single firmware binary" that is
> capable of supporting all your devices. How do you currently support
> multiple devices. Given you drive the DAC configuration with an external
> Arduino chip and you only use the audio-widget as a USB->I2S module I do
> not see any changes impacting on your products.

The "same binary" aspect is more or less for my own case.
I compile the firmware with a few special -Dxxx to set my
specific VID/PID, identification strings, and a few other features.
That firmware is flashed into every audio widget modules I
ship, regardless of what specific DAC it will be used in
(as I said, currently I have three models).

As long as any new firmwae feature can be compiled in (or not),
where new hardware support is concerned, I'm ok with that.
There is already precedence with this practice.
For example Borge's WM880x and SPDIF code, which are all
conditionally compiled. I think it's a good way to do it.

> Would you list the pins that you export and use to your products. With a
> pin usage table we can easily spot conflicts and work on solutions.

I see that you created a spreadsheet, that's a good idea.
I'll work on it later when I have more free time.

> As for div/1 and 384K I believe Jaroslav Dohnai is the only one with
> experience at this sampling rate. I do not know how stable the hardware and
> software is at this level but if Jaroslav believes the chip/firmware/ASIO
> will reliably support this then there is no real need for the div/2 we
> currently use. To support existing boards there would need register
> manipulation that could be set during the build or ar runtime
> configuration.

We still need to support existing hardware that does the div/2.
Borge and I discussed this previously, and agreed to assigning
a GPIO pin to let the "analog board" tell the audio widget whether
the incoming clock is div/2 or div/1. The firmware reads this
pin at boot time and handle it appropriately.

> One item I will be removing from the software will be the LCD parallel
> driver. I will be replacing the parallel system with a serial interface
> (hopefully)

OK, no problem with that. Where an LCD is concerned, one of my
DACs has one but it's driven by a separate arduino processor,
not the audio widget.

Børge Strand-Bergesen wrote:
> If I remember correctly, Ti's module is a replica of the one I made, but
> only with one row of pinning. Ti, is that right?

Yes, it's essentially a clone of the USB-I2S module that you shipped
with your AB-1.1, I believe those have the 2mm pitch pins only too.

> It shouldn't be too hard to test 384k firmware. Descriptors,
> uac2_usb_specific_request.c, uac2_d_a_t.c would have to change. Testing on
> Linux makes sense, then we don't have to rewrite the ASIO driver at the
> same time. But I don't know if the firmware would actually be able to
> handle it.

Yes, we should test this, but we need to merge Jaroslav's
modifications into the experimental branch (or at least grab his
code to compile, and merge later). Currently I don't have any
384K-capable DACs to test it with. I might be able to breadboard
something, but it's going to be some time before I could do
that, my time is pretty full these days.

-Ti

[Børge Strand-Bergesen]

Hi George,

Here's my update of the spreadsheet.

For once, we can remove hpsdr_device_audio_task.c. I have tried to maintain it while putting new stuff into uac1 and uac2 d_a_t, but I haven't tested the code. Better get rid of it! Same thing goes for bootup LED blinking. The if(startup) code has caused me some headaches the last few nights.

Børge

[George Boudreau]

Thanks Borge,  Ti Kan, I took the pin assignment from the Zeta schematic you had posted on you AMB site and update the speadsheet. (see attached).  If could update the comment section for you pin usage or lack of it would be great.

Borge, I see you re-mapped the clock select pin on your prototype board.  Any new software will need to maintain both pins to allow legacy support for your original AB-1 as well as Ti Kan's Zeta board (correct).

What I see as obsolete functions from the new pin assignments.

• ROTI & ROTQ is for a rotary quadrature encoder. Borge has claimed one of the pins so we drop the support code for these pins
• LCD pins
• AK5394 ADC hardware pins.  If someone decides to produce an ADC I hope the use I2C configuration and not hardware. If possible this block of consecutive pins, PB00-PB09 should be kept as a unused block. It may make a nice 8-bit parallel port for future use. 
  
• DAC0 and DAC1 were used in the SDR-Widget for bias control of a RF power amplifier so they can be reused. Any reference to the DAC function will be removed from the code. Borge has commandeered 3 of the 4 pins assigned to DAC0 and DAC1.

George

[Børge Strand-Bergesen]

Hi George,

I agree with what you describe as obsolete HW.

Børge

[Ti Kan]

Hi George,

OK, attached is the spreadsheet with my updates.

-Ti

On Thu, Mar 02, 2017 at 08:44:22AM -0500, George Boudreau wrote:
> Thanks Borge, Ti Kan, I took the pin assignment from the Zeta schematic
> you had posted on you AMB site and update the speadsheet. (see attached).
> If could update the comment section for you pin usage or lack of it would
> be great.
>
> Borge, I see you re-mapped the clock select pin on your prototype board.
> Any new software will need to maintain both pins to allow legacy support
> for your original AB-1 as well as Ti Kan's Zeta board (correct).
>
> What I see as obsolete functions from the new pin assignments.
>

> - ROTI & ROTQ is for a rotary quadrature encoder. Borge has claimed one

> of the pins so we drop the support code for these pins

> - LCD pins
> - AK5394 ADC hardware pins. If someone decides to produce an ADC I hope

> the use I2C configuration and not hardware. If possible this block of
> consecutive pins, PB00-PB09 should be kept as a unused block. It may make a
> nice 8-bit parallel port for future use.

> - DAC0 and DAC1 were used in the SDR-Widget for bias control of a RF

> >>>>>>> - USB : UAC1 & UAC2 *** A 4-layer board: Yes, this should be

> >>>>>>> used. I got lucky with the original SDR-Widget and Audio-Widgets by using a
> >>>>>>> 2-layer board and short runs. The PCB should have controlled impedance to
> >>>>>>> support the full 480mbps. Cost is greater but that is life.

> >>>>>>> - MCLK : support - div 2 and div 1 frequency select
> >>>>>>> - I2S : Out ( DAC )
> >>>>>>> - I2S : In ( ADC )
> >>>>>>> - I2C : Master for device control.
> >>>>>>> - SPI : Master with 1 or more CS lines for ???
> >>>>>>>
> >>>>>>>
> >>>>>>> ::Nice to have:::
> >>>>>>>
> >>>>>>> - S/PDIF : Chip specific implementation. Who choses chip but if

> >>>>>>> the pins are defined for input then all is possible.

> >>>>>>> - SPI : Slave (if possible)
> >>>>>>> - USART : Future functionality
> >>>>>>> - GPIO : hardware support for what???
> >>>>>>> - JTAG : How many people actually have a JTAG debugger for the

> >>>>>>> AVR series
> >>>>>>>
> >>>>>>>
> >>>>>>> ::Won't support::
> >>>>>>>

> >>>>>>> - 4-bit parrallel LCD (use SPI display is you want visual

> >>>>>>> output)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ::SOFTWARE: Once stripped of all radio control functions what is
> >>>>>>> left should be
> >>>>>>>
> >>>>>>> ::Required::
> >>>>>>>

> >>>>>>> - Support UAC1 and UAC2 audio
> >>>>>>> - SPDIF library
> >>>>>>> - I2C library :
> >>>>>>> - SPI library:
> >>>>>>> - USART library :
> >>>>>>> - GPIO :
> >>>>>>> - DEBUG :

> >>>>>>> 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.

> >>>>> 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.

> > 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

[George Boudreau]

Hi Ti Kan,

I was unable to open your file.  Try sending as an old fashion .xls

> >>>>>>> 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.
> >>
> >
> > --
> > 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]

OK, attached.

-Ti

> > > >>>>>>> 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.

> > > >>>>> 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.

> > > > 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.

> > 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.

[George Boudreau]

Excellent.  You were not kidding when you said you were using the design as strictly USB -> I2S.   Re-purposing any of the unused pins would not impact your boards which give plenty of flexibility.

Thanks,

George

OK, attached.

-Ti

> > > >>>>>>> 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.
> > > >>
> > > >
> > > > --
> > > > 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.

> > 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.

[Børge Strand-Bergesen]

Hi guys,

I'm making progress on the SPDIF buffering side. May not seem relevant, but its requirements for stability is leading to improvements elsewhere in the code. The relationship between num_remaining and which half-buffer the pdca is working on is just one example. Another is all the various ways the outgoing DAC data is nulled. I have started working on a unified way of nulling the output, and expect to work more on that even after George's cutting process is well underway.

My SPDIF code is getting more and more every day. I can push what I have but the code is still in flux.

One thing I can strip here is excess images. I suggest only retaining UAC1 and UAC2 images, and deleting everything else. I'll commit before I do that major cleanup.

audio-widget-experimental does NOT support ADCs today. The Audio Widget USB descriptors have long had any trace of ADCs removed. It was required to make UAC1 work on iOS. The sequential code still has sections for filling ADC IN endpoints, but it isn't used. I have re-purposed the ADC I2S channel for SPDIF buffering. One job which must be done as a part of AW2 is to re-introduce ADC support with conditional compile statements. It did work in earlier versions of the code, and shouldn't be too hard to put in. We just have to be aware of it. With an ADC present, the feedback reporting system for audio OUT must be deactivated.

Børge

[George Boudreau]

Borge et al.

I did not know the experimental was stripped of its ADC functionality.  If adding ADC functionality back to the code impacts on the quality of the DAC playback I suppose it does not make sense to keep
the AK5395 hardware traces.  In the end the Audio-Widget will be an output only USB audio engine (w/SPDIF).

This is only code and since no one is claiming ADC input functionality for their boards strip away Borge.

George

[Børge Strand-Bergesen]

Hi George,

I have never made an ADC board. So when I found out the descriptors had to have it taken out, I stopped maintaining the functional code.

If we really need ADC it isn't very hard to put it back in. Removing ADC IN functionality does make the re-insertion a bit harder.

I'm all for keeping ADC support as a build option, but it must be tested and maintained by someone other than me since I don't have hardware for it.

Børge

[Ti Kan]

Hi Borge,

Speaking of iOS supoprt, I am still experiencing problems with the
latest code on my iPhone with the USB camera adapter. As you might
recall, it would play fine initially, but after a number of songs
something goes wrong and the sound becomes garbled, with the
two rate feedback LEDs flashing like crazy. I don't see this
behavior on Windows or Linux. All these are in UAC2 mode. I didn't
try UAC1 yet. An older firmware I built in August 2015 does not
exhibit this problem.

Do you think your code improvements might fix this? If not, then
this should be an item to look at.

-Ti

[George Boudreau]

Hi Borge.

To me it is all about keeping the widget flexible. Using I2C or SPI to drive an ADC is superior to the hardware bit flipping of the SDR-Widget.  Hardwire was the method of choice back then as it was 'simplier' for a dedicated board.

As long as the I2S subsystem will support an ADC input and your SPDIF then all is well. If it is to be an either/or usage then there needs to be some head work done.  Compile time config is acceptable but I am hoping for DAC-ADC-S/PDIF support for the really adventurous DIY.

I can use what I learned from other jobs to create a 2 channel board with I2S and I2C config.  using a different chip such as the  AK5397. The AK5397 is their premium ADC with some serious specs.  I will make it a bare bones, fixed input voltage straight from their datasheet.

George

[Børge Strand-Bergesen]

Ti,

Strange! I'll test. Haven't tested on iOS for a while.

George,

It's fairly easy to run a DAC chip off recovered MCLK from an SPDIF receiver chip. That leaves the ADC I2S port alone.

The tricky part is to buffer the data in the MCU and play it back on the high-quality oscillators in the analog section. For that I'm re-purposing the ADC port. That's an either-or with ADC functionality.

Børge

[George Boudreau]

Borge

Ok, it is either/or at design time as well as at compile time.This is not a problem as long as future users know what needs to be done.

How ugly would the compile time switches be.  The deeper you need to reach into the code to accommodate both ADC and S/PDIF with switches the more difficult it is to maintain.  Would it be possible to create separate modules with minimal connections to each other?  It may be the perfect opportunity to rethink the code base with all the ripping and stripping you will be doing.

[Børge Strand-Bergesen]

Hi George,

I'm trying to make the switches based on general features, not on very specific nitty-gritty. Preferably by function calls and not unreadable code. First I have to make it work properly, then I'll try to make it more and more tidy. Removing dead code will also simplify the tidying.

Børge

[Børge Strand-Bergesen]

Hi guys,

I've just pushed my last code to audio-widget-experimental. This builds for my prototype, change AUDIO_WIDGET_DEFAULTS in Makefile if you want to build for something else. Traditional AW builds haven't been tested, then again, most of my changes are within special #ifdefs.

Ti, you mentioned something weird on iOS. I'll check this too. My advice to you is to scope on the GPIO referred to around writes to (uacX_device_audio_task.c) and reads from (pdca interrupts) spk_buffer_X. You can also put in a UART terminal and look for '+', '-', '/', '*', 'i' and 's'. A little bit of + and - is normal for a stable USB feedback system.

Børge

[Ti Kan]

Hi Borge,

I don't fully understand what you wrote, but I'll trty to figure it out.
It will be some time before I could get to this, because I am currently
swamped with other work.

-Ti

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

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

> >>>>>>>>> > > > >>>>> --
> >>>>>>>>> > > > >>>>> 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/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>>>>
> >>>>>>>>> > > > >>>>

> >>>>>>>>> > > > >>>> --
> >>>>>>>>> > > > >>>> 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/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>>>
> >>>>>>>>> > > > >>>

> >>>>>>>>> > > > >>> --
> >>>>>>>>> > > > >>> 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/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>>
> >>>>>>>>> > > > >>

> >>>>>>>>> > > > >> --
> >>>>>>>>> > > > >> 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/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>
> >>>>>>>>> > > > >

> >>>>>>>>> > > > > --
> >>>>>>>>> > > > > 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.
> >>>>>>>>> > >
> >>>>>>>>> > >
> >>>>>>>>> > >
> >>>>>>>>> > > --
> >>>>>>>>> > > 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.

> >>>>>>>>> > > 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.

> >>>>>>>>> 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.

> >>>>> 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.

[Børge Strand-Bergesen]

Hi Ti and all,

If you want to debug the feedback system for any OS, watch these two GPIO signals while monitoring the UART dump. That is the monitoring method which eventually led me to investigate its stability.

The interrupt driven pdca code shows where it fetches the -next- half-buffer of audio samples:

https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/taskAK5394A.c#L156
https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/taskAK5394A.c#L163

The sequential USB receive code indicates where it puts the recently received audio samples:
https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/uac2_device_audio_task.c#L991
https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/uac2_device_audio_task.c#L993

These two GPIO signals should be in phase. The amount of slack allowed is defined here:
https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/uac2_device_audio_task.c#L101

Depending on how far out-of-phase the two are (i.e. size of gap), different action is taken in the feedback system:
https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/uac2_device_audio_task.c#L1104

Børge

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

> >>>>>>>>> > > > >>>>> For more options, visit https://groups.google.com/d/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>>>>
> >>>>>>>>> > > > >>>>> --
> >>>>>>>>> > > > >>>>> 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/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>>>>
> >>>>>>>>> > > > >>>>
> >>>>>>>>> > > > >>>> --
> >>>>>>>>> > > > >>>> 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/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>>>
> >>>>>>>>> > > > >>>
> >>>>>>>>> > > > >>> --
> >>>>>>>>> > > > >>> 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/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>>
> >>>>>>>>> > > > >>
> >>>>>>>>> > > > >> --
> >>>>>>>>> > > > >> 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/op
> >>>>>>>>> tout.
> >>>>>>>>> > > > >>
> >>>>>>>>> > > > >
> >>>>>>>>> > > > > --
> >>>>>>>>> > > > > 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.

> >>>>>>>>> > > 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.

[Børge Strand-Bergesen]

Hi guys, 

I have just made some pretty large changes to the code and pushed to audio-widget-experimental. I'm getting fairly happy about the SPDIF buffering performance. It still lacks a couple features for best audio, but the surrounding infrastructure seems reasonably functional. At least to the point where I'm now switching ot more long-term testing. (Knock on wood, salt over shoulder, the usual :)

At this time I'm OK with moving on with Audio Widget code reduction. Let me know your opinions about where to start and whether I'm suggesting to remove too much here.

Please list your I2C hardware requirements! On my list I only have WM8805. 

The first things on my list are:

- More systematic approach to clearing spk_buffer?[]

- Remove all images other than UAC1 and UAC2, with associated code. 

- Keep basic LCD features but remove advanced text and graphics

- Keep basic I2C but remove hardware support which isn't part of the Audio Widget branches

Børge

[Ti Kan]

Hi Borge,

Currently I don't have any I2C devices connected to the audio widget.

-Ti
-- 

Sent from my commlock

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

[George Boudreau]

Keep banging away Borge.  A lean, mean code branch is easier to maintain and add features to.

I2C:  Any chance you can implement an I2C channel that supports 'events'.  For example: speed change detection causes an event trigger. If that event has supporting code, such as register changes it is acted on at that time.  This would allow new hardware to be implemented in as a separate file. Device specific register commands would be held in this file. For generic, non-configurable devices such as the PCM5102 the file would only contain power up settings and MCLK selection on the speed change event.

The pros would be device specific file for compile and no need to touch the code 'kernel'. There is the possibility of having the code inhaled from the configuration routine.

Just a though.

George

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.

[Børge Strand-Bergesen]

Hi George, 

That mechanism is quite easy to put in, at least if function calls are accepted. An untouchable core system calls a function which can be easily edited. 

Børge

[George Boudreau]

Borge,

I have attached a copy of the XMOS configuration template describing their 'event' servicing/idea.  This structure supports USB and DSD and could be expanded to support your SPDIF implementation.

The idea is to have a basic 'no configuration needed' file that would support hard wired devices. DAC or ADC that require configuration would have compile time files that would manipulate configuration registers based on 'events'.  Device specific code would be in a single file and those who wanted to implement their own devices would only need to create/modifiy this file and run the compile.  No need to wade chin deep through the main code (assuming it is bug free...)

In an ideal world where I was a code guru this file would actually be an external text file that would be loaded by the GUI into the widget firmware. This would keep sticky fingers out of the code base, drop the need for new developers to have the Atmel IDE installed and all the headaches associated with the compile.  This is just and idea and i have a few thoughts on implementation but nothing solid.

The easiest method would be a compile the new device file and link it against the main code block.

George

[Børge Strand-Bergesen]

Hi George, 

a lot of the functionality I have been putting in lately is fairly deep down. I even had to write an assembly routine for the SPDIF sample rate detector. (Which uses the cycle counter for precision and statistics to detect task switching!)  

Next on my list would be DSD support using two USARTs. I have no idea if it will work. If it does, it will limit us to DSD64. 

Børge

[Jaroslav Dohnal]

Hi Børge,

When I have time I want to design dual WM8741 with discrete outpuststage and powersupplies. 

Already have the chips so I have some motivation... :D

I'll do some glue logic muxing around the AVR32. I also want to try external filter mode (or 8FS mode, whatever you wanna call it) to put PCM data from AVR32 directly into DACs modulators. 

I planned to use the SSC for DSD Left channel data (configured to 8 or 16 bit mode) and USART/SPI (configured to 16 or 32 bit mode) for right channel. SCK generated as usual from clock module. Will see how that goes. 

Why do you thing USART would limit it to DSD64? I dont really mind as DSD64 is plenty for me personally. I've got 768kHz and DSD512 working on xmos...but you just never use it. 

I also need to port the whole firmware into atmel studio so I can use my ICE JTAG debugger...othervise it would be pain to get going...

I'll let you know if I get somewhere, but I just have really a lot of work lately, I don't even have time for my personal live.

[Børge Strand-Bergesen]

Hi Jaroslav, 

Dual WM8741 sounds very interesting! What is your proposed power supply structure? I'm working on a simplified version of: http://www.startfetch.com/keantoken/content/Kmultiplier.php

I'm working with the AK4490 these days. The DSD and NOS interface are quite similar, boht have one data pin for each channel. That's a big hassle because the UC3 only has one SSC. And even using the SSC for 100% tight I2S is NOT easy. I have an ongoing struggle with that....

Anyway, my take on DSD and NOS was to investigate the use of two USARTs fed by two separate PDCAs. Do you think that is better or worse than SSC and USART in combination? 

DSD64 has the USB bandwidth of PCM 176/24. At the moment we're maxing out the USB subsystem at 192/32. So I think DSD128 ~= 352/24 is slightly out of reach. Because the UC3 doesn't have 1kB endpoint buffers, we'd have to run it at 125us USB packet rate. (352.8ksps * 0.125us * 3 bytes * 2 channels < 512 bytes) We might be able to push the RTOS to a 125us packet rate, but a lot of timing and interaction would have to be hand tuned. 

Best,

Børge

--

[Jaroslav Dohnal]

Hi, 

I will use active shunt regulators with current sources as a power supplies, that multiplier looks bit overcomplicated for its performance. I thing simple current source feeding cap on trasistor base will be better. With like 3 diodes in series bypassing the current source for fast charge of the cap on powerup. 

I will probably use SPI + SSC for DSD/EXIF. My friend writing UAC on SAME70 has terrible problems in synchronizing USARTS. I dont know if its only a problem on that platform, or Atmel USART in general...but I presume if they had a bug with their new processor, they gonna have it here as well. He said that it works for 2.8...MHz, but doesn't work with higher FS. 

Also, did you look into that problem with new MS UAC2 drivers where dac is ony 44.1 kHz? 

Thanks.

JD

On Tuesday, 28 February 2017 17:45:28 UTC+1, George Boudreau wrote:

Borge Strand-Bergesen, Ti Kan, Jaroslav Dohnai, et al

I am throwing out a 'Request For Comment' on the future direction of the audio-widget hardware and code base.  I look at my files and I see original files dated 2009/2010. As everyone knows the audio-widget was a re-imagining of the hardware of the Amateur Radio SDR-Widget hardware I produced.  I stripped all the I/O and the ADC hardware from the design and created a platform that focused strictly on audio output. The original audio-widget card had the ESS ES9023 chip and then moved to the TI PCM5102 DAC.  I sold a number of DIY solder kits using both chips  The idea was to spur others to use the AT32UC3A3 USB audio engine a base for their designs. The hope was there would be enough interest from others that a Windows UAC2 driver might be written. An ASIO driver was created but that was as far as Windows support went. Borge Strand-Bergesen was the first to embrace the hardware and he eventually released a commercial product based on the Audio-Widget core.

From the code side the Auudio-Widget was a 'crippled' SDR-Widget. Some feature were disabled at compile time while others were set during runtime configuration.  The is done to take advantage of the evolving SDR-Widget code. Any improvements in the SDR-Widget audio change were available to the Audio-Widget with minimal effort.  While this was acceptable in the early days it has left a legacy support problem.  The 'experiment branch' of the widget code forked from the original SDR-Widget code base and focuses strictly on the audio chain yet there is still old radio control software in this branch. This makes life for the software maintainer a nightmare and needs to be changed.

I am proposing an 'Audio-Widget 2.0' hardware platform and a software tree that only supports the hardware as a USB audio engine driving DAC and/or ADC components with no backward compatibility with the older hardware.  I am soliciting ideas from the group as to what features you wish supported. Any idea that can be supported by the chip will be considered. Justification should accompany all ideas and if you have a solution to go with your suggestion you get bonus points.

The existing software is a dogs breakfast since there was no specification in the and the functionality evolved with minimal direction. I propose another fork of the existing code base that will support only those functions needed to support an audio controller and strip away all unnecessary radio focused code. A cleaner code base will allow for easier maintenance and feature enhancements.

Long winded explanation ended, now the formal requests for input. Some will seem obvious but better stated than forgotten.

HARDWARE:: What hardware features do you require

::Required::

• USB : UAC1 & UAC2  *** A 4-layer board: Yes, this should be used. I got lucky with the original SDR-Widget and Audio-Widgets by using a 2-layer board and short runs.  The PCB should have controlled impedance to support the full 480mbps.  Cost is greater but that is life.

• MCLK : support - div 2 and div 1 frequency select

• I2S : Out  ( DAC )

• I2S : In  ( ADC )

• I2C : Master for device control.

• SPI : Master with 1 or more CS lines for ???

::Nice to have:::

• S/PDIF :  Chip specific implementation. Who choses chip but if the pins are defined for input then all is possible.
  

• SPI : Slave (if possible)
• USART : Future functionality
  

• GPIO : hardware support for what???

• JTAG : How many people actually have a JTAG debugger for the AVR series

::Won't support::

• 4-bit parrallel LCD  (use SPI display is you want visual output)

::SOFTWARE:  Once stripped of all radio control functions what is left should be

::Required::

• Support UAC1 and UAC2 audio

• SPDIF library
  
• I2C library :
• SPI library:
• USART library :
• GPIO :

• DEBUG :

[Børge Strand-Bergesen]

Hi Jaroslav, 

I have recently gone very deep into the SSC/PDCA code for I2S. The reason is that the PDCA can some times flip R/L channel if it isn't started at exactly the right spot. This is also an issue on the RX PDCA in my buffered I2S application. I have pushed my code quite resently with these changes. We should talk as you attack the SPI / UART / SSC stuff. I never worked on any ARM based Atmel chips. In an ideal world our AVR32 code could be ported to something with higher performance, lower cost and very similar IO. 

MS drivers for UAC2: Ongoing issue. ANY help appreciated! In short, I think there is something wrong with descriptors and/or control endpoint commands. The reason I think so is that UAC2 on Linux (Mint 17 / 64-bit) doesn't relate to the DAC's volume control system. On UAC1 it does, and other OSes can set the volume just fine. 

 And UAC2 on Win10 Creators Update doesn't change the sample rate. I have modified the sample rate definitions in the descriptors, then C.U. doesn't see it at all. 

My -belief- is that the two operating systems both detect that something is wrong, and then relate to the DAC in each their own minimal feature set ways. To get to the Win10 frequency bug, we might as well debug descriptors and commands on Linux. 

Anybody here able to lend a hand on that? I can build new firmware with volume control enabled. I've been recommended to run it on a kernel with verbose ALSA drivers. I've never tried that, and I haven't built a kernel in 17 years, so I'm not sure it is the best way forward for me. But if you have experience with this sort of thing, please let us know! 

Børge

[Jaroslav Dohnal]

I'm quickly looking at it. But as I dont really have much time, I dont think I will be able to do anything... 

here is a register dump and comparasion of my XMOS (768/32 output with native DSD + dop, without volume) and my ooooold audio widget firmware (192/24, no volume that I'm aware of): https://www.diffchecker.com/fbmS8owf

Maybe it will be helpfull. XMOS works under windows without any trouble.

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

[Børge Strand-Bergesen]

Interesting tool! 

I'll post as I try out different things here. 

Børge

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

[Børge Strand-Bergesen]

Jaroslav, 

I'm deep into debugging UAC2 on Win10 C.U. and have been for several days. So far I have found that the Audio Widget is able to communicate sample rates to Win10 and to other OSes. The reason Win10 locks to 44.1 does not seem to be malformated sample rate configuration. (Although this chase did uncover a couple bugs in that area.)

Could you please check what I write here against the diff'ed descriptors you sent? 

I have dumped output from uac2_usb_specific_request.c from plug-in events of Win10+ASIO, Win10 C.U, Linux (Mint17/64), Mac OS X. There are three pieces of USB interaction which take place on Mac OS and Linux but NOT on Win10 C.U. I'm not using the fairly minimalist ASIO driver as a reference, since it does not implement full UAC2. 

My latest checks show that Win10 C.U. NEVER asks whether the clock source is valid or not. This data is requested by Linux and by Mac OS but not by Win10 C.U.: https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/uac2_usb_specific_request.c#L1040

What I believe now is that Win10 doesn't find a valid clock source in the descriptor, and hence never asks the device if it's running OK. 

Possibly as a consequence, it never does these two checks, which however are requested by Linux and Mac OS:

https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/uac2_usb_specific_request.c#L1349

https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/uac2_usb_specific_request.c#L1021

Børge

[Børge Strand-Bergesen]

Hi guys, 

I tried adding an "Pro-Ject Clock Selector" because this was present in the device Jaroslav sent the diff of, but not present in AW firmware. 

Still no success on Windows 10 C.U. I'm afraid. Do you see any major bugs with this descriptor dump?

Børge

Information for device Henry Audio USB DAC 128 mkII (VID=0x16D0 PID=0x075D):

Connection Information:

------------------------------

Connection status: Device connected

Device actual bus speed: HighSpeed

Device supports USB 1.1 specification

Device supports USB 2.0 specification

Device is hub: No

Device address: 0x0009

Current configuration value: 0x01

Number of open pipes: 2

Device Descriptor:

------------------------------

0x12 bLength

0x01 bDescriptorType

0x0200 bcdUSB

0xEF bDeviceClass   (Miscellaneous device)

0x02 bDeviceSubClass   

0x01 bDeviceProtocol   

0x40 bMaxPacketSize0   (64 Bytes)

0x16D0 idVendor

0x075D idProduct

0x1000 bcdDevice

0x01 iManufacturer   "Audio-Widget"

0x02 iProduct   "Henry Audio USB DAC 128 mkII"

0x03 iSerialNumber   "2017042900BSB"

0x01 bNumConfigurations

Device Qualifier Descriptor:

------------------------------

0x0A bLength

0x06 bDescriptorType

0x0200 bcdUSB

0xEF bDeviceClass   (Miscellaneous device)

0x02 bDeviceSubClass   

0x01 bDeviceProtocol   

0x40 bMaxPacketSize0   (64 Bytes)

0x01 bNumConfigurations 

0x00 bReserved 

Configuration Descriptor:

------------------------------

0x09 bLength

0x02 bDescriptorType

0x00C9 wTotalLength   (201 Bytes)

0x04 bNumInterfaces

0x01 bConfigurationValue

0x00 iConfiguration

0xC0 bmAttributes   (Self-powered Device)

0x05 bMaxPower   (10 mA)

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x00 bInterfaceNumber

0x00 bAlternateSetting

0x00 bNumEndPoints

0x00 bInterfaceClass   

0x00 bInterfaceSubClass   

0x00 bInterfaceProtocol   

0x00 iInterface

Interface Association Descriptor:

------------------------------

0x08 bLength

0x0B bDescriptorType

0x01 bFirstInterface

0x02 bInterfaceCount

0x01 bFunctionClass   (Audio Device Class)

0x00 bFunctionSubClass   

0x20 bFunctionProtocol   

0x00 iFunction

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x01 bInterfaceNumber

0x00 bAlternateSetting

0x00 bNumEndPoints

0x01 bInterfaceClass   (Audio Device Class)

0x01 bInterfaceSubClass   (Audio Control Interface)

0x20 bInterfaceProtocol   

0x07 iInterface   "Henry Audio USB DAC 128 mkII"

AC Interface Header Descriptor:

------------------------------

0x09 bLength

0x24 bDescriptorType

0x01 bDescriptorSubtype

0x0200 bcdADC

0x04 bCategory   (HEADSET)

0x0048 wTotalLength   (72 Bytes)

0x00 bmControls

AC Clock Source Descriptor:

------------------------------

0x08 bLength

0x24 bDescriptorType

0x0A bDescriptorSubtype

0x05 bClockID

0x02 bmAttributes

0x07 bmControls

0x03 bAssocTerminal

0x05 iClockSource   "Clock 2"

AC Clock Selector Descriptor:

------------------------------

0x08 bLength

0x24 bDescriptorType

0x0B bDescriptorSubtype

0x05 bClockID

0x01 bNrInPins

0x05 baCSourceID(1)

0x07 bmControls

0x05 iClockSelector   "Clock 2"

AC Input Terminal Descriptor:

------------------------------

0x11 bLength

0x24 bDescriptorType

0x02 bDescriptorSubtype

0x11 bTerminalID

0x0101 wTerminalType   (USB Streaming)

0x00 bAssocTerminal

0x05 bCSourceID

0x02 bNrChannels   (2 Channels)

0x00000003 bmChannelConfig

0x00 iChannelNames

0x00 bmControls

0x08 iTerminal   "Audio-widget"

AC Feature Unit Descriptor:

------------------------------

0x12 bLength

0x24 bDescriptorType

0x06 bDescriptorSubtype

0x12 bUnitID

0x11 bSourceID

0x00000003 bmaControls(0)

0x0000000C bmaControls(1)

0x0000000C bmaControls(2)

0x00 iFeature

AC Output Terminal Descriptor:

------------------------------

0x0C bLength

0x24 bDescriptorType

0x03 bDescriptorSubtype

0x13 bTerminalID

0x0602 wTerminalType   (Digital audio interface)

0x00 bAssocTerminal

0x12 bSourceID

0x05 bCSourceID

0x0000 bmControls

0x00 iTerminal

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x02 bInterfaceNumber

0x00 bAlternateSetting

0x00 bNumEndPoints

0x01 bInterfaceClass   (Audio Device Class)

0x02 bInterfaceSubClass   (Audio Streaming Interface)

0x20 bInterfaceProtocol   

0x00 iInterface

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x02 bInterfaceNumber

0x01 bAlternateSetting

0x02 bNumEndPoints

0x01 bInterfaceClass   (Audio Device Class)

0x02 bInterfaceSubClass   (Audio Streaming Interface)

0x20 bInterfaceProtocol   

0x00 iInterface

AS Interface Descriptor:

------------------------------

0x10 bLength

0x24 bDescriptorType

0x01 bDescriptorSubtype

0x11 bTerminalLink

0x07 bmControls

0x01 bFormatType   (FORMAT_TYPE_1)

0x00000001 bmFormats

0x02 bNrChannels   (2 Channels)

0x00000003 bmChannelConfig

0x00 iChannelNames

AS Format Type 1 Descriptor:

------------------------------

0x06 bLength

0x24 bDescriptorType

0x02 bDescriptorSubtype

0x01 bFormatType   (FORMAT_TYPE_1)

0x04 bSubslotSize

0x18 bBitResolution   (24 Bits/sample)

Endpoint Descriptor:

------------------------------

0x07 bLength

0x05 bDescriptorType

0x02 bEndpointAddress   (OUT Endpoint)

0x05 bmAttributes (Transfer: Isochronous / Synch: Asynchronous / Usage: Data)

0x0188 wMaxPacketSize   (392 Bytes) 

0x02 bInterval

AS Isochronous Data Endpoint Descriptor:

------------------------------

0x08 bLength

0x25 bDescriptorType

0x01 bDescriptorSubtype

0x00 bmAttributes

0x00 bmControls

0x00 bLockDelayUnits   (Undefined)

0x0000 wLockDelay

Endpoint Descriptor:

------------------------------

0x07 bLength

0x05 bDescriptorType

0x81 bEndpointAddress   (IN Endpoint)

0x11 bmAttributes (Transfer: Isochronous / Synch: None / Usage: Feedback)

0x0004 wMaxPacketSize   (4 Bytes) 

0x04 bInterval

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x03 bInterfaceNumber

0x00 bAlternateSetting

0x02 bNumEndPoints

0x03 bInterfaceClass   (Human Interface Device Class)

0x00 bInterfaceSubClass   

0x00 bInterfaceProtocol   

0x00 iInterface

HID Descriptor:

------------------------------

0x09 bLength

0x21 bDescriptorType

0x0111 bcdHID

0x00 bCountryCode

0x01 bNumDescriptors

0x22 bDescriptorType   (Report descriptor)

0x0043 bDescriptorLength

Endpoint Descriptor:

------------------------------

0x07 bLength

0x05 bDescriptorType

0x84 bEndpointAddress   (IN Endpoint)

0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)

0x0008 wMaxPacketSize   (8 Bytes) 

0x05 bInterval

Endpoint Descriptor:

------------------------------

0x07 bLength

0x05 bDescriptorType

0x05 bEndpointAddress   (OUT Endpoint)

0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)

0x0008 wMaxPacketSize   (8 Bytes) 

0x05 bInterval

Other Speed Configuration Descriptor:

------------------------------

0x09 bLength

0x07 bDescriptorType

0x00C9 wTotalLength   (201 Bytes)

0x04 bNumInterfaces

0x01 bConfigurationValue

0x00 iConfiguration

0xC0 bmAttributes   (Self-powered Device)

0x05 bMaxPower   (10 mA)

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x00 bInterfaceNumber

0x00 bAlternateSetting

0x00 bNumEndPoints

0x00 bInterfaceClass   

0x00 bInterfaceSubClass   

0x00 bInterfaceProtocol   

0x00 iInterface

Interface Association Descriptor:

------------------------------

0x08 bLength

0x0B bDescriptorType

0x01 bFirstInterface

0x02 bInterfaceCount

0x01 bFunctionClass   (Audio Device Class)

0x01 bFunctionSubClass   (Audio Control Interface)

0x20 bFunctionProtocol   

0x07 iFunction   "Henry Audio USB DAC 128 mkII"

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x01 bInterfaceNumber

0x00 bAlternateSetting

0x00 bNumEndPoints

0x01 bInterfaceClass   (Audio Device Class)

0x01 bInterfaceSubClass   (Audio Control Interface)

0x20 bInterfaceProtocol   

0x07 iInterface   "Henry Audio USB DAC 128 mkII"

AC Interface Header Descriptor:

------------------------------

0x09 bLength

0x24 bDescriptorType

0x01 bDescriptorSubtype

0x0200 bcdADC

0x04 bCategory   (HEADSET)

0x0048 wTotalLength   (72 Bytes)

0x00 bmControls

AC Clock Source Descriptor:

------------------------------

0x08 bLength

0x24 bDescriptorType

0x0A bDescriptorSubtype

0x05 bClockID

0x02 bmAttributes

0x07 bmControls

0x01 bAssocTerminal

0x05 iClockSource   "Clock 2"

AC Clock Selector Descriptor:

------------------------------

0x08 bLength

0x24 bDescriptorType

0x0B bDescriptorSubtype

0x05 bClockID

0x01 bNrInPins

0x05 baCSourceID(1)

0x07 bmControls

0x05 iClockSelector   "Clock 2"

AC Input Terminal Descriptor:

------------------------------

0x11 bLength

0x24 bDescriptorType

0x02 bDescriptorSubtype

0x11 bTerminalID

0x0101 wTerminalType   (USB Streaming)

0x00 bAssocTerminal

0x05 bCSourceID

0x02 bNrChannels   (2 Channels)

0x00000003 bmChannelConfig

0x00 iChannelNames

0x00 bmControls

0x00 iTerminal

AC Feature Unit Descriptor:

------------------------------

0x12 bLength

0x24 bDescriptorType

0x06 bDescriptorSubtype

0x12 bUnitID

0x11 bSourceID

0x00000003 bmaControls(0)

0x0000000C bmaControls(1)

0x0000000C bmaControls(2)

0x00 iFeature

AC Output Terminal Descriptor:

------------------------------

0x0C bLength

0x24 bDescriptorType

0x03 bDescriptorSubtype

0x13 bTerminalID

0x0602 wTerminalType   (Digital audio interface)

0x00 bAssocTerminal

0x12 bSourceID

0x05 bCSourceID

0x0000 bmControls

0x00 iTerminal

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x02 bInterfaceNumber

0x00 bAlternateSetting

0x00 bNumEndPoints

0x01 bInterfaceClass   (Audio Device Class)

0x02 bInterfaceSubClass   (Audio Streaming Interface)

0x20 bInterfaceProtocol   

0x00 iInterface

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x02 bInterfaceNumber

0x01 bAlternateSetting

0x02 bNumEndPoints

0x01 bInterfaceClass   (Audio Device Class)

0x02 bInterfaceSubClass   (Audio Streaming Interface)

0x20 bInterfaceProtocol   

0x00 iInterface

AS Interface Descriptor:

------------------------------

0x10 bLength

0x24 bDescriptorType

0x01 bDescriptorSubtype

0x11 bTerminalLink

0x07 bmControls

0x01 bFormatType   (FORMAT_TYPE_1)

0x00000001 bmFormats

0x02 bNrChannels   (2 Channels)

0x00000003 bmChannelConfig

0x00 iChannelNames

AS Format Type 1 Descriptor:

------------------------------

0x06 bLength

0x24 bDescriptorType

0x02 bDescriptorSubtype

0x01 bFormatType   (FORMAT_TYPE_1)

0x04 bSubslotSize

0x18 bBitResolution   (24 Bits/sample)

Endpoint Descriptor:

------------------------------

0x07 bLength

0x05 bDescriptorType

0x02 bEndpointAddress   (OUT Endpoint)

0x05 bmAttributes (Transfer: Isochronous / Synch: Asynchronous / Usage: Data)

0x0188 wMaxPacketSize   (392 Bytes) 

0x01 bInterval

AS Isochronous Data Endpoint Descriptor:

------------------------------

0x08 bLength

0x25 bDescriptorType

0x01 bDescriptorSubtype

0x00 bmAttributes

0x00 bmControls

0x00 bLockDelayUnits   (Undefined)

0x0000 wLockDelay

Endpoint Descriptor:

------------------------------

0x07 bLength

0x05 bDescriptorType

0x81 bEndpointAddress   (IN Endpoint)

0x11 bmAttributes (Transfer: Isochronous / Synch: None / Usage: Feedback)

0x0004 wMaxPacketSize   (4 Bytes) 

0x01 bInterval

Interface Descriptor:

------------------------------

0x09 bLength

0x04 bDescriptorType

0x03 bInterfaceNumber

0x00 bAlternateSetting

0x02 bNumEndPoints

0x03 bInterfaceClass   (Human Interface Device Class)

0x00 bInterfaceSubClass   

0x00 bInterfaceProtocol   

0x00 iInterface

HID Descriptor:

------------------------------

0x09 bLength

0x21 bDescriptorType

0x0111 bcdHID

0x00 bCountryCode

0x01 bNumDescriptors

0x22 bDescriptorType   (Report descriptor)

0x0043 bDescriptorLength

Endpoint Descriptor:

------------------------------

0x07 bLength

0x05 bDescriptorType

0x84 bEndpointAddress   (IN Endpoint)

0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)

0x0008 wMaxPacketSize   (8 Bytes) 

0x05 bInterval

Endpoint Descriptor:

------------------------------

0x07 bLength

0x05 bDescriptorType

0x05 bEndpointAddress   (OUT Endpoint)

0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)

0x0008 wMaxPacketSize   (8 Bytes) 

0x05 bInterval

Microsoft OS Descriptor is not available. Error code: 0x0000001F

String Descriptor Table

--------------------------------

Index  LANGID  String

0x00   0x0000  0x0409 

0x01   0x0409  "Audio-Widget"

0x02   0x0409  "Henry Audio USB DAC 128 mkII"

0x03   0x0409  "2017042900BSB"

0x07   0x0409  "Henry Audio USB DAC 128 mkII"

0x05   0x0409  "Clock 2"

0x08   0x0409  "Audio-widget"

------------------------------

Connection path for device: 

USB xHCI Compliant Host Controller

Root Hub

Henry Audio USB DAC 128 mkII (VID=0x16D0 PID=0x075D) Port: 4

Running on: Windows 10 or greater

Brought to you by TDD v1.84.0, Dec 14 2015, 09:19:38

[Jaroslav Dohnal]

Hi,

very interesting findings, I agree, that could be the trouble. But why the hell MS driver never asks if the clock source is valid? Clock selector is optional I think by UAC specification, that should not make any difference and if any my guess would be to make it worse. XMOS is one clock domain only device, so thats partialy why it has the clock selector. Does windows ask for supported fs over the control endpoint channel? Did you try debugging there?  

I sadly wont be developing DSD (or anything) on AVR32 anytime soon. I wont be building WM8741 DAC as I did some listening test and the WM8741 chip doesn't sound good. I will be using different DAC chips and I will have to use 16 core XMOS as I want to try to write my own PDM modulator. AVR32 just doesnt have enough power for me anymore... Would be a interesting thing to try porting it onto the new Cortex M7 architecture :D

I also looked at the descriptor, but cannot see anything obvious or missing...

https://www.diffchecker.com/AZlpFvwA

the HID seems to be done different way and the DFU is there on XMOS, other than that...really dont know what could cause it. 

[Børge Strand-Bergesen]

Hi Jaroslav, 

I have been working quite hard with the descriptors the last few days, to no avail so far. What I have done includes:

- Removing the Widget Control interface to not be "Other device" in Windows. Should be easy to put back in again. 

- Adding the Clock selector didn't change anything, so I took it out again.

- The clock source CS2's association field could be wrong, so I tried different options

- HID had both TX and RX. We only use TX so I removed the idle RX endpoint. 

- Drew up the Units and Terminals on a schematic which seems to make good sense

- A few other things suggested by people here and there

My next suspision is that the feedback endpoint isn't defined according to the standard. I think it must be an endpoint in the audio interface, not an endpoint in its own interface. I will read the fine print and compare again with the diffchecker. 

Now, the device you're comparing with, is it known to work on the Win10 C.U. driver? Please send me the full descriptor dump in addition to the diff. 

I will probably not implement DSD on AVR32. DSD-64 should be doable, the main challenge I see is in the output circuitry. 

Børge

[Ti Kan]

I think abandoning DSD would be the death of the current audio widget. It would be quite unfortunate. Even if DSD64 is possible then that would be a major plus.  Contrast this to the Amanero, which I think is the most direct "competitor" to audio widget. But Amanero is closed source, and specifying custom USB VID/PID adds a significant chunk to the cost.

Originally I adopted audio widget as the platform of choice on a couple of my DACs because of its open source nature, which, in most instances means a lot of community input and thus new features get developed quickly.  I guess in our case it didn't work out that way.

If it's possible to switch to a different processor and achieve a pin-for-pin equivalent audio widget module, with all the features we have now, plus up to 384KHz PCM and full DSD DoP mode support, then I would be happy.  But it would be a ground-up new project, and who knows when it would see the light of day?

-Ti
-- 

Sent from my commlock

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

[Børge Strand-Bergesen]

Hi Ti, 

I'm now finally getting head above water with improved PDCA init (to prevent LR swap) and UAC2 support for the Win10 Creators Update driver. These two tasks have taken a lot of effort, and I'm honestly glad that no other FW development has been going into github at the same time. 

But now that is about to change, and I'm happy to say I've pushed my recent updates to audio-widget-experimental for all to play with. Let's keep the dialog very tight if we plan to push things to github. I will probably push a bit more code cleanup in the next day as long-term testing commences. 

This also means that the code stripping which George has promoted can very well start up again. 

Now, to DSD! 

I belive DSD-64 is within range, and that we could do DSD-128 with a bit of luck and hard work. I have tried to split DSD into smaller tasks here so that it doesn't look too monumental for only one guy. 

1 - The ability to test and track DSD data. I'd like to have a data stream which, say, sets every 19th bit and clears all others. That kind of signal can be written to file in Octave and tracked through the entire playback chain and firmware. I want to be able to generate known-good sources first. I can do a lot of tracking in FW, but I was hoping for assistance on writing the generator in Octave. It shouldn't bee too different from wavwrite().

2 - The ability to make DSD test frequencies. I've done a fair share of delta-sigma programming in Matlab/Octave, and would be happy to make a rudimentary PCM to DSD converter for test purposes on top of the DSD file generator in task 1. That way we can test sine tones, LR separation etc. 

3 - Deciding on output format from MCU. Most DACs use two data pins for DSD (and oversampler bypass PCM for that matter). I believe we should shoot for this functionality and support more than just those few DACs which can handle DSD over PCM natively. However, the SSC in the AVR32 only handles 1 data pin in and 1 data pin out. In my opinion that leaves us with a few choices:

 a) Use the SSC as-is, interlace the data bits and split them in two with external flip-flop. If the bit rate permits it, that is.

 b) Use 1x SSC + 1x SPI TX -or- 2x SPI TX

 c) Use 1x SSC + 1x USART TX -or- 2x USART TX

I've recently read up on PDCA management for SSC, but I'm not fluent in AVR32 SPI or USART hardware. If you want DSD functionality, doing a bottom-up IO study has to be part of the job sooner or later. 

4 - Adding DSD hardware. My present DACs don't have DSD hardware support in the DAC chip. I'm working on layouts which do. 

Børge