Switching sampling frequency for Amanero USBaudio

[zlmikhail]

From driver version 10.245 to the current release, there is a bug with switching the signal sampling frequency for devices based on the Amanero chip.

The problem occurs regardless of the underlying USB drivers used (USBD 10 or 11). Since the release of USBaudio driver 10.245, the following error has been observed on Amanero USB audio devices. The device does not switch from the first time to the sample rate of the material being played. It is necessary to repeat the playback of the track with the same frequency in order for the sample rate switching to be successful. And so with any change of track with a different sample rate. For devices based on XMOS chips, there is no such problem. At the moment, I have to use driver 10.244 which works stably.

[zlmikhail]

Descriptors for Amanero device

[zlmikhail]

Descriptors for XMOS device

[w.m.brul]

Ensure that Lars Erdmann 10.249 USB driver set and USB Audio 2.0 Adapter are properly installed.

Enable tracing for the USBAUD2.SYS driver i.e. add the following to config.sys and reboot:

TRACEBUF=2048 /M=W,Q,NODTI /D=ALL TRACE=ON 238

Open the trace tool and do File-Recapture Buffer which will clear the trace buffer.

Play the 44100s2.wav file (plays for 2 seconds) and play the 48000s2.wav file (plays for 2 seconds).

Do File-Recapture Buffer again and this time save the formatted trace. Attach that file here.

Question: Did the reported problem occur?

[w.m.brul]

The modification of config.sys must be split into 2 lines:

TRACEBUF=2048 /M=W,Q,NODTI /D=ALL

TRACE=ON 238

[zlmikhail]

Good day! Thanks for responding to my problem. Attached is a trace made according to your instructions. I checked beforehand that the drivers meet your requirements. Installing OS Arca is fresh, nothing more.

In the case of using USBAUD2 drivers (ver. 245-249), sampling frequency switching occurs with a delay of one track, i.e. if you try to play a track with a frequency of 48kHz, then switching will occur either when the same track is played again or when playing ANY other track, regardless of its frequency. Before the start of capturing events for the trace, the device was in the 48kHz sample rate mode, the first file was played at a frequency of 44.1kHz, and the device switched the frequency at the start of playback because before that a file with a frequency of 44.1 kHz was played once, which did not switch the frequency, then I played the track with a frequency of 48 kHz which did NOT change the frequency of the device (if I tried to play again, the frequency would change successfully).

The problem manifests itself on both the native OS/2 kernel and the OS/4 kernel, and the symptoms do not depend on the version of the underlying USB drivers (USBEHCD,USBD).

It is noteworthy that I also experience problems with the operation of audio devices with an Amanero chip in the XHCI port on USBXHCD drivers (versions 12.14, 12.13). In my case, the problem manifests itself after successfully playing a track of any length and resolution, trying to play the next track results in only loud noise being played. At the same time, when installing an audio device with an XMOS chip in the same port with an XHCI controller, there is no such problem,

[w.m.brul]

Since version 10.245 the USBAUD2.SYS driver no longer sets alternate interface to 0 (just before setting the sampling frequency). Since then, setting the sampling frequency occurs once the interface is active. Unfortunately some devices like the amanero don't respond to sample rate changes while the interface is active. In amanero-test-20230829.zip I have added an extra setting of the sampling frequency just before setting the alternate interface.

To test replace the 10.249 version USBAUD2.SYS and USBAUD2.SYM files with the ones contained in amanero-test-20230829.zip and reboot your system.

[zlmikhail]

Thankful! Based on my own experience and experiments on different equipment, the issue with changing the sampling frequency on Amanero chips has been resolved, switching occurs the first time, and even the already familiar click at the beginning of playback is gone.

Thanks again for your help.

I apologize for being persistent. You can find out the answer to another question. Is it possible to improve the performance of Amanero audio devices on USB 3.0 ports with AN's USBXHCD drivers? As I wrote earlier, on the ports of the Texas instrument TUSB7320 controller, an audio device on the XMOS chip normally works, but the device on the Amanero chip normally plays only the first track, instead of the next track, only noise sounds. Perhaps we should just wait for a better USBXHCD implementation from AN?

[w.m.brul]

Lars reviewed my change and discovered that I introduced a minor bug which he fixed. So I have prepared amanero-test-20230905.zip for you to test. Replace USBAUD2.SYS and USBAUD2.SYM files with the ones contained in amanero-test-20230905.zip and reboot your system. Follow the test procedure in comment:1 and attach the formatted trace.

About your question "Is it possible to improve the performance of Amanero audio devices on USB 3.0 ports with AN's USBXHCD drivers?". There is not much I can do. None of my systems have USB 3.0 ports nor do I have such an Amanero audio device. Sorry.

[zlmikhail]

I did the trace as you requested.

[w.m.brul]

Thank you. The trace confirms that it works. Perhaps you could follow the test procedure once again but this time with AN's 12.14 drivers and the Amanero audio device connected to a USB 3.0 port so that I can compare both situations. This might give me a clue as to what causes that noise problem. Append that trace here and report back the playback results.

[Lars Erdmann]

Will be in the next release 10.250

[zlmikhail]

Trace from the XHCI controller port

[w.m.brul]

Thank you for the trace from the XHCI controller port. I compared both traces and alas it did not give me a clue as to what causes the noise problem (The Amanero audio device works similarly well according to both traces).

[zlmikhail]

Do I understand correctly that you also consider crackling and noise to be most likely a problem of data transmission at the level of the XHCI controller driver? It is not clear then why such a problem is not observed for XMOS-based devices.

[w.m.brul]

Do I understand correctly that you also consider crackling and noise to be most likely a problem of data transmission at the level of the XHCI controller driver? It is not clear then why such a problem is not observed for XMOS-based devices.

I don't know. The problem could well be in our driver. Right now I am working with Sergey who has an ArcaOS 5.1 system with both EHCI and XHCI controllers. His USB 2.0 audio device 20b1:3076 works for sampling rates up to 96 kHz but for 192 kHz it produces noise or silence. For 192 kHz the formatted trace shows that playback starts with an incorrect number of samples being sent dependent upon the previous playbacks sampling frequency. I fixed that and prepared amanero-test-20230928.zip for you to test too. Replace USBAUD2.SYS and USBAUD2.SYM files with the ones contained in amanero-test-20230928.zip and reboot your system. Follow the test procedure as described in comments:1,2 and attach the formatted trace. Report whether or not this works for you too.

[zlmikhail]

I also conduct my experiments on ArcaOS 5.1 (I also check the work on the previous version of ArcaOS 5.0.7 and on the OS4 kernel), the result is the same everywhere. I attached another photo to the trace file, this is the error that I get if I play several files despite the crackling and noise, the error is the same and contains the same data.

[w.m.brul]

I also conduct my experiments on ArcaOS 5.1 (I also check the work on the previous version of ArcaOS 5.0.7 and on the OS4 kernel), the result is the same everywhere. I attached another photo to the trace file, this is the error that I get if I play several files despite the crackling and noise, the error is the same and contains the same data.

As a long shot I increased the number of isochronous buffers from 3 to 8 (the maximum) and prepared amanero-test-20231009.zip for you to test. Replace USBAUD2.SYS and USBAUD2.SYM files with the ones contained in amanero-test-20231009.zip and reboot your system. Follow the test procedure as described in comments:1,2 and attach the formatted trace. Report whether or not this works now for you.

[zlmikhail]

I apologize for the delay (higher power circumstances). The report is attached. I didn't find any significant changes. I also tested the operation of the USB Audio device on XHCI controllers from different manufacturers (Intel, Texas Instruments, VLI), as a result, on the Intel controller the operation of the audio device was the best, rare clicks and minor distortions were observed, there was no terrible noise after changing the first track. But all controllers have one problem - often, when changing or stopping a track, the system crashes into TRAP 000e (the same as in my previous attached report).

[zlmikhail]

Recently I was able to get back to testing the drivers that you kindly provided at my request. For a long time I did not have the opportunity to do this fully. At the moment, I have discovered one problem that appears on drivers above 10.245, including the latest beta version 10.250. This problem does not depend on the controller (XHCI or EHCI) to which the Amanero USB audio device is connected. The error manifests itself in the fact that at an arbitrary point in time, but usually in the first 2 minutes, file playback suddenly stops. In this case, no errors appear, playback simply stops and the player timer freezes. I filmed and attached a trace of the case when the playback stopped at 24 seconds of playback.

[w.m.brul]

Trace 241023.ftf shows that you did not have the proper trc00ee.tff installed in your os2\system\trace directory. Lars Erdmann 10.249 USB Audio Drivers must have been properly installed first. Then replace USBAUD2.SYS and USBAUD2.SYM with the ones contained in amanero-test-20231105.zip and reboot your system. Follow the test procedure described in comments:1,2 and attach the formatted trace. Report back your results.

[zlmikhail]

I have attached the TRACE, I hope it is correct. I reinstalled the 10.249 driver, then manually copied TRC00EE.TFF, just in case, and replaced the UAC2.0 driver with the one you provided. With the new driver, the symptoms when playing sound on a UAC2.0 device persisted. In the latest ArcaOS system, freezes occur at random times when playing a track when a device is connected to a port with an EHCI controller. When connected to ports with an XHCI controller, there is still a crackling noise when playing sound. It manifests itself differently on different UAC2.0 devices (Amanero, XMOS), but these distortions are completely obvious. I hope there is some opportunity to draw AN's attention to the problem with isochronous data transfer through their driver. Personally, I have been blocked from entering Mantis after I left my last report on this topic there.

[Lars Erdmann]

As a test and in case you have a USB 2.x HC controller (if you need to load USBEHCD.SYS in config.sys), have you ever tried to use our USB stack (of course, without being able to use USB 3.x) together with our USB audio client drivers ? If yes, does the problem also occur with our USB stack ?

[Lars Erdmann]

USB drivers preominary version 10.250

[Lars Erdmann]

Try the attached. You will still need to replace the USB audio drivers with the ones that Wim has provided here recently (Wim has not yet checked in his latest changes).

[Lars Erdmann]

What I can see from your trace is that "TimerInterruptHandler?" is called on and on, without any new data being fed to the device, in short succession (before you or the system eventually closes the device). That is not what should happen and it certainly does not happen on my system with the 10.250 driver set that I have now attached.

[zlmikhail]

I reproduced the playback stuck error on a clean ArcaOS system with the bundled HC drivers from ArcaNoae?. I considered this error worthy of publication since the average user may encounter it.

For my needs, I made a minimalistic system image for booting over the network via QSINIT with the native OS/2 kernel from ArcaNoae? and with the OS/4 kernel, in this image all unnecessary devices and services are disabled, the system runs directly into the PM123 player (SET RUNWORKPLACE=C: \Programs\pm123\pm123.exe) all other settings are untouched, and, yes, there are no freezing problems when using this system image. But this experience cannot be considered pure) For testing purposes, I always use an environment with a fresh OS installation on 2 different PCs.

Lars, thanks for the new version, I will check it and try to replace the HC drivers with yours on the test system.

I requested that ArcaNoae? open a Mantis ticket that they had previously closed. Since I have fulfilled the formal conditions for this. I hope they do this and pay attention to the problem with the isochronous mode.

[zlmikhail]

Replacing the HC controller drivers with the provided 10.250 did not solve the problem of playback freezing on a clean ArcaOS 5.1 system.

[Lars Erdmann]

Does the XMOS MTech device work ?

I am using PM123 Version 1.43, but I am using an XMOS USB audio 2.0 device. I have been playing a single track for more than 21 minutes, no freezes, with the time info properly advancing.

I cannot reproduce your problem with the Anamero device. I wonder if the problem is device related or if there is another problem.

[zlmikhail]

I would like to believe that the problem is in the device, but M2Tech behaves the same way. Yesterday I found out that another user has exactly the same problem on devices with XMOS chips (he discussed it with Win). He solved it by choosing a special USB cable to connect the device, but I also have this problem when I connect the ​https://www.m2tech.biz/prodotti/dispositivi-usb-pen/hiface-two/ directly to the PCIE card port, without a cable.

UPD: The most interesting thing is that playback freezes (associated with the failure of UAC devices) began not with the advent of a new USB HC driver or USB Audio driver, but with the transition to ArcaOS 5.1. I specifically tried to roll back the system image to 5.05 (my previous version), installed the latest versions of USB 12.14 and USB Audio 10.250 and so far I have not noticed any problems.

[w.m.brul]

UPD: The most interesting thing is that playback freezes (associated with the failure of UAC devices) began not with the advent of a new USB HC driver or USB Audio driver, but with the transition to ArcaOS 5.1. I specifically tried to roll back the system image to 5.05 (my previous version), installed the latest versions of USB 12.14 and USB Audio 10.250 and so far I have not noticed any problems. I made some changes. LightLock? calls instead of SpinLock? calls. WakeUp? one thread only. Revamped Audio 1.0 driver playback functionality similar to Audio 2.0 driver. This fixes the PM123 problem with stability of sound and jerky progress bar (reported by Igor on os2world). No hiccups and hops backwards anymore. I could reproduce and fix that problem on my laptop with ArcaOS 5.0.6 and 12.14 drivers installed. To test use an ArcaOS system with 12.14 drivers installed. Install usbdrv250.zip audio drivers. Replace USBAUDIO.SYS, USBAUDIO.SYM, USBAUD2.SYS, USBAUD2.SYM in \MMOS2rectory and replace TRC00EE.TFF in \OS2\SYSTEM\TRACE directory. Are theres still hangs?

[w.m.brul]

I did some changes to keep the current wav playing while stopping an earlier paused wav.

To test use an ArcaOS system with 12.14 drivers installed. Install usbdrv250.zip (preliminary version) audio drivers. Replace USBAUDIO.SYS, USBAUDIO.SYM, USBAUD2.SYS, USBAUD2.SYM in \MMOS2rectory and replace TRC00EE.TFF in \OS2\SYSTEM\TRACE directory.

[w.m.brul]

I made some changes: Fixed 8-bit volume. Reduced playback/feedback latency.

To test use an ArcaOS system with 12.14 drivers installed. Install usbdrv250.zip (preliminary version) audio drivers. Replace USBAUDIO.SYS, USBAUDIO.SYM, USBAUD2.SYS, USBAUD2.SYM in \MMOS2 directory and replace TRC00EE.TFF in \OS2\SYSTEM\TRACE directory.

[Lars Erdmann]

Hi Wim,

just built the latest version and test with USB audio 1 as well as 2.

SVN rev 2477 and 2478: Seems to still work ok but for both audio 1 and audio 2 I hear some slight clicks every now and then (missed samples). I am not sure if this is because of the playback/feedback latency change or anything else. But it was better with older versions.

[Lars Erdmann]

Hi Wim,

in SVN rev 2475 and 2476 you changed the logic: "changes to keep the current wav playing while stopping an earlier paused wav."

Before that change it was like this: play file A. While it plays, start to play file B. If playing file B ended or was stopped the system would resume playing file A where it left off.

Now, if I play file A and while it plays I start to play file B, it will delay playing file B until file A is played to completion or stopped.

Was that change intentional ? I think both solutions have their advantages and disadvantages but I found the older solution more intuitive (as both files would appear to be selected/active).

In both cases, the limiting factor is that an USB audio device can only play one stream at a time but of course, that cannot be circumvented.

[w.m.brul]

Replying to Lars Erdmann:

Hi Wim,

just built the latest version and test with USB audio 1 as well as 2.

SVN rev 2477 and 2478: Seems to still work ok but for both audio 1 and audio 2 I hear some slight clicks every now and then (missed samples). I am not sure if this is because of the playback/feedback latency change or anything else. But it was better with older versions.

Hi Lars,

I changed the way feedback works for Sergey to try and test. At the same time I changed the number of playback/feedback buffers back from 8 to 3. You could try and increase the number of playback/feedback buffers to see if those slight clicks disappear on your system. On my system just 3 buffers were sufficent.

[Lars Erdmann]

Hi Wim,

I did as you suggested and reverted back to 8 buffers and yes it fixed the problem for both, audio 1 and 2. Do you want me to check it in ?

[w.m.brul]

Replying to Lars Erdmann:

Hi Wim,

I did as you suggested and reverted back to 8 buffers and yes it fixed the problem for both, audio 1 and 2. Do you want me to check it in ?

Yes.

[w.m.brul]

Replying to Lars Erdmann:

Hi Wim,

in SVN rev 2475 and 2476 you changed the logic: "changes to keep the current wav playing while stopping an earlier paused wav."

Before that change it was like this: play file A. While it plays, start to play file B. If playing file B ended or was stopped the system would resume playing file A where it left off.

That is still the way that it works on my system. However when I did not wait for playing file B to end, and stopped file A instead, then file B would become silent (while still increasing its shown elapsed time till the end) but did not really end. After that the system behaved oddly as in which stream to pause and which stream to activate and having dead wav files.

Now, if I play file A and while it plays I start to play file B, it will delay playing file B until file A is played to completion or stopped.

On my system it does not do that. But there is still something strange going on when double clicking on audio files.

Was that change intentional ? I think both solutions have their advantages and disadvantages but I found the older solution more intuitive (as both files would appear to be selected/active).

Yes. However it still seems that the driver gets confused in which stream to deactivate and which stream to activate.

In both cases, the limiting factor is that an USB audio device can only play one stream at a time but of course, that cannot be circumvented.

[zlmikhail]

Hello. Wim and Lars, good day.

I can confirm that now audio playback on a UAC 2.0 device connected to the XHCI port occurs without distortion, switching tracks in all formats occurs normally. But playing a track for about a minute most often results in my system completely freezing or the PM123 player freezing. I'll try to build another configuration tomorrow and install the system on it for testing. In any case, I thank you for this result, it gives me confidence that the UAC 2.0 + XHCI problem will be solved.

[zlmikhail]

Testing on another system with different XHCI controllers revealed that the problem of sound artifacts persisted. Sound playback was accompanied by a crackling sound when connecting the UAC 2 Amanero device to the XHCI controller built into the motherboard (Silicon semiconductor) and an external PCI-e card with an XHCI VLI controller. Yesterday I tested playback on a system with another PCI-e controller; it complies with the USB 3.2 SS 10Gbit standard, and perhaps this is why no artifacts were detected when working with it.

A problem with freezing or falling out with a critical error was also identified. Most often it occurs when playback is stopped. Those. It is enough to press stop several times in the player, and the system crashes into TRAP000e in the USBXHCD module

[zlmikhail]

It's possible that Arca Noae's 12.15 driver fixes XHCI, but I can't test the new driver because I don't have it.

[Lars Erdmann]

I had a chance to test with the 12.15 drivers. However, they don't fix the problem:

1) I plugged in a USB audio 2.0 device into a USB 3.0 only port and used the 12.15 driver set and our USB audio drivers (USBAUD2.SYS in that case) to play an .MP3 file.

2) While I played that file, I moved the USB mouse. The sound immediately started to stutter, it was obviously interrupted by the system handling the interrupts from the HC controller the USB mouse was connected to (which was on another HC controller, not the one servicing the audio device)

3) when I stopped playing the file, the system crashed with a trap in USBXHCD (Version 12.15):

Exception in module: USBXHCD 
 TRAP 000e       ERRCD=0002  ERACC=****  ERLIM=******** CPU=01 
EAX=00000000  EBX=f8f3edc0  ECX=70300000  EDX=70300000 
ESI=b8f70004  EDI=f51b7209  EBP=f740aec8  FLG=00010282 
CS:EIP=0168:f8f1cc83  CSACC=c09b  CSLIM=ffffffff 
SS:ESP=1550:f740ae94  SSACC=c093  SSLIM=ffffffff 
DS=0160  DSACC=c093  DSLIM=ffffffff  CR0=8001003b 
ES=0160  ESACC=c093  ESLIM=ffffffff  CR2=b8f70039 
FS=0000  FSACC=****  FSLIM=******** 
GS=0000  GSACC=****  GSLIM=********

I don't know if that is the same place where USBXHCD (12.14) trapped for you.

4) I could not get an USB audio 1.0 device to work at all. However, I did not test with the AN USB audio 1.0 driver, I only tested with our USB audio 1.0 driver.

I had no chance to test with an AN USB audio 2.0 driver because they only have a USB audio 1.0 driver.

[zlmikhail]

I confirm your observations, I recently received the driver and tested it. It doesn't fix the problem. Unfortunately.