New firmware: volume control

[Børge Strand-Bergesen]

Hi guys,

There's been a request for a digital volume control in the Audio
Widget. So I set out to do some coding!

A lot of it works. But I could need a hand in Linux UAC2 testing and
finding a better random number generator.



Good news first: It works!

- This is what was missing for iOS UAC1 support. With external power
the DAC now plays on iOS with both UAC1 and UAC2!

- UAC1 and UAC2 volume and mute control protocol

- Multiplication appplies volume to audio samples (C builds with
muls.d asm instruction)

- Multiplication disabled at 0dB

- Range set to -60..0dB

- 6dB gain steps done as clean shifts

- 0.5dB gain resolution, <1dB deviation from ideal dB curve

All the code is in the audio-widget-experimental branch in github
(which took some beating during merge I'm afraid). Let me know if
there are any issues!

Binaries are in the widget_binaries repository. Both
awx_20160323_volume_control.elf and
awx_20160323_volume_control_0dB.elf respond to the volume control
protocol. The 0dB file doesn't perform multiplication.



Bad news: A couple wrinkles must be straightened out.

- In Linux (Mint17, PulseAudio) I'm able to receive control in UAC1
just fine but UAC2 doesn't respond to the volume control protocol. I
don't know if this is due to the UAC2 driver or a PulseAudio setting.
On my system Linux UAC2 does its own soft volume control rather than
communicate with the device. Hence using the 0dB file causes an
audible volume difference in Linux UAC2, where it really shouldn't!
It's quite feasible to debugh the volume control protocol on RS232 in
case you have any ideas for me to try out.

-The random number generator I put in for dithering is taking too much
time at 192ksps, so it's only written into the code for UAC1. With a
faster RNG dithering will go into all sample rates and modes.

- I wrote and tested code for storing volume setting to flash. The
flash writes are only done once in a while if the volume has changed
since the last write. But the flash writes seem to hold on to the MCU
for quite a while and therefore generate ticks and noise. It's taken
out of the code for now.

- With no flash support, the firmware defaults to -12dB gain. Some
OSes will remember the last setting they applied. Others will use the
DAC's default at -12dB. Hopefully this won't kill any power amps for
now :-) With better flash write the DAC will remember its own volume.


Cheers,
Børge

[Alex Lee]

Hi Borge,

I tested the digital volume control under Ubuntu Linux 1404 64bit.

It works under uac2.

Good work.

Alex

[Piotr Lopatka]

Hello,

I did try the volume control FW under Debian Stretch (9.0) and it does work in UAC1 mode, but not in UAC2.

Not a big problem, just feeding back.

thanks.

Piotr

[Børge Strand-Bergesen]

Thanks Alex! 

The missing volume control protocol was what kept it from working on iOS and UAC1. Now both protocols work on all OSes. In the fw it was quite tricky to come up with the casting notation which compiled into a 32x32=64 mult. Don't touch that code without verifying it in the list file.

On my Mint 17 box with mpd UAC1 has true volume control in the DAC but UAC2 has digital volume control in the host. (Not that the effect is much different, but the principle surely is.) I seem to remember more or less the same being the case on Android. I haven't yet tested volume with the preliminary Windows UAC2 driver.

The way to test this is to compare the volume control fw to the 0dB file of the same date. Both use the same volume protocol interaction with the Host, but the 0dB file doesn't perform any volume multiplication. So if the computer's volume slide influences the output on the 0dB file, this means it is the computer doing the volume change. Mind that on some systems pulling the slide all the way down will evoke mute, something the fw handles separately from the volume control multiplication.

I have a feeling Linux implements volume differently in UAC1&2. But I haven't yet told any kernel people. 

UAC1 uses primitive dithering after volume multiplication. On 192 the present RNG uses too many CPU cycles, so I bluntly disabled dithering in UAC2 for now. A faster RNG could do the trick. I just pulled one off the net more or less at random :-)

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.

[Jaroslav Dohnal]

Hi, great to see some progress.

I would definitely recommend TPDF dithering for volume regulation, you will get zero noise modulation. But I can really see MCU not having enought power for 192 and 384khz FS... I gues you did disable all the other non important RTOS tasks.