OS/2, eCS & ArcaOS - Technical > Multimedia

Rebuilds of MM Audio Pack

<< < (9/10) > >>

Dave Yeo:

--- Quote from: Paul Smedley on December 12, 2022, 10:26:40 pm ---
--- Quote from: Martin Iturbide on December 12, 2022, 01:12:57 am ---What it didn't work was to convert it to FLAC. I also did the "Convert To", but this time, when I press the convert button, the bar will not progress, the error sound will chime and the audconv.exe program will be unresponsive and I require to kill the process. It generates a 0 bytes FLAC file that of course don't work.
Regards

--- End quote ---

You probably also have an entry in popuplog.os2 - I need to get around to debugging this....

--- End quote ---

Using the old mmioflac.dll does work. It's kind of surprising that any of the rebuilt DLLs work with audconv built with EMX and some VACPP object files. Wish that cwmm was buildable but it seems to be missing stuff.

David McKenna:
Hey Dave,

  I was looking at the source of CWMM at Netlabs and saw this in a readme:

How the Trunk was Built
3   
4   2017-07-12 SHL Baseline
5   
6   The trunk was built from the contents of the zip files stashed in
7   tags/imported-zips.
8   
9   The zip files are dirty in the sense that they contain a combination of
10   build sources, backup files, build products and some other cruft.
11   
12   This initial import was a best efforts to import a buildable set of files.
13   However, it is not unlikely that some files were missed.  If so, they should
14   be found in one of the zip files and should be "svn added" to the trunk.
15   
16   It is also likely that some build products where committed to the trunk.  If
17   so, they should be "svn removed" from the trunk.
18   
19   Have fun
20   
21   Steven

 Did you check out the zip files mentioned?

Regards,

Dave Yeo:
Yes, Arca Noae asked me at one point to try to compile them with the goal of fixing the cdplayer to use digitial transfer. Unluckily it seems Chris had dependencies on other files on his system so the SOM stuff was unbuildable.

David McKenna:
 Ahhh.. that really is too bad - would be nice to add the digital transfer.

Regards,

Lars:

--- Quote from: David McKenna on December 12, 2022, 10:15:09 pm --- Lars,

  Thanks for the explanation. To be clear: on both of my test systems, the USB devices (both USBAudio 1 and 2) worked perfectly with different bit resolutions from the WPS. It was UniAud I was testing that did not work with 24 bit files, I was hoping to get to work. I tried replacing AUDIOIF with USBAUDIF in MMOS2.INI, but that didn't work (just got silence).

  So the obvious question is: can the code used in USBAUDIF be used to upgrade AUDIOIF so it can be used by UNIAud (or any other driver that uses AUDIOIF)? Clearly UniAud supports higher bit resolution (works with PM apps), so it must be AUDIOIF that is blocking the WPS from using higher bit resolutions?

Regards,

--- End quote ---

In principle, yes. You could even use USBAUDIF.DLL verbatim (even though its name might imply something different). Unfortunately, there is an interaction between AUDIOIF.DLL/USBAUDIF.DLL and UNIAUD16.SYS (or any other audio driver that communicates with it. The connection is set up by MMPM2.INI, just look at the "VSDDRIVER" keyword). That is, AUDIOIF.DLL calls into UNIAUD16.SYS and expects a certain kind of responses. UNIAUD16.SYS would have to be adapted to USBAUDIF.DLL.
The reason why I created USBAUDIF.DLL in the first place was, because AUDIOIF.DLL was buggy and did not do the things it should. But that also meant to adapt USBAUDIO.SYS and USBAUD2.SYS to return the info that was necessary (but using only the documented interfaces, no special stuff).

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version