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 5 ... 10
31
Multimedia / Re: USB Audio
« on: March 12, 2017, 04:37:07 pm »
What you attempt to do will not work. There is a version crosscheck between USBCALLS.DLL and USBRESMG.SYS.
That is, you need to install them BOTH from the same package, either AN package, my package or Wim's package. You cannot mix my drivers with Wim's USBCALLS.DLL (and it is also not necessary).


32
Multimedia / Re: USB Audio
« on: March 12, 2017, 01:23:57 pm »
Just to be sure,

have you ensured that USBCALLS.DLL was properly updated ?
It should be in the \OS2\DLL directory (only !) and bldlevel.exe run against USBCALLS.DLL should tell you that it's version 10.215.
I can see no reason that USBRESMG.SYS should interfere with USB audio unless you use it with something, in your case, that seems to be USBECD.SYS.
By the way: USBCALLS 10.215 is fully compatible with Wim Brul's latest USBCALLS.DLL. Wim just did some additions to the header file but that's only relevant to programmers.

33
Applications / Re: Are you getting ready for ArcaOS?
« on: March 10, 2017, 03:46:34 pm »
DANIS506.ADD and also latest IBM1S506.ADD require a MiniVDM for int13. That's because they use the real mode int13 service for querying the physical disk geometry. Apparently there is no easy way to get to this Information in any other way.
There is a DevHelp to use int13 Support. I seem to remember that if you call that DevHelp, then the MiniVDM for int13 will be started automatically if it is not already running.

34
Multimedia / Re: USB Audio
« on: March 09, 2017, 08:31:30 pm »
Hi Wim,

from what I can tell from USBAUDIO.SYS tracing, Youtube will use 44.1 kHz stereo 16-bit PCM for sounds it wants to play. Therefore the dropouts when using Youtube in Firefox must stem from a different problem.

35
Yes, that's the problem. After I did the initial posting I realized that the -legacy packages are the ones to install in addition.
Unfortunately this is not explained anywhere. I screwed up my complete system and did a reinstall of YUM/RPM and ANPM from scratch which was painful.

I still think it's a bad idea to put version info into DLL names.

Next question: sometimes there are up to 3 packages for the same thing: a "i386" variant, a "i686" variant and a "pentium4" variant.
Which one to choose ? I have the latest and greatest CPU (AMD CPU with SSE, SSE2, bla bla bla).
In particular I cannot tell the difference between "i686" and "pentium4" and also I don't see what happens if I mix variants between 2 different packages (install one package as "i686" variant and the other as "pentium" variant).

Is there an easy explanation what qualifies as "i686" or "pentium4" ? I am thinking about needed instruction extensions (SSE, AVX, etc. etc.).


Lars


36
Multimedia / Re: USB Audio
« on: March 08, 2017, 09:02:38 pm »
Good to hear that it does not trap any more. That was the predominant thing to fix, obviously.
If possible you should try and play those system sound files (non sample rate converted files) that led to the trap and see if they will work without trap now.
Just today, Wim has found another bug in USBAUDIO.SYS that might also have a bearing on the problem.

About drop outs in Firefox: maybe that cannot fully be avoided. It might happen on high interrupt load. Isochronous transfer will lead to a fairly steady interrupt load. If something else is busy in the system (hard disk etc.) that might lead to a delay in interrupt processing.


37
Hi,

Apache Office 4.1 needs libicu in Version 4.2 (it is looking for DLL icuuc42.dll).
However Firefox needs libicu in Version 56.1 (it is looking for DLL icudt.dll I seem to remember).
The problem is: if I install the newer version, the older version is removed. I had to manually zip all files from the old version package, install the new one and then unzip the saved DLLs.

What is the correct way to deal with this ? Do I need to copy over that old stuff into the Apache Office application directory ?
I admit that I am lost.

Lars

38
Multimedia / Re: USB Audio
« on: March 07, 2017, 06:58:14 pm »
HI Neil,

thanks for posting the device descriptor. I seem to have the very same (inside), I have the sample rates etc. and for my device it also says
"C-M" which surely stands for C-Media.

Plus: Good news, I think I have fixed the trap you had with 11.12 and even though 10.215 seems to work for you: it's a serialization issue for isochronous buffer handling and it can likely strike again at any time (for isochronous devices).
By the way: I had the same trap with USBEHCD 10.215 and that trap is now gone.

I have now added proper serialization to ALL HC drivers (USBEHCD,USBOHCD,USBUHCD). Additionally Wim has fixed an issue in USBAUDIO.SYS with not properly keeping up the correct sample rate (for any sample rate that is not a multiple of 1000 Hz).

Would you be willing to test a new set of drivers ? If yes let me know where to send the stuff ...

39
Multimedia / Re: USB Audio
« on: March 07, 2017, 07:32:57 am »
Open USBRES.EXE (it's in \ecs\bin folder).
Select the device that is the sound device (should be able to guess from the Product name).
Now, right click on the device, "view device report" will show in the appearing context menu.
Click on the context menu entry.
A window "Device Report View" will pop up. Copy everything in the window (can be fairly long and you will need to scroll) and paste it here.

By the way: what driver version of USBEHCD.SYS are you using ? Seems you are using AN 11.14, correct ? Unfortunately, for that I don't have a map file, therefore I cannot locate the point of the trap (it's not at the same CS:IP as the trap that I had even though the error is similar).
You will need to report the trap on the AN bugtracker.


Thanks !

40
Multimedia / Re: USB Audio
« on: March 06, 2017, 11:25:26 pm »
Quote
..add in zeros and THEN to convolve with a low pass filter window..
If I understand correctly then this would lower the output level. My suggestions do not change sound level (less than one LSB max.). Low pass filtering is done after the DAC anyway. Absolutely no need to do anything here in software except if you plan high perfomance audio processing. Which I doubt is of any use for OS/2 and is definitely not doable with any of these USB audio toys. 

The simplest solution (doubling each sample for 22.05 to 44.1 conversion) is better than anything you can get out of these creepy USB toys anyway. Even on good sound cards (which are not available for OS/2) you hardly will find someone who can even measure the difference to more sophisticate algorithm at the analog output. And I bet you will not find anyone in the OS/2 community who can hear the difference in a blind test.

No, if you properly choose the window coefficients, you will not lower the output level, instead it will properly "fill up" the gaps between the original samples. For example, if you properly choose the window coefficients, a DC signal will still be a DC signal with the "gaps filled in" to the very same level as the original samples. I am not sure if this is dramatic but just repeating the samples will lead to distortion that might not be too good for earphones for example. In other words: it might not only be a question of quality.

41
Multimedia / Re: USB Audio
« on: March 06, 2017, 11:15:40 pm »
Yes, I have also experienced this very same trap and even another one. "Your trap" occurs in a frequently used copy routine where the copy routine tries to copy past the end of the segment (compare SI to DSLIM: that's the "end of segment" condition on an attempt to copy in units of 4 Bytes from DS:SI to ES:DI) and even though I have a full system dump for that trap, the dump is broken in a way that I cannot do a stack trace to find out where the error originates. Too bad.

About the other trap I ran into, I know where and why it occurs but I don't yet know what would be the proper solution to fix the error.

By the way: are you using the USB Audio device attached to an external USB 2.0 hub or are you using it in a system that in principle has EHCI only but also a rate matching hub built-in ? Or is this USB Audio device really a USB 2.0 device  (which I doubt) ?

Posting the device descriptor (copied from USBRES.EXE) would help. If the device is USB 1.x, it's a problem with USBEHCD.SYS having to do special processing when handling USB 1.x isochronous devices. That stuff is not really well tested.



42
Multimedia / Re: USB Audio
« on: March 05, 2017, 03:44:51 pm »
....
Actually, supporting 11.025 kHz or 22.05 kHz can be accomplished by inserting zeros in between the samples (3 zeros for 11.025 kHz and 1 zero for 22.05 kHz) and then convolving with a low pass filter window...

There exist sophisticated algorithm for sample rate conversion but we definitely will not need them on OS/2 IMHO. Though putting zeros into the stream I would consider one of the worst solution. A much better and adequate approach (IMHO) would be inserting the same sample a second time for making 22.05 to 44.1 conversion. A slightly better algorithm would be inserting the mean value of two neighbor samples in between.

You did not read properly. I said to add in zeros and THEN to convolve with a low pass filter window. There is nothing sophisticated about that. And using a proper window (say dolph-chebychev) instead of doing linear interpolation gives a much better result at only very little additional cost.

43
Applications / Problem with ANPM
« on: March 05, 2017, 01:38:50 pm »
I tried to update various packages and got this:

[u'ERROR with transaction check vs depsolve:', 'nss3.dll is needed by rpm-libs-4.13.0-9.oc00.pentium4', u'Please report this error at http://yum.baseurl.org/report']

Anyone know how to resolve this problem ? I cannot find nss3.dll in any of the likely packages. I can only find nss3k.dll.
I have the same problem with nssutil3.dll vs. nssuti3k.dll.

And another one: installing "netlabs-exp" leads to this error message:
Cannot access repository dir /@unixroot/var/cache/yum/netlabs-exp

It installed these settings for the repo:
URI : http://rpm.netlabs.org/experimental/00/i386/

44
Multimedia / Re: USB Audio
« on: March 02, 2017, 06:32:09 am »
Yes, I was thinking about the average consumer who wants to hear some bells and whistles here and there.

Actually, supporting 11.025 kHz or 22.05 kHz can be accomplished by inserting zeros in between the samples (3 zeros for 11.025 kHz and 1 zero for 22.05 kHz) and then convolving with a low pass filter window. That'll create a 44.1 kHz signal. Tried that in MATLAB and it works.
I also found a way to "hook into" the MMPM subsystem and get an address to the buffer containing the sample data (for playing sound).
The one thing I don't know is how I can "exchange" that buffer against one of bigger size ...
The other alternative would be to allocate a temporary buffer directly in the driver USBAUDIO.SYS. But I don't like that idea.

45
Multimedia / Re: USB Audio
« on: March 01, 2017, 10:29:48 am »
Hi David,

that is obviously possible but not a good solution in general. We need a sound subsystem that is able to deal with different sound formats and also with different sample rates. You don't want the user to convert his sound files to the very few formats that OS/2 and the Audio HW understand.
The MMIO mechanism deals with the conversion between different sound formats (say: MPG to WAV), therefore that is already covered.
In addition, we also need to deal with different sample rates which is not yet covered.

Pages: 1 2 [3] 4 5 ... 10