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.

[Lars Erdmann]

AN released USB 12.16. One of the fixes goes against isochronous operation. Please get and install USB 12.16 and see if that fixes your problem.

​https://www.os2world.com/cms/index.php/past-news/80-news/software/23802-arca-noae-usb-driver-package-version-12-16-now-available

[zlmikhail]

Testing... At first glance, the new drivers work correctly. I never saw any kernel errors. Sound reproduction occurs without artifacts, frequency grids and bit depth are switched correctly. There are some problems with the fact that sometimes playback stops after 1 minute, but I do not associate this with an XHCI driver problem, something similar happened earlier on EHCI ports. And this problem does not cause the system to freeze.

[zlmikhail]

Update.

Unfortunately, I was unable to get my UAC2 device to work correctly.

The sound plays normally via USB audio only if my UAC 2.0 device is connected to the first XHCI controller. If the system has an additional XHCI controller, the UAC device connected to it will behave very strangely. And these oddities will depend on which specific XHCI controller is currently being used as an additional (second) one.

When testing, I used 3 PCI-E cards with XHCI controllers on different chips, as well as a motherboard with two built-in XHCI controllers. In all cases, normal operation for audio output could only be ensured by the port connected to the first XHCI controller. In other words, if in CONFIG.SYS I leave only one BASEDEV=USBXHCD.SYS, then the UAC devices connected to its ports will work normally, but if there are two USBXHCD devices in the config, then the device connected to the second UAC controller will behave very strangely.

For example: in the case of the Texas Instruments TUSB7320 USB 3.0 controller, the old story is repeated, tracks are played back at a speed increased several times. At the same time, playback of the first track always occurs normally. The speed increases only for the second and subsequent tracks. Sometimes USBAUD2 Trap000d appears. When using another USB 3.1 Gen 2 controller, tracks are played at normal speed, but very often playback stops at random times. At the same time, no errors are displayed, the system does not freeze, it’s just as if pause was pressed.

I tried all versions of USBAUD2, from those that you posted in this thread. But the result is approximately the same.

[Lars Erdmann]

I have uploaded usbdrv250 to Hobbesarchive. Please install that, if a trap appears in USBAUD2, please take picture of trap screen.

[Lars Erdmann]

My system has 3 EHCI host controllers. I swapped my USB Audio 2.0 device between the first and the third EHCI host controller and there were no problems.

The class drivers (USBAUDIO, USBAUD2 but also USBMSD etc.) are agnostic to the specific host controller they are attached to other than the fact, that they get reported by USBD.SYS what host controller a device is attached to so that they can route the request to the correct host controller. That said, in reality, they instead route the request to USBD.SYS which then sets up the transfer using the correct host controller (the one it reported to the class driver earlier).

I cannot see how the class drivers behaviour would lead to effects on host controllers the device is not even attached to. But maybe the trap screen (of USBAUD2.SYS) can give a clue of what is going wrong.

To me it sounds like an error in USBD.SYS.

[zlmikhail]

picture of trap screen

[Lars Erdmann]

Did you install usbdrv250 ? Otherwise I cannot guarantee that I will find the trap location.

[Lars Erdmann]

please install usbdrv250 and again take picture of trap screen (if possible).

[zlmikhail]

Replying to Lars Erdmann:

Did you install usbdrv250 ? Otherwise I cannot guarantee that I will find the trap location.

Yes, I installed the USB audio driver via minstall/* I cannot install the rest of the driver on top of the AN version of the USB stack. This trap may have been accidental and I could not repeat it.

[zlmikhail]

I have to admit that my conclusions about the causes of errors in the operation of UAC devices were incorrect. I tested PCI-e USB XHCI controllers on a board without its own XHCI controller. All the boards behaved differently and only one worked correctly on both motherboards and with all the UAC devices I have.

In total I have 4 PCI-e different XHCI boards, 3 of them on different chipsets (Texas instruments, Asmedia, and Renesas). If we talk about each separately then:

1. The board with the Renesas PD720202 controller for 6 ports does not work at all, it is detected in the system, but none of the UAC2 devices work on it and are not detected. Apparently the problem is that this card has a HUB/divider.

2. The board with a Renesas PD720202 controller for 2 ports is fully functional. Both devices on XMOS chips and AMANERO are detected and operated on it. When playback is at the correct speed, multi-hour playlists do not stop.

3. Board with Asmedia ASM2142 controller for 1 port. The board is unstable. In the original and latest build of ArcaOS 5.1 installed in UEFI mode, the board is only capable of working with the Amanero UAC2 device and refuses to detect and work with the XMOS device. With the UAC2 Amanero device, playback can stop at any time without any apparent reason or error. Moreover, in a micro assembly, when loading the system into MSHELL via Legacy (BIOS), playback mode can last several minutes, and in a full system in UEFI mode, playback rarely lasts longer than 5 seconds.

4. Board with Texas Instruments TUSB73x0 controller for 1 port. The board is unstable. In the original ArcaOS 5.1 build installed in UEFI mode, the board is only capable of working with the Amanero UAC2 device and refuses to detect and work with the XMOS device. With the UAC2 Amanero device, normal playback is possible only for the first launched track; all subsequent tracks are played back at a speed increased several times.

---

As for XHCI controllers built into the motherboard or processor chipset. At the moment for OS/2 I am using a motherboard with an Intel Q370 chipset, the only CHRSH controller on this motherboard only works normally with the AMANERO UAC2 device? works fully (without accelerations and sudden stops). UAC2 XMOS device is not detected.

[zlmikhail]

The board with the Renesas PD720202 controller for 6 ports does not work at all

[zlmikhail]

The board with a Renesas PD720202 controller for 2 ports is fully functional.

[zlmikhail]

Board with Asmedia ASM2142 controller for 1 port. The board is unstable.

[zlmikhail]

Board with Texas Instruments TUSB73x0 controller for 1 port. The board is unstable.

[Lars Erdmann]

Replying to zlmikhail:

Replying to Lars Erdmann:

Did you install usbdrv250 ? Otherwise I cannot guarantee that I will find the trap location.

Yes, I installed the USB audio driver via minstall/* I cannot install the rest of the driver on top of the AN version of the USB stack. This trap may have been accidental and I could not repeat it.

No, it's not the latest driver from hobbesarchive, find here: ​http://www.hobbesarchive.com/Home/Download?path=/Hobbes/pub/new/usbdrv250.zip

Please reinstall (only USBAUDIO.SYS/SYM and USBAUD2.SYS/SYM or course)

[Lars Erdmann]

That most certainly sounds like a HC driver problem, in particular with isochronous devices (I guess your USB mouse,keyboard,memstick work ok).

Even though XHCI is a standard, the individual host controller implementations might have their quirks or interpret the standard in different ways.

[zlmikhail]

Replying to Lars Erdmann:

That most certainly sounds like a HC driver problem, in particular with isochronous devices (I guess your USB mouse,keyboard,memstick work ok).

Yes, I checked the operation of HID devices, and also tried to copy data from flash drives through the ports of PCi-e cards

[zlmikhail]

Replying to Lars Erdmann:

Please reinstall (only USBAUDIO.SYS/SYM and USBAUD2.SYS/SYM or course)

I tried the drivers you suggested, I didn’t notice any changes in behavior, the card with the TI chip continued to play the sound at an accelerated rate after the first track.

[Lars Erdmann]

The only 2 things I can think of right now is to try this:

1) turn off the on-board USB host controllers. Apparently, you have additional XHCI cards plugged in so it would be best to isolate the problem to these add-on cards

2) I would try ACPI.PSD /VW (the virtual wire switch). That should force the system to use PCI IRQs instead of MSI interrupts. Maybe that makes a difference. An alternative is ACPI.PSD /NOMSI which might prevent problems with virtual wire mode but will still prevent MSI from being used.

[Lars Erdmann]

post the output of ACPISTAT.EXE.

[Lars Erdmann]

also, in %ETC%\acpid.cfg, enable logging like so:

; AcpiLog: Where to write the acpica$ log file, full path, default=don't create
AcpiLog = C:\var\log\AcpiCA.log ; change path to your preference

and then post acpica.log.

[Lars Erdmann]

Replying to zlmikhail:

Replying to Lars Erdmann:

Please reinstall (only USBAUDIO.SYS/SYM and USBAUD2.SYS/SYM or course)

I tried the drivers you suggested, I didn’t notice any changes in behavior, the card with the TI chip continued to play the sound at an accelerated rate after the first track.

The driver behaviour did not change but the binary layout of the driver changed. I need the newest driver to properly interpret the trap screen.

[zlmikhail]

output of ACPISTAT.EXE

[zlmikhail]

Replying to Lars Erdmann:

2) I would try ACPI.PSD /VW (the virtual wire switch). That should force the system to use PCI IRQs instead of MSI interrupts. Maybe that makes a difference. An alternative is ACPI.PSD /NOMSI which might prevent problems with virtual wire mode but will still prevent MSI from being used.

Thanks for the advice. The /VW and /NOMSI keys are blocking my system from booting.

[zlmikhail]

David A (administrator) 2024-07-31 14:01 Arca Noae does not produce a class 2 audio driver, and as such does not recommend or support class 2 audio devices. If you are trying to use a class 2 audio device with a third party driver, you must contact that third party for support.

Sadness.

[zlmikhail]

Caught Trap000d when switching tracks using a Renesas PD722020 controller. The driver used was the latest one with the date 07/28/24

[zlmikhail]

I caught a similar error when playing a long track

[Lars Erdmann]

fix bug if setmem receives a zero length request with a far address with zero offset (setting PCM silence in buffers)

[Lars Erdmann]

pull usbaudio.zip from the attached package and reinstall it. It should fix your trap. I fixed both, USBAUD2.SYS and also USBAUDIO.SYS as both contained the same problematic piece of code.

[zlmikhail]

Replying to Lars Erdmann:

pull usbaudio.zip from the attached package and reinstall it. It should fix your trap. I fixed both, USBAUD2.SYS and also USBAUDIO.SYS as both contained the same problematic piece of code.

For XHCI controllers on Asmedia ASM2142, Texas Instruments TUSB73x0, the behavior has not changed. In the first case, playback can still stop spontaneously; in the case of the second controller, the first track is still played at normal speed, the second and subsequent tracks are played at double speed.

A board with a Renesas PD720202 controller and two USB 3.0 ports is so far more stable than others. I'll continue testing.

[zlmikhail]

A board with a Renesas PD720202 controller with a new driver plays back different recording formats for more than 4 hours without errors.

I would like to understand why other controllers work so strangely and why the UAC device on the XMOS chip is not recognized and does not work through them.