• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

SOUND: Multiple WAV/RAW Streams to a sound card?

Started by RobertM, 2007.08.22, 00:46:44

Previous topic - Next topic

RobertM

Hi,

I am wondering what is required to have multiple sound streams played simultaneously by a sound card?

I am aware that certain sound cards under OS/2 support it such as:

  • IBM MWave based cards
  • Certain SoundBlaster AWE32/64 based cards?

Are there others that support this using UniAudio? If not (or if there are only a few) is it possible to replace (or catch the streams before) the IBMMixer DLLs with something that can do stream mixing before output to the sound card? Or is there an option in UniAudio that I am missing that enables this for any sound card?

Thanks,
Robert




|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

Anyone? For me this is a (lack of a) feature that is causing some problems when two determined devices vie for the sound card (sometimes requiring a reboot or at the least, shutting down every app and restarting the WPS just to free the sound card).


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


kim

What kind of streaming are you trying with and I give it a try on the system that I got here on my side.

obiwan

Quote from: RobertM on 2007.08.23, 05:37:23
Anyone? For me this is a (lack of a) feature that is causing some problems when two determined devices vie for the sound card (sometimes requiring a reboot or at the least, shutting down every app and restarting the WPS just to free the sound card).

Does this problem occur with any sound driver or only Uniaud? If Uniaud, are one or both of the streams being played using the Uniaud API?

I was not aware that audio streams could be mixed in MMOS/2 with the SB AWE hardware. Or MWave for that matter. If that's really the case then of course there is the potential for Uniaud to support the feature, but I'm sure it does not now.

RobertM

#4
Hi guys,

First note:
I may be incorrect about which SoundBlaster supports multiple streams... though I am pretty sure it was (at least) the AWE32 as that was the one I owned. The drivers that support it under OS/2 are the SBLive081 drivers (and I believe the docs list which cards are supported for multiple streams).

The driver [ported by Sander Van Leewen(sp?)]supports:
- Up to 32 simultaneous wave playback streams
- One record stream
- Full duplex
- Support for the IOCTL90 mixer interface (designed by Joe Nord of
  Crystal Semiconductor and supported by the Crystal OS/2 audio drivers)
- RTMIDI playback & recording

It is based off the SBLive Linux drivers and can be found on Hobbes. IIRC, only certain AWE32 & AWE64 series were supported (the Live! Series - and only the earlier ones of them before they were changed).

As for the MWave, I know it definitely supported playing multiple streams on OS/2 from as early as 1996/1998. Some of the stream handling was done by the MWave chip itself I think (as the MWave cards could only handle a certain number of streams based off how much of the MWave's CPU resources were available). Each app that was playing sound on the MWave could individually control the sound level of it's particular stream (leading me to believe that some of the volume or mixing handling was done by MMOS2 before passing the "volumized" stream to the MWave - which only had one master volume control for each stream type).

The MWave was also capable of playing multiple stream types with each player individually controlling it's output volume for it's stream alone [for instance: 2 MIDI streams, 3 WAV streams, 1 MP3 stream (ie: 4 audio, 2 MIDI) - all simultaneously, all with their volume levels set by the program playing each stream].

The advantages of the MWave was a lot of the work seemed to be offloaded to the MWave's CPU - thus my 100MHz 486 DX4-100 could actually play that number of streams simultaneously.

The disadvantages (currently) are that the MWave's in question only came in ISA (unless integrated into a Thinkpad or Sun SparcStation), the drivers are very difficult to find for OS/2, updates for the Thinkpad version were a bit ahead of the ISA version's updates [better (and more) MIDI samples, support for other features (besides the standard sound, Q-Sound, MIDI, MPEG processing, voice/fax/data modem that came in all releases)].

On to my issue at hand:

Using the latest UniAudio, in (for instance) playing an MP3 using (either) Z! or PM123 or CWMM, when another object tries to use the sound card (for instance the web browser when I inexplicably hit a page with audio, OR, BackTalk, OR, sometimes even the WPS playing sounds for folder animation), the program that originally had control of the sound card (PM123, etc) does not always regain control. When that happens (which doesn't seem to be consistent or predictable), the program needs to be shut down and restarted. This will sometimes allow it to once again play sound. The rest of the time, it still will not have access to the sound card (and nothing else will) - in which case, sometimes shutting down every app running and restarting the desktop will release the sound card - while other times it will require a reboot to release the sound card (again it is not predictable which method is necessary to release the sound card).

The sound chip in question is a Crystal Semiconductor chip (exact chipset not known at the moment and would require a reboot to determine) on a few year old HP board.


Anyway, I was thinking that a "WAV-OUT" device could be written that is actually a driver that creates/allows multiple input streams (creates one each time an app requests one) and then one output stream to IBMMixer... though I am guessing that the functionality probably already exists in MMOS2 since at least a half-dozen sound cards (or variants) support multiple output streams and none of them seem to change the IBMMixer (which IIRC has options for how many streams it can receive/process in the INI file).


-Robert



|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


obiwan

Hi Robert,

Everything you have said here is very good news to me. The problems you are describing about Uniaud seem related to some other problems I am told about, which I think is a flaw that can be fixed without too much difficulty.

Generally, when MMOS/2 can't mix sounds, it does a pretty good job of interrupting one to allow another one and then resuming the first, but I think Uniaud does not respond correctly to this.

The fact that MMOS/2 can mix sounds when the hardware supports it, as I said, I did not know, but is very good news, because it means everything is there to do it without having to reinvent it.

Even better is the fact that Sander's sbliveos2 driver works with it, because we have the source for it, so it is only a matter of re-implementing it in Uniaud. This is far simpler than having to reverse-engineer the feature and write it from scratch, which I, for one, would not be able to do.

So really here there are two issues, one being a source of a fairly serious problem, the other being a lovely but optional feature. There is hope for both in Uniaud.

RobertM

Well, and possibly a third (at least for later)... for cards that only support one audio stream - now that CPUs have become far more powerful, it seems that eventually we (the OS/2 community/developers) will hopefully be able to have a driver solution that allows mixing of any sound streams (as some or most Windows drivers do - using the CPU to do the mixing via the driver before the mixed, single sound stream is sent to the card).

I'm guessing the MMOS2 subsystem should be able to handle that as well... but with a little more work... there are already programs - and DLLS,  that do similar things... for instance, the CrossFade plugin for PM123 (used to) do that (dont think it is compatible with the newest PM123 release - but that is really irrelevant) - and there are also apps that did multiple WAV file - single output stream mixing.

Well, one step at a time I guess... though I am curious if for the sound cards that dont support multiple streams, if the answer would be simply to create another sound device instance that uses such technology, and then outputs the stream to the main (real) sound device instance... much like some of the virtual device drivers that intercept keyboard input, play with it, and then pass it on to someplace else...

-Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


obiwan

A possibility to investigate is whether ALSA already does that. If so there would be very little to do to achieve it with Uniaud.

If it doesn't, of course it seems technically plausible to invent such a feature for OS/2, but considering this would be primarily for older hardware, it probably isn't worth the effort. Doesn't most if not all new audio hardware these days have multiple channels?

RobertM

From some of the ALSA project Docs:
Quote
Intro to dmix

The dmix virtual sound mixing device is a plugin to ALSA which takes multiple sound streams and mixes them into one virtual stream which a lower-end card can handle. Any card which does not support multiple streams or hardware mixing of sounds must use this plugin to take full advantage of ALSA and its capabilities.

In most cases, dmix will be automatically configured for ALSA 1.0.9 RC2 and above. There is no need to adjust the default configuration for the basic user and it should work transparently with your system.

Which means, outputting multiple streams that is supported in hardware seems to be supported by the drivers... using DMIX seems to be the method for older sound cards that dont support it - but requires DMIX-aware-apps... or in OS/2 perhaps by registering DMIX as the WAVOUT device intercept or mixer...

So... I dunno...



|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


rudi

Quote from: obiwan on 2007.08.24, 04:04:22
Generally, when MMOS/2 can't mix sounds, it does a pretty good job of interrupting one to allow another one and then resuming the first, but I think Uniaud does not respond correctly to this.

MMOS2 is buggy. In Warp4, it sends wrong stream state change notifications to the driver, which can cause the lockups described. The functionallity works correctly in Warp3. I did a workaround for that in the C-Media driver, which eventually will show up in the Netlabs SVN. But it could also be a problem of UNIAUD...


Quote from: obiwan on 2007.08.24, 04:04:22
The fact that MMOS/2 can mix sounds when the hardware supports it, as I said, I did not know, but is very good news, because it means everything is there to do it without having to reinvent it.

MMOS2 doesn't mix by itself. If a device and it's driver supports multiple streams, it's installer will put this information in MMPM2.INI. In addition to that some drivers support a query function. When a new stream is to be created, MMOS2 checks the INI and/or asks the driver. If it finds out that the driver might be able to deal with this, it passes the request on. Otherwise it might try to suspend an existing stream (depending on the sharing mode). So for MMOS2 these streams are completely unrelated. As if they would go to different cards. Mixer commands are just passed down to the driver that handles the stream, which has to decide what to do depending on a stream number.


Quote from: obiwan
A possibility to investigate is whether ALSA already does that. If so there would be very little to do to achieve it with Uniaud.

The best would be to have this feature disconnected from UNIAUD, i.e. so that it would work with any "backend" driver. Not just UNIAUD. However, this will probably require heavy changes in MMOS2. I'm quite positive, that it is doable, but it's a lot of work. Restricting to UNIAUD would most likely be much easier to accomplish.


Quote from: obiwan
considering this would be primarily for older hardware, it probably isn't worth the effort.

I wouldn't say that. PCs must be cheap. Therefore only relatively "high-end" sound hardware supports multiple streams. Especially, since W*******s does software mixing as well, the vendors have no real reason to implement multi-stream support in hardware.


Quote from: obiwan
Doesn't most if not all new audio hardware these days have multiple channels?

Multiple channels: Yes, 5.1 is considered to be standard these days.  Multiple streams: No.


obiwan

Thanks Robert and Rudi for educating me on this subject. I am confident that functional dmix support can be added to a future version of Uniaud.