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 ... 10 11 [12] 13 14 ... 51
166
Hardware / Re: Question about USB Audio (Input / Output).
« on: August 28, 2020, 01:13:08 pm »
I had a look at the descriptor info for the CM6533.

It has a setup where it mixes microphone input (from the MIC jack of the device) and USB input to produce sound on the output.

My suspicion is that USBAUDIO.SYS does not do the necessary setup to the FEATURE and MIXER components (look at the descriptor info) to ONLY take USB input (and turn off MIC input) and route that to the sound output. The problem is that the "sound network" between inputs (be it MIC or USB) and outputs (be it SPEAKER or USB) is "universal" and the connections a bit difficult to parse and come up with a generic decision on how to set the FEATURE and MIXER components (maybe someone DOES want to mix MIC input and USB input to a common speaker output).
"Cheapo" devices usually have a very simple network: connect MIC input via FEATURE component to USB output, connect USB input via FEATURE component to speaker and that's what USBAUDIO.SYS (and USBAUD2.SYS) is aiming for.
(short note: a FEATURE component does things like mute on/off, setting volume, setting base, setting treble etc. Your device only allows for mute on/off and volume as most devices do).

If I find some time, I would be able to hack a REXX script to properly set the FEATURE and MIXER components to do the above. It might take some trial and error though, as the REXX interface (using USBCALLS.DLL and USBRESMG.SYS under the hoods) is a little difficult to use.

You would then at least be able to run the REXX script shortly after you plug in the USB device. The USB device itself will keep the settings until you detach it.

One way to check my suspicion would be to attach a MIC to the MIC jack and then see if the picked up sounds are being heard on the speaker while you are playing that WAV file. One the other hand, that would not explain why you can successfully play other WAV files without any probs ...

167
Internet / Re: socket () fails: Protocol family not supported
« on: August 27, 2020, 06:16:29 pm »
Just a guess,

make sure you have file "protocol" in your %ETC% directory (and "services" if that is also missing).

168
Hardware / Re: Question about USB Audio (Input / Output).
« on: August 27, 2020, 06:14:01 pm »
I can play both files "applause.wav" and "dsk_opnw.wav" with my USB audio stick (Terratec Aureon Dual USB) without any need to convert those files.
Of course, you can convert files but the intention was to NOT force the user to muck around with his sound files.

Does "dsk_opnw.wav" not play at all, does it sound much too fast or does it have clicking issues ?
If clicking, see the other thread about shortcomings in the AN 12.x EHCI driver. If it sounds much too fast, that means that for whatever reason the sample rate conversion (in USBAUDIO.SYS) does not work.

What you can also do is to run "lsusb.exe" to dump the USB descriptors for your sound device. That would tell me what sample rates, bit depths and num of channels your USB audio device supports natively.


Lars

169
Hardware / Re: Question about USB Audio (Input / Output).
« on: August 26, 2020, 07:45:31 pm »
There is no "partially" supported. An USB audio device typically supports a limited number of sample rates, channels and bit depths. Usually, that is only one: 44.1 kHz, 16-bits, 2 channels or maybe 48 kHz, 16-bits, 2 channels. Especially the cheapo ones.

The USB audio drivers are always able to convert about any WAV input file in practical use to that target format. If that does not work, you have likely not fully installed the USB audio drivers (including additional components that they update).

Look at the WAV file you have problems with. What sample rate, bit depth, num channels does it have ?



170
Hardware / Re: Question about USB Audio (Input / Output).
« on: August 25, 2020, 10:23:39 am »
Yes, the 10.234 drivers do the necessary upsampling,channel duplication,bit conversion in order to properly play these old WAV files. But to be sure that everything works, you need to go through the whole USB audio installation and not only copy the drivers because some updates to the MMPM Subsystem are also necessary.

171
Hardware / Re: Question about USB Audio (Input / Output).
« on: August 22, 2020, 02:52:43 pm »
Hi Wim,

if you are talking about the Multimedia Setup Object Extension that I have written:
I have no clue if ArcaOS also delivers that extension. Can you see if the ArcaOS package (USBAUD2.WPI) contains the DEFDEV.DLL file (the DLL that implements the Multimedia Setup Object Extension) ? The WPI command line tool (WIC.EXE) should be able to list the WPI content.

172
Hardware / Re: USB 12.07 stack - Audio Clicking Issue
« on: August 21, 2020, 07:33:37 pm »
Version 12.07 looks much better. However, the problem with the quality of USB sound has not been fully resolved.
The new version does not lose data anymore, but the sound is choppy. It's like listening to a clipped vinyl record with clicks. Obviously, by the time the playback of the data packet is completed, the next one does not have time to arrive.
Most likely this is a problem in the ECHI driver that they tried to solve. I advise developers to rely on the experience of the 16-bit version. These problems are not there...

Does USB audio also properly work with the 11.17 EHCI driver (or the 11.17 driver set in its entirety) ? If yes, that should give David some good hint of what to change.

173
Hardware / Re: USB 12.07 stack - Audio Clicking Issue
« on: August 21, 2020, 05:31:15 pm »
AFAIK, the original IBM USB Audio driver has never had any significant updates - v12.07 is pretty much the same as every other version back to IBM's v10.something. Since AN now includes Lars/Wim's drivers in ArcaOS, I wouldn't expect any new development. Why bother with the IBM driver when the alternative is clearly better?
Both drivers (from Lars and from Ark) behave the same with the 12.07 stack. Both work with clicks. This is not a sound driver problem, but the USB ECHI driver.

I do know that Wim invested a lot of effort on USBEHCD.SYS to get isochronous transfers to work on EHCI (OHCI and UHCI were much better in this respect). There were some iterations until it would finally work. One of the things that I also fixed more than once (in USBEHCD.SYS) was the bandwidth computation in order to reserve the proper transmission frames (the ones with the least occupied bandwidth).
Then Wim did some iterations on USBAUDIO.SYS to get it to smoothly stream the data into USBD.SYS (and eventually USBEHCD.SYS).
I guess that David did not follow all the changes that went into USBEHCD.SYS regarding isochronous transfers and rolled his own ball.


174
Setup & Installation / Re: Startup.Cmd not executing
« on: August 11, 2020, 02:56:34 pm »
Just to add,
startup.cmd has to be a plain batch file. You cannot run a REXX script or a batch file that invokes a REXX script.

175
Setup & Installation / Re: How to have quantity and quality of memory
« on: July 28, 2020, 02:31:19 pm »
I have experienced the same (with 16 GB of installed memory !) and I would think that is an error in OS/2's memory management. I am using eCS, therefore I don't think this has anything to do with ArcaOS in particular.

I wouldn't be surprised if the memory manager checked IF some allocated memory could go into the swap file (after possibly increasing the swap file) even without actually doing so.
The MEMMAN directive has a COMMIT parameter that unconditionally allocates SWAP space (even if swapping would not be necessary) which kind of brings me to this conclusion. Maybe OS/2 expects some minimum of swap space to exist (even if unused) or some such. Or, with the invention of high memory, there was some bug introduced that improperly handles swapping under certain conditions.

It would not be the only error in OS/2's memory management. Think about high shared memory not getting freed when a DLL (using high shared memory) gets unloaded.

176
Off Topic discussions / Re: Thinkpad Yoga S1 12 weird *A* key
« on: July 21, 2020, 03:17:25 pm »

177
Multimedia / Re: Use of webcam
« on: July 18, 2020, 07:33:40 am »
USBRES is buggy, in particular for audio devices.
8783113Hz as supported sampling freq is obviously wrong.

178
Multimedia / Re: Use of webcam
« on: July 17, 2020, 11:06:17 pm »
Yes, that's worth a try.

But I can only say how it works for EHCI and OHCI/UHCI: if you have an EHCI host controller driver installed, right on driver HW initialization, the driver will "set a global switch" (configure flag) in the EHCI HW to claim all USB devices, regardless if USB2 or only USB 1.x. Later on, if a device is attached, there is an attach logic realized in HW where there is a special "USB2 chirp sequence" checked for by the EHCI HW. If the device does not send the chirp sequence, the EHCI driver will "reject" the device (handing over "port ownership") which either passes it over to a USB 1.x companion driver (and HW) if there is one (OHCI or UHCI) or the EHCI HW also contains a RMH (rate matching hub) which will convert the USB2 transfer to a USB 1.x transfer (which makes it largely transparent to SW if a device is a USB 2.0 device or USB 1.x device).

That said, I have not looked into the USB 3.x host controller spec if it follows the analogue sequence between USB 3.x and USB 2 if you have a port that can handle both, USB 3 and USB 2 (and USB 1.x).

179
Multimedia / Re: Use of webcam
« on: July 17, 2020, 09:08:26 am »
are we now entering the dark world of fake news, or what ?

DANIS506.ADD is a 16-bit driver. Is it outdated just because of that ? There are loads of other 16-bit only device drivers, including all of the older MAC drivers ? Are they all outdated only because of that ?
Obviously you have been enough worked on to believe that 32-bit drivers are somehow a cure to the whole driver problem on OS/2. They are not, and the initial entry points to ANY driver are STILL 16-bit with the exception of IDC entry points which can be made 32-bit.

Also, my 16-bit drivers are not "not compatible with USB3". In fact, they would be but I have no incentive to write a USB3 host controller driver because I think OS/2 is at the end of its lifeline, or to say it with Frank Zappas words: "OS/2 ain't dead, it just smells funny".

180
Looks like "unzip -Z -t" gives me the info I am looking for.

Pages: 1 ... 10 11 [12] 13 14 ... 51