Open-source USB interface: Audio Widget

I'm a strong believer in no SRC in inline music. Rather trust the digital filter inside the DAC and hope the digital department talked to the analog department before the chip was taped out.

But for testing I need to run audio of my own choice at various sample rates and know that it's supposed to sound the same. The content is typically low in overtones. So no harmonicas, violins and saxophones. It's way easier to detect in Enya, flutes and 2nd movements of piano music. I go mad if I have to listen to pure sines for very long.

Demian, your observations match what most people have; very rare noise, if any. I just happen to take every observation of anything off the chart as a challenge :)

Børge
 
Member
Joined 2004
Paid Member
I have a headache ...
Is much better, but not perfect.



Summary:
AB1.2 works better with fw audio-widget-2012-11-08.elf for me.
I tested about 40 files in 192k. 90 percent of them is OK.
With fw awx_20121206.elf there is no change, there is often a metallic sound.

Later I'll check other files from Gimell records on linux and windows7. (different formats)

Cheers,
Zumbik

I'm getting similar results on 192 KHz. It doesn't look like the feedback is working for some reason. The momentary frequency isn't changing as it should. Its working normally on 88.2, 96 and 176. I have heard no obvious issues. It always shows the 7.17 feedback format. I'll dig deeper tomorrow.
 
Last edited:
I'm getting similar results on 192 KHz. It doesn't look like the feedback is working for some reason. The momentary frequency isn't changing as it should. Its working normally on 88.2, 96 and 176. I have heard no obvious issues. It always shows the 7.17 feedback format. I'll dig deeper tomorrow.

Daniel,

I'm hoping to put in a bit of coding time tonight. Please let me know what you observe vs. what you expect.

To get the feedback as good as possible it's necessary to understand the code on the computer side too and how the packet size is calculated. My question, which I hope to answer soon, is "What does it take in terms of feedback data to make the PC increase or decrease the packet size?"

Børge



Nikolay wrote me:

You may found how to calculate packets size in audiotask.cpp and .h files.

void AudioFeedbackTask::processBuffer(ISOBuffer* nextXfer) - recieve feedback value and
int AudioDACTask::FillBuffer(ISOBuffer* nextXfer) - fill packets for sending to DAC

Then got this info from Daniel a couple days back. Haven't yet had the time to look at their code. Hope to ponder on this tonight.

https://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=blob;f=sound/usb/endpoint.c

In particular, check the lower half of the function
snd_usb_handle_sync_urb() which is called when a feedback packet is
received. Apart from dealing with different format shifts, it sets
ep->freqm to the value in the packet.

This value is referred to in snd_usb_endpoint_next_packet_size() which
also keeps around the unused lower 16 bits for the next iteration of the
calculation to not loose precicion. The return value of this function is
then taken as the size of the next packet so be sent out.
 
I've tried to read up on some USB documentation and I'm left with some questions about the nature of the feedback system. There are links to highly recommended reading below.

Question: could someone please explain the 16.16 feedback format used in our UAC2 firmware?

USB documentation specifies the feedback data from the DAC to be
1) Full-speed: 10.14 format describing number of samples per USB frame (1ms).
2) High-speed: 16.16 format describing the number of samples per USB microframe (=1/8 frame =125µs). (Actually, it's 12.13 format with 4 MSB '0's and 3 LSB '0's inserted)

("10.14" means a real number which is shifted up by 14 bits and then converted to 24-bit integer, using 14 LSBs to convey after-the-decimal-point fractional data.)

Example: 44.1ksps music uses 44.1 samples per 1ms frame = 5.5126 samples per 125µs microframe. Q: Am I right that the full-speed translation should be round(44.1*2^14)=722534, and that the high-speed translation should be round(44.1/8*2^16)=361267 ??

The Linux driver code (https://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=blob;f=sound/usb/endpoint.c l:1073) does automatic up/down shifting to guess the feedback format. Nikolay's Windows ASIO code divides by 65536.0f in audiotask.h l:88.

The reason I'm asking is this: In audio-widget:uac2_usb_specific_request.c l:279 etc. FB_rate is set as samples per ms and shifted up 14 bits. That rimes perfectly well with the full-speed format. As does audio-widget:uac2_device_audio_task.c l:366 where 3 bytes are used to send the FB_rate variable as 10:14 data.

BUT: In line 409 for the High speed code there is no data shifting, so that samples/frame stored in .14 is sent as samples/microframe in .16. I'm wondering what I've misunderstood, because to divide by 8 (frame -> microframe) is a shift of >> 3, while a conversion from .14 to .16 is a shift by << 2. So I was kind of expecting the High speed code to do a > 1 of the internal FB_rate variable before sending it out as samples/microframe.

If I'm wrong, great, but please let me know where I err. This calculation probably has little to do with Linux 192ksps playback bugs because of its automatic format adaption. And 192 seems to be very stable in Windows with the explicit division by 2^16.

At present the feedback system adds 2^6 (FB_RATE_DELTA=64) to the internal FB_rate variable in .14 samples/frame format. The host obviously uses an integer number of samples per frame or microframe. I'm a bit worried that it some times takes the firmware too long to cause the the host's number of samples per frame/microframe to change. Once I've understood the above mechanisms better I'd like to have the firmware explicitly request +-1 samples added to the samples count. Such a take on things will be sample rate dependant.


I'm basing the above calculation on:
http://www.usb.org/developers/docs/usb_20_110512.zip Section 5.12.4.2 of usb_20.pdf
http://developer.apple.com/library/mac/#technotes/tn2274/_index.html
http://www.usb.org/developers/devclass_docs/Audio2.0_final.zip Section 3.16.2.2 of Audio20_final.pdf and Section 2.3.1.1 of Frmts20_final.pdf

Børge
 
Last edited:
I'm a strong believer in no SRC in inline music. Rather trust the digital filter inside the DAC and hope the digital department talked to the analog department before the chip was taped out.
sorry, that's a big mistake. Silicon is expensive. No on-chip digital filter will ever come close to the sophisticated algorithms (and large memory footprint, extreme precision, etc) used by the best software SRC... (such as sox).
 
Feedback Format = 15.17
Feedback Format = 7.17

"Feedback Format" is 7.17 was 15.17 (the same file) Why?

Cheers,
Zumbik

Zumbik, do you still have the same issues as in your post from a few days ago?

I suspect the 15.17 format may correspond to what I believe is one right-shift too little. (See my previous post.) 15+17=32, so that's 4 bytes of feedback. UAC2 uses 16.16.

As to the 7.17 format I don't know. 7+17=24, so perhaps only 3 bytes of feedback are generated or interpreted. UAC1 uses 3 bytes of feedback but does it in 10.14 format. That is properly detected on my system, though. I have not been able to replicate the 7.17 issue.

The Mac purchase didn't pan out today, so I decided to set up another Linux test box. I've got a Linux Mint 12-64 on a Core2-duo-3GHz running kernel 3.0.0-12-generic with mpd running as user.

Q: when I change between UAC1 and UAC2, which steps should I take in Linux? I did change from UAC2 to UAC1 without much other ado than resetting the AW, and the files under /proc/asound/card1 disappeared. Being a Windows user I rebooted (!) and the files reappeared. But before that step I did try killing and restartig mpd, which did nothing to bring them back.

Cheers,
Børge
 
BUT: In line 409 for the High speed code there is no data shifting, so that samples/frame stored in .14 is sent as samples/microframe in .16. I'm wondering what I've misunderstood, because to divide by 8 (frame -> microframe) is a shift of >> 3, while a conversion from .14 to .16 is a shift by << 2. So I was kind of expecting the High speed code to do a > 1 of the internal FB_rate variable before sending it out as samples/microframe.

Børge

But you also need to take into consideration that the AW firmware sends every OTHER microframe (ie every 250uS, NOT 125uS).

Alex
 
borges said:
Zumbik, do you still have the same issues as in your post from a few days ago?
Right now I make more tests on a fresh Linux installation.

borges said:
Q: when I change between UAC1 and UAC2, which steps should I take in Linux?
A: You don't need change nothing in linux.

borges said:
I did change from UAC2 to UAC1 without much other ado than resetting the AW, and the files under /proc/asound/card1 disappeared.

If you have a problem, type aplay -l
For me, it looks like this:
Code:
**** List of PLAYBACK Hardware Devices ****
card 0: AB12 [QNKTC USB DAC AB-1.2], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: SB [HDA ATI SB], device 0: ALC892 Analog [ALC892 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: SB [HDA ATI SB], device 1: ALC892 Digital [ALC892 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

If you press RESET button on the AB-1.2 aplay-l gives the result:

Code:
card 0: SB [HDA ATI SB], device 0: ALC892 Analog [ALC892 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 1: ALC892 Digital [ALC892 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: AB12 [QNKTC USB DAC AB-1.2], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

In the first case:
Code:
/proc/asound/card0

in the second case:
Code:
/proc/asound/card1

Will be more easily if you swich off completely internal sound card.
 
But you also need to take into consideration that the AW firmware sends every OTHER microframe (ie every 250uS, NOT 125uS).

Alex

Yes, that's where I thought I missed out too! Yet, when I read UAC2 documentation, /8 or *125us seem fairly static, and there is little reference to the microframes actually used. Please let me know if you have such references to the spec.

I'll try to change from 15.17 to 16.16 in experimental firmware and see what happens. On Linux I expect it to work just as before, the computer will simply perform less shifting. On Windows I'll add debugging to the driver and check.


Børge
 
I finished my preliminary tests on fresh linux, twice.
Configuration: Ubuntu minimal, kernel 3.5.0-19-generic, or 3.7-generic, alsa 1.0.25, fw audio-widget-2012-11-08 (only), UAC2, quirk = none.

Feedback format = 7.17 on UAC2 at 44.1, 96, 192

If I have do another test FW, I need information about which version and with what parameters.
Later I'll check how it works on xbmc, and UAC1 too.

I forgot ... All files work perfectly!
 
I finished my preliminary tests on fresh linux, twice.
Configuration: Ubuntu minimal, kernel 3.5.0-19-generic, or 3.7-generic, alsa 1.0.25, fw audio-widget-2012-11-08 (only), UAC2, quirk = none.

Feedback format = 7.17 on UAC2 at 44.1, 96, 192

If I have do another test FW, I need information about which version and with what parameters.
Later I'll check how it works on xbmc, and UAC1 too.

I forgot ... All files work perfectly!

Which firmware was this with? I did PM you a quite experimental awx_20121213.elf which didn't go public due to bad 88.2 performance on Windows.

A while ago you were having some issues with 192 on Linux. What has changed? The firmware, the computer or both? It would be very interesting to correlate the improvement you observe with the changes made.

What may cause Linux to detect 7.17 format I have no idea. At 192 there are 24 samples per 125µs microframe, so It can't be counting the non-zero non-fractional bits which would be 5.

Cheers,
Børge
 
Last edited:
My board. This week will have a new enclosure. I use UAC2 on Windows 7-64 (No problems).
 

Attachments

  • PC090888_2.jpg
    PC090888_2.jpg
    905.2 KB · Views: 260
Now the plan is to use as USB-SPDIF converter, and from time to time as USB DAC. Next, new module, I will add to my Buffalo, I do not know. Other plans, maybe after X-mas.
My new panels will be, water cutting, tomorrow.
 

Attachments

  • aw_front_1.jpg
    aw_front_1.jpg
    28.9 KB · Views: 233
  • aw_back_1.jpg
    aw_back_1.jpg
    21.4 KB · Views: 228