Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lars

Pages: [1] 2 3 ... 66
1
Multimedia / Re: OS/2 Warp 4.52 VM, changing audio to Uniaud
« on: September 26, 2022, 04:11:33 pm »
Your MMPM2.INI does not contain any entries regarding UNIAUD. No surprise that it does not work. Rerun the installation.

2
Multimedia / Re: OS/2 Warp 4.52 VM, changing audio to Uniaud
« on: September 26, 2022, 12:33:57 am »
Thanks David.

I will try with MInstall first. Are you referring the one from Martin Kiewitz or the IBM one?.
 
It seems that modifying the INI directly, with all the stuff it has there, it will be long and hard.

Regards

To get rid of soundblaster:
0) BACKUP MMPM2.INI
1) in section [Drivers], remove from "Waveaudio=": IBMWAVESB01
2) in section [Drivers], remove from "Sequencer=": IBMSEQSB01
3) in section [Drivers], remove from "Ampmix=": IBMAMPMIXSB01
4) remove sections [IBMWAVESB01],[IBMWAVESB01-PLAY],[IBMWAVESB01-RECORD]
5) remove section [IBMSEQSB01]
6) remove section [IBMAMPMIXSB01]
7) check section [defaultnames], if any of the above driver names appear, remove that entry


3
Applications / Re: VisualAge for C Modern Installer
« on: September 25, 2022, 11:31:08 am »
Building upon what Alex mentioned, I have also written a "CD-ROM Update" to the VAC installation CD-ROM that builds upon "FI":

This is for the VAC 3.6.5 Compiler:

http://www.os2site.com/sw/dev/vacpp/vacinstfix2.zip

The ZIP contains a "addinfo.txt" that explains on how to use the contents of this ZIP file. Effectively, you save the CD-ROM contents to hard disk, dump the ZIP file over it and burn back to a CD-ROM. The rest is listed in "addinfo.txt", including all the steps needed to get the help system working.

4
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 25, 2022, 08:56:57 am »
David, can you create a ticket against USBAUD2 at Netlabs and attach all info there ? It´s becoming too cluttered here.

5
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 25, 2022, 12:25:32 am »
Can you also attach the descriptor report for the Behringer ?
And then, also a trace. Make sure you also update TRC00EE.TFF ! I have enhanced tracing (added additional tracepoints).

6
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 25, 2022, 12:20:04 am »
Are you sure you are using

https://repos.arcanoae.com/misc/USB-12.14-20220829-test.exe

Make sure that you update all components and only take the usb audio drivers from my package.
What USB HW are you using ? I am using AMD/ATI. As I said, on my system it now works ok, with all flavours: UHCI,OHCI,EHCI,XHCI.

Try the attached. Maybe it makes a difference.

7
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 24, 2022, 11:08:09 pm »
That is strange, because I installed the AN drivers and at least my audio 2.0 device works ok and I tried with "USB3 only" ports.
Please retry with the attached.
What you will notice is that it sounds a bit corrupted as David had already said. But it will play.

8
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 24, 2022, 03:58:46 pm »
I had some email exchange with David. He told me that "isochronous in" endpoints are not yet completely/properly supported.

However USB audio 2.0 requires "isochronous in" endpoints as feedback endpoints to tell the audio driver how many samples per time unit the device expects to get (to iron out variances in transmission speed/to maintain the needed data rate when streaming). USB audio 1.0 (USBAUDIO.SYS) did not yet require that and therefore USB audio 1.0 should not be affected.

He also pointed me to a XHCI driver test build that you can find here:
https://www.arcanoae.com/resources/downloadables/experimental-builds/

It is worth trying because apart from other stuff, he has also modified isochronous support.

9
Multimedia / Re: XHCI and USB Audio perspectives - new test version
« on: September 24, 2022, 09:28:23 am »
Hallo David et al,

please test the attached. Just unzip the USBAUD2.SY? and TRC00EE.TFF files and put them in the proper directories.

10
Multimedia / Re: OS/2 Warp 4.52 VM, changing audio to Uniaud
« on: September 23, 2022, 06:51:39 am »
Or you could try the uninstall that I once wrote and that is part of a uniaud install.
It will take file cardinfo.dll as a base of what to uninstall.
So, even if it was written for uniaud, you can use it in conjunction with the SB drivers. You just need to run it from the directory where the SB installation files are located. That should contain a file cardinfo.dll.

11
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 22, 2022, 09:26:45 am »
Hi Lars,

  Thanks for giving it a shot. I'm starting to get the idea that USB in general is a patchwork 'hall of mirrors' so it's amazing anyone can keep track of how it all fits together....

Regards,

My understanding is there was the standard, which IBM followed, then there was the MS way, which did not follow the standard and was not documented.
USB3 is supposed to be better, but David seems to be working around weirdness in the hardware too much, with Intel being the worst, which is kind of surprising.
You might want to try an older (2 or 3 versions or more back) and see if that helps, David has been making things more strict I think.

In order to not mix up things:
1) "there was a standard that IBM followed, then there was the MS way": this statement only relates to device enumeration and this is mostly controlled by USBD.SYS. This has been changed to the MS way a long,long time ago and I don´t think that David has changed that in any way

2) "USB3 is supposed to be better": this is about typical requests like setting a device address or selecting an alternate setting of an interface. For < USB3, quite a bit of SW interaction was necessary to do that, USB3 does that almost all in HW with only very little SW interaction (which also involved timing issues which is always a bit unreliable to do in SW if you need fairly precise timing). In that way, USB3 is indeed better (apart from performance, of course)

Some of the requests in 2) are used during device enumeration in 1), so there is some relation to 1) , but it is not the same problem. They are 2 different problems.



12
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 21, 2022, 07:12:49 am »
Hi David,

this was just a quick shot.

Anyway: removing what David (Azariewicz) claims to be the problem obviously did not help.
To be honest, I also doubt that the USB audio drivers do not conform to the spec.

What had been in the code before and what I now removed is not only backed by the usb audio spec (in fact, the usb audio 1.0 spec mandates it under certain conditions) but also by the libuvc implementation (which I worked on in the past) which does the same (from an application level) after it has stopped streaming to a UVC compliant video device: to set the alternate setting of the audio (or video, in case of libuvc) streaming interface to 0. The speciality of alternate setting 0 (compared to alternate settings >=1) is that it contains no endpoints which is odd (but hey, that`s what the audio 1.0 spec specifies !) and serves the purpose to release any bandwidth if you do not stream data.

Needless to say that libuvc was ported from Linux, so obviously, it works under Linux and very likely also for USB3, otherwise somebody would have complained. And it works under OS/2, at least when I only use USB 2.

I am out of ideas.

13
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 21, 2022, 12:35:43 am »
Try the attached, also with USB3. That attempts to fix what David calls "it doesn't work because of a defect in the audio class driver. This driver is apparently not compatible with USB3/XHCI".


15
Multimedia / Re: XHCI and USB Audio perspectives
« on: September 19, 2022, 03:30:46 pm »
Hi Lars,

  I tried lsusb -v, but that failed to detect it too, ending with:

[C:\]lsusb -v > lsusb.txt
can't get debug descriptor: No such file or directory
can't get device qualifier: No such file or directory
can't get debug descriptor: No such file or directory
can't get device qualifier: Invalid argument
can't get debug descriptor: Invalid argument


Ok, that could be expected. lsusb.exe uses LIBUSB that in turn uses USBCALLS/USBRESMG. Since USBCALLS/USBRESMG fails, then LIBUSB and therefore lsusb.exe will also fail.

Pages: [1] 2 3 ... 66