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 4 ... 14

  Back in the ISA buss days, I had 2 sound cards with Warp4 and I could switch between them from the Multimedia Setup object, so at least it used to work. Maybe I'll dig up the drivers (one was a Crystal Semiconductor card and one was one of those IBM multifunction cards) and try installing to see what kind of entries are added to MMPM2.INI...

I have now written an installation DLL that is called during MINSTALL installation.
It does this for both, the WAVEAUDIO device as well as the AMPMIX device:
1) it scans the list of installed drivers in MMPM2.INI. If it finds it own install name (WMB....) it picks the first instance of itself (in theory there might be more than one USBAUDIO.SYS installed even though that is more or less impossible in practice)
2) it sets this first instance as the default device

Admittedly, that'll force USB use as a default even if you have UNIAUD installed in parallel.

I have never seen a configuration page to switch between different instances of AMPMIX devices. You can switch the default WAVEAUDIO device but strange enough that does not seem to have any effect.

I am open to suggestions. I suggest that once I get the USB driver set out of the door that you just rerun the USB audio installation. In order to see if it works or not, you can modify MMPM2.INI beforehand to list UNIAUD as the default device for WAVEAUDIO and AMPMIX. The USB installation should then change that to USB WAVEAUDIO/AMPMIX.

Hi Lars,

  Further fiddling shows me that just by having the line 'Ampmix=....' in the [defaultnames] section is all that is needed to get sound where I want it. So this:


 gets sounds out of the soundcard (apps and double clicking files) and this:


 gets sounds out of the USB speakers.

 I can't believe this is how MMOS/2 is intended to work, since there are no 'Ampmix' tabs in the Multimedia Setup object. Something isn't quite right. Can you point me to any documents that describe the contents or creation of the MMPM2.INI file? Google doesn't get me anything useful....

No there is no documentation. It's all trial and error (as so often in OS/2). When I look at the DDK code for all the MMPM related stuff (drivers as well as MMPM subsystem) I have the strong impression that all this stuff was hastily hacked together to have something working. Adding "OS/2 for PowerPC" support to the code base made the souce code even more messy.

However, now that you found out, I am thinking about adding a page to the Multimedia Object to allow setting the "default" mixer. Or it could be done via USBAUDIF.DLL (the VSD replacement for AUDIOIF.DLL).
Of course it would be even better if the "USB WaveAudio" page in the Multimedia Objekt would change that setting along with setting the default WAVE device.
I am pretty sure there is an MCI API function that allows to set the default mixer and the change should then make it into MMPM2.INI. In the past I had written an uninstall utility for UNIAUD using the MCI functions and those would also modify the MMPM2.INI file where necessary.

Then I suspect that we will have to wait for Lars to put the latest versions up on hobbes.

BTW, I asked that question because I have found in the past that people forget to put minstall into the directory with the files they are installing.

No need to put "minstall" into the directory where the installation files are located. What you have to do though is switch to that directory and run the installation from there by invoking "minstall /*".

Hi Wim,

  Thanks for all the development you've been doing on USB Audio! And thanks for the tip about the [defaultnames] section of MMPM2.INI! I had UniAud installed and working and added USB audio, but could never get the USB sound working by switching the 'Default Waveaudio Device' setting in 'Multimedia Setup'. After reboot it would still use Uniaud, so I just uninstalled UniAud to get USB audio to work.

  After seeing your MMPM2.INI tip, I tried again and discovered that when you switch the 'Default Waveaudio Device' setting in 'Multimedia Setup', only the 'Waveaudio=....' line in the [defaultnames] section of MMPM2.INI is changed. Apparently that is not enough, an 'Ampmix=...' line corresponding to the 'Waveaudio=...' line is also needed. Once I added the Ampmix line and rebooted, USB audio worked.

  This seems like either a bug, or a setup problem with MMOS/2 as the Waveaudio device should be associated with the proper mixer automatically, no?

I don't know if you can name it a bug. I rather think that WPS blindly uses the first audio device for audio playback instead of explicitely asking for the "default" audio device. The result is that if you double click on a sound file, the first audio device (which is the one appearing on the very left of the Waveaudio= and Ampmix= line in MMPM2.INI) will be used. I think the "default" setting is ignored by about any application and that's the problem.

Looks like AN had about the same idea. I decided to include the change in my next set of USB drivers.

This sounds fantastic, I can't wait to try it out.

Are the additional sample rates available to any audio adapter, or just USB?

Just wondering - I've got a couple of Warp boxes running audio logging 24x7, I'd love to be able to up the sample rate (they're using onboard audio cards supported via Uniaudio). 

I could of course switch these 2 systems over to using USB audio cards if needed.

Currently they are only available to USBAUDIO because the USBAUDIO installation package updates the MMPM subsystem accordingly.
The problem is an outdated AUDIOIF.DLL and SPI.INI. In principle Uniaudio could also support these higher rates and BitsPerSample (of course only if the HW supports them). But for that it needs an updated AUDIOIF.DLL and SPI.INI.
In order to not interfere with other audio adapters we have decided to build a USBAUDIF.DLL which takes the place of AUDIOIF.DLL so that AUDIOIF.DLL can remain untouched.



This is pretty awesome stuff. Will this make for a completely separate solution from something like the AN stuff though?

 - Dariusz

Don't worry. You can combine my USBAUDIO.SYS with the AN driver stack and it should work just fine. The updated installation installs a new dll called USBAUDIF.DLL as a replacement for AUDIOIF.DLL alongside to the already existing AUDIOIF.DLL (in the \MMOS2\DLL dir) but it leaves AUDIOIF.DLL untouched so they don't step on each others toes.

Likewise the new installation overwrites SPI.INI (in the \MMOS2 dir) but our SPI ini update is "cumulative", which means it includes and adds on top of what is already in the default SPI.INI file.

In short: we try to keep things compatible with whatever comes with an AN installation.

Go, Lars and Wim, go! Any chance multiple streams could be added?...

In principle, yes. But I don't see the concept of multiple simultaneous streams supported in the USB audio spec. And therefore the current installation restricts it to 1 stream. But thinking about it, maybe yes, I'll have to check if there are devices that support multiple interfaces with each having the same parameters.
What DOES work is having a simultaneous input (record) and output (playback stream).

Wim and me, we have been working on updating the MMPM subsystem so that it will finally support WAV files with 24-bit and > 65535 Hz (there was a limitation in the MMPM subsystem components that would restrict the sample rate to a 16-bit value).

In fact, we updated the MMPM subsystem to support these sample rates beyond 48000 Hz:
64000, 88200,96000,176400,192000,352800,384000 Hz.

The MMPM subsystem still has an inherent limitation to only support a discrete number of sample rates but we picked the rates that are in common use today. But I think we can live with that and the supported rates can be extended if necessary (but will require an updated USBAUDIO installation, see end).

With this support you can finally use more recent USB audio devices and exploit their full capabilities.
While 16-bit, 44100 Hz stereo (CD-ROM quality) was about the best you could get in 1996, more than 20 years later this is about the minimum sample rate /bit-depth used. It will also pave the way to support USB audio 2.0 devices which normally only offer these higher sample rates.

By the way: UNIAUD would also need this MMPM subsystem update to support WAV files with sample rates higher than 48000 Hz.

Once we have everything nice and polished I will release a new version of my USB device drivers.
It will be necessary to rerun the USBAUDIO driver installation to get everything updated properly.


Applications / Re: Dynamic Icons
« on: January 16, 2018, 12:36:08 pm »
FWIW, that is an ancient and quite obsolete version of the HOWTO. The latest HOWTO and toolkit was version 2.1 released in December 2011.

Alex, what happens if you run "rebuild new themes" from the Theme applet ? Will it bind the resource files (create by rc with the -r switch) to the DLLs in question ? In short: will that also lead to a selection of a specific theme ? Will this change be applied on next system start ? Or will it even be applied immediately ?

Thanks for any help. Lars


I have created an experimental version of USBD.SYS that will place attached devices under the corresponding hub they are attached to instead of placing them under the host controller they are attached to.
I think that makes it easier to determine where a device is plugged in. For example, if you use an external USB hub you will see the attached devices under "USB Hub Device_x.y.z" instead of under the host controller the external USB hub is attached to.
I think this logic also better follows the Windows logic.

Would anyone want to try out ? Unfortunately it will not work with the AN stack yet so you will need to (temporarily) install my 10.220 stack. If people prefer this I will try and convince AN to put it in their USBD.SYS.
It's not a big change to USBD.SYS and my HWMAN.DLL extension will still show the proper device names without any change !


Programming / Re: OS/2 kernel requiring speculative execution patch!!!!
« on: January 03, 2018, 02:35:22 pm »
There's also the question of whether this flaw really affects OS/2 as I believe the kernel memory runs in a separate segment, something that is not supported by 64bit mode and I believe gives some protection.

As far as I understand, the problem is that even though you cannot access kernel memory from user space, the speculative execution of subsequent instructions following that instruction will allow you to deduce what the instruction attempting to access kernel memory would have produced as a result.
I cannot see what bearing the Intel segmentation mechanism would have on this. You could simply bypass the segmentation mechanism by using linear addresses in your exploit code. 32-bit code will not undergo the segmentation mechanisms anyway (apart from internal functions written in 16-bit requiring thunking of code and data addresses).

Programming / Re: Compiling an OS/2 Driver
« on: January 03, 2018, 10:01:22 am »
If you compile with a 16-bit compiler (which cl.exe is), make sure you include the DDK header file directories before you include the TOOLKIT directories.
In fact, you will very likely not need to include the TOOLKIT header files at all if you include the DDK header files.

Be absolutely sure that you reset/delete the INCLUDE and LIB environment variables before you run the makefile and that you properly define the includes and libraries via the proper compiler and linker switches/directives. I have been caught by the problem of including the wrong header and library files more than once.


Programming / Re: Compiling an OS/2 Driver
« on: January 01, 2018, 12:53:19 pm »

unfortunately, Watcom produces debug info that no IBM supplied debugger can use, including ICSDEBUG.EXE (the debugger that comes with Visual Age) and ICAT (the remote source code debugger that can debug either via serial port or via UDP). This is also true if Watcom creates debug info in CODEVIEW format (looks like the CODEVIEW variant that Watcom generates is not understood by the IBM debuggers).

Just for that reason it can occasionally be better to still use Microsoft C 6.0 compiler as that one produces a CODEVIEW format that the IBM debuggers can understand.
If you don't care about source code debugging then of course this is not relevant.

Where that is possible I tend to create 2 makefiles: one for compiling/linking via Watcom and one for compiling/linking via VAC. Then I can develop using VAC and if everything works ok I can switch over to Watcom for the final build.


Article Discussions / Re: ArcaOS Wishlist - 6 months !!
« on: December 30, 2017, 08:37:55 pm »
Here you go with 2 drivers that I have written:

The WPIs contain all the source code. While they might not serve a practical purpose for most people, they are a live example of what can be done in a device driver.

And here is another one (including source code).

The latter is a PSD. Hopefully the source code contains enough comments for people to understand :-)

Pages: 1 [2] 3 4 ... 14