I am very interested, if you could describe what is this register doing, how to set it, what are the effects and perhaps side effects, trade offs, etc... anything that is not already described in the data sheet, while not crossing the NDA line.
Just telling you "added" this register is zero information. I don't even understand if your comments are about the 9038 (as suggested by the app name) or about the 9822 which you promoted lately here.
Come on, the value entered into the window shows Ivan changed the value from the default and he explains why he did it. For me it's a valuable information.
Sorry, I don’t know the data sheets by hard and I am one ocean away from them, for the moment. Is that register described in the data sheet? For which chip (app windows says 9038, drop downs say ADC). I thought (my memory could be bad) the ESS ADC has 2 channels that can be combined in 1 (mono), are there in fact 4 ADC channels?
AKM 5574 & AKM 4490 44.1...768kHz (ADI-2 Pro Fs Loopback)
Some asked about UAC2 & WASAPI exclusive mode using 768kHz...
so see attached... 😀 😱
for measurements up to 100kHz OK, while DSP based optimized for 384kHz SR
Hp
Some asked about UAC2 & WASAPI exclusive mode using 768kHz...
so see attached... 😀 😱
for measurements up to 100kHz OK, while DSP based optimized for 384kHz SR
Hp
Attachments
Other than the stinking’ noise shaping in 2 and 3, which makes most of the audio ADCs improper for measurements, what’s special here? I guess 1 shows the frequency responses at SR up to 784k?
Yes, as file names should tell...
in other words above 192khz, AKM has not that yellow on the egg 😱
My clean results of bitperfect MS UAC2 playback at 512kHz/32b/2ch, 768kHz/32b/2ch, 3.9MHz/16/1ch were linked a few pages ago https://www.diyaudio.com/forums/equ...rumentation-applications-105.html#post6767736 . The tests are all in digital domain, therefore the bitperfection is proven.
Analog loopback tests cannot reveal bitperfection of the chain, but at least they show the samplerate is supported. The UAC2 driver supports any samplerate the device reports. I have not tested multiple packets per microframe (around 12MHz/16b/1ch max as HS isochronous allows maximum of three 1024bytes packets per microframe) because the linux UAC2 gadget does not support it (likely yet).
Testing duplex operation now, it will take a while, I have to make a working wasapi-exclusive recorder to wav first.
Analog loopback tests cannot reveal bitperfection of the chain, but at least they show the samplerate is supported. The UAC2 driver supports any samplerate the device reports. I have not tested multiple packets per microframe (around 12MHz/16b/1ch max as HS isochronous allows maximum of three 1024bytes packets per microframe) because the linux UAC2 gadget does not support it (likely yet).
Testing duplex operation now, it will take a while, I have to make a working wasapi-exclusive recorder to wav first.
AK4493 at oct/hex sampling speeds - oversampling filter issue?
IMO the "newer" AKM chips AK4490/93 with official 768kHz support are just the old 192kHz convertors with newer digital input capable of 768kHz framerate/49MHz bitrate. The results at octo/hexa are... what they are.
50kHz directly behind AK4493@768kHz
vs. 350kHz directly behind ES9038Q2M@768kHz
"directly" mean at DAC's pin before LPF?
Sorry for the bad picture from old HP, newer scope is at another room.
This is AK4490@768 at pin 25:
Attachments
Last edited:
Sorry, I messed up that picture, already forgot what I tested in my post https://www.diyaudio.com/forums/equ...-oversampling-filter-issue-4.html#post6659154 . That was 48kHz@192kHz with oversampling disabled - as one would expect it.
The result of that thread was that AK4490/3 do no oversampling at oct/hex modes.
Please try 96kHz @384 samplerate at oct mode (e.g. MCLK x128 IIRC). Then e.g. 88kHz@ 192kHz and @384kHz - like I did in https://www.diyaudio.com/forums/equ...-oversampling-filter-issue-5.html#post6659176 . The measurements in that thread were by three independent posters.
The 88kHz sample is better viewed with single-run time base.
The result of that thread was that AK4490/3 do no oversampling at oct/hex modes.
Please try 96kHz @384 samplerate at oct mode (e.g. MCLK x128 IIRC). Then e.g. 88kHz@ 192kHz and @384kHz - like I did in https://www.diyaudio.com/forums/equ...-oversampling-filter-issue-5.html#post6659176 . The measurements in that thread were by three independent posters.
The 88kHz sample is better viewed with single-run time base.
Last edited:
50kHz is non-integer samples per period and thus moving. Please try integer divider (e.g. 48kHz) or single-shot. IMO you will not see any oversampled points (only the original 16 points per period), unlike 48kHz at samplerate <=192kHz.
Last edited:
Please can you read that thread AK4493 at oct/hex sampling speeds - oversampling filter issue? and post there your results? They are fundamentally different from scope shots of mine, KSRT and bohrok2610 - we all got identical results. There must be something different. Thanks.
Finally I got to the duplex test, using Henrik's Rust WASAPI loopback example wasapi-rs/loopback.rs at master * HEnquist/wasapi-rs * GitHub modified for exclusive access.
Attached is clean spectrum of 350kHz signal generated on RPi at 768kHz/2ch/32bits, captured through MS UAC2 driver on Win10 by the loopback application in Wasapi exclusive and played back to the RPi via the same UAC2 driver again in WASAPI exclusive, to be captured and "spectrogrammed" on the RPi. Duplex operation at close to maximum UAC2 bitrate is bitperfect too.
Java does not support WASAPI. I am working on a WASAPI-exclusive java connector for John Mulcahy to use. Still learning, I am not an ingenious programmer like Hernik, it will take a bit.
What quirks specifically of the UAC2 driver have been discussed here? Any practical experience? IME it behaves quite nice, any samplerate/sample size, correctly responds to feedback control, duplex operation. It treats the USB configuration very strictly (max packet size value, explicit feedback value, defined output terminal type, etc.) but when the UAC2 device is coded to satisfy the rules, it's quite performant.
The linux UAC2 driver is way more lenient, obviously accepting the win10-finetuned UAC2 devices. OSX is somewhere in between but tested OK to accept them, including correct response to async feedback.
Attachments
Earlier in another thread I mentioned that Windows UAC2 driver has low tolerance to descriptor errors (Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter).
Another minor issue I have struggled somewhat with is that the Windows UAC2 seems to not accept sync FB at minimum intervals neither in FS nor HS. If I send sync FB at every SOF Windows disregards every one regardless of the frame parity. So my current FB scheme sends sync FB only after receiving IN token from the host. This in practice means that the interval is doubled (every other SOF). I'm still not sure if this problem is due to the host or something to do with STM32. Anyhow this is not really a problem as even the doubled FB interval is more than sufficient.
That's true, but fixing the device solves the problem. I am not talking about legacy devices, but about devices being developed now and in the future. No reason to keep errors in their descriptors. If devs have no source code to fix some broken library by the chip vendor, well... that's a wrongly chosen vendor in my view.
I have not tested FS, but for the HS this works fine:
EP-OUT: bInterval=only 1-4, not more (documented by MS)
sync EP-IN: bInterval= only 4 (I think it's even mentioned in MS docs)
feedback value - average number of samples per packet, not per uframe. So for EP OUT bInterval=4 the number corresponds to 1ms, for bInterval=1 to 125us (1/8th of the number). The linux UAC2 driver identifies the corresponding timeframe automatically, windows UAC2 just ignores the "wrong" feedback value and makes no changes in packet size (BTW just like OSX).
Code:
@@ -128,8 +130,13 @@ static void u_audio_set_fback_frequency(enum usb_device_speed speed,
* byte fromat (that is Q16.16)
*
* ff = (freq << 16) / 8000
+ *
+ * Win10 and OSX UAC2 drivers require number of samples per packet
+ * in order to honor the feedback value.
+ * Linux snd-usb-audio detects the applied bit-shift automatically.
*/
- freq <<= 4;
+ ep_desc = out_ep->desc;
+ freq <<= 4 + (ep_desc->bInterval - 1);
}
Last edited: