USB Audio

[Eugene Gorbunoff]

PM123 audio player -> Press STOP button -> system reboots

• Basic USB: 11.06 from BETAZONE
• eCS 2.1 or eCS 2.2
• USB Audio, #1048

[Eugene Gorbunoff]

details:

1) fixed?

• plays as usual
• PM123 you can adjust volume

1) good:

• plays good
• OS boots without troubles
• attach USB Audio => no crashes

2) problems:

• PM123 audio player -> Press STOP button -> system reboots

Using drivers:

• USB Audio, #1048
• base drivers: 11.06

[Eugene Gorbunoff]

• eCS 2.2 beta 1
• PANARAMA 1.06
• ACPI 3.23
• USB 11.06

Hardware:

• MSI Z77IA-E53 -- ​http://www.regard.ru/catalog/tovar119390.htm
• ALC892 is supported by UNIAUD

[Eugene Gorbunoff]

IBM USB Audio driver:

• press STOP => crash of OS
• sound file goes to the end, play is over => crash of OS
• switch to other track => crash of OS

and your driver has the same problem.

So, something happens on closing of USB Audio adapter. Or finishing work with session. I don't know

[Eugene Gorbunoff]

USB report for chinesse 3D Sound USB Audio adapter: ​http://ecomstation.ru/usbdock/reports/0d8c000e.log

[Lars Erdmann]

Changed dynamic memory allocation to use VMAlloc+VMFree instead of AllocPhys/FreePhys/AllocGDTSelector/FreeGDTSelector

[Lars Erdmann]

Try SVN1050.ZIP. Report back if it at least fixes the crash of the OS or the scenarios listed above.
If you have problems: I added a switch /L to allocate below 16MB physical address line. You can try that and see if it makes a difference. But first, try WITHOUT this switch.

[Lars Erdmann]

update memory allocation to allow a buffer of exactly 64K bytes in size

[Lars Erdmann]

Yet another minor fix: try SVN1051.zip. The same comments apply as to SVN1050.zip.

[Lars Erdmann]

do not dynamically allocate stream table, statically place into data segment instead

[Lars Erdmann]

Yet another update, SVN1052.ZIP. It should be functionally equivalent to SVN1051.ZIP. Please try, same comments apply as for SVN1050.ZIP and SVN1051.ZIP.

[Eugene Gorbunoff]

Let's test again:

• 1050,1051,1052 - all versions boot, player writes a message about initialization error. MCI Erorr 5006: ?? Hardware error

• /L - the same problems --

• testing 1048 again - the user can listed sound. So.. no random factors.

[Lars Erdmann]

always return NULL on MemoryBuffer_Alloc

[Lars Erdmann]

in MemoryBuffer_Alloc, allocate in process address space

[Lars Erdmann]

Please test svn1052test1.zip first. Please tell me if it works like 1048, that is, you hear sound but you experience the crashes as before
Then try svn1052test2.zip. Tell me if it works at all or not.

[Lars Erdmann]

rework dynamic memory allocation to use AllocGDTSelector, fix bug in ISOSendBuffer

[Lars Erdmann]

Try svn1054.zip.

[Eugene Gorbunoff]

The user tested all versions: 1052 .. 1054

=> the same problem with every:

MCI Erorr 5006: Ошибка аппаратуры = MCI Erorr 5006: Hardware error

[Lars Erdmann]

Please try another application then PM123. Can you try to play system sounds ?

[Lars Erdmann]

Unoptimized version of 1054

[Lars Erdmann]

Please try SVN1054_DBG.ZIP. It's an unoptimized/debug version. I suspect a bug in the compiler optimizer but I am not sure.

[Lars Erdmann]

register with USBD.SYS directly after attaching to its IDC entry point

[Lars Erdmann]

Once you tried SVN1054_DBG.ZIP, try SVN1057.ZIP. Make sure you properly overwrite the files !

[Lars Erdmann]

remove superfluous handling of multiple DD headers (we only have one)

[Lars Erdmann]

Also try SVN1058.zip.

[w.m.brul]

Although I am testing with OS/2 Warp 4.0 NL... SVN1054_DBG.ZIP delivers sound whereas SVN1057.ZIP doesn't. The debug log contains a.o. a lot of the follwing messages: USBAUD: IOCTL_Generic : rc=8103

[w.m.brul]

log from svn1054_debug.zip

[Lars Erdmann]

Wim, in audiodat.c, can you set gAMsg to : DBG_CRITICAL | DBG_HLVLFLOW | DBG_IRQFLOW | DBG_DETAILED | DBG_SPECIFIC | DBG_DBGSPCL and rebuild the driver ?

That should give all debug output via serial terminal.

[w.m.brul]

Replying to erdmann:

Wim, in audiodat.c, can you set gAMsg to : DBG_CRITICAL | DBG_HLVLFLOW | DBG_IRQFLOW | DBG_DETAILED | DBG_SPECIFIC | DBG_DBGSPCL and rebuild the driver ?

That should give all debug output via serial terminal.

Hi Lars, Tomorrow I will try to build from your branch.

[Eugene Gorbunoff]

Our tester (tester G) installed fresh eCS, USB Audio only.

• #1048 - work as described in the beginning
• all versions - the same problems as described
• 1058 - doesn't work

he is testing using PM123 and system play => WAV files don't start playing.

[Lars Erdmann]

have you tried svn1054_debug.zip ? Obviously, it works ok at least on Wim's system.
1) How does the USBAUDIO.SYS statement look like in config.sys ? Please attach config.sys. 2) How does mmpm2.ini look like ? Please attach mmpm2.ini.

[Lars Erdmann]

Wim can you tell me how to properly install USBAUDIO.SYS ? The minstall.exe utility from eCS is screwed up beyond all hope. Or did you get it to install with the minstall.exe from eCS ?

[Lars Erdmann]

register USBAUDIO.SYS with USBD.SYS at INIT_COMPLETE but not any time before

[Lars Erdmann]

Please try sn1059.zip. I now have USBAUDIO.SYS properly installed in the system. It now properly registers with USBD.SYS. This is necessary so that USBD.SYS can call USBAUDIO.SYS to request service for any USB devices of audio class type.

[Lars Erdmann]

@Wim: in your debug log, the 0x8103 return codes show up because USBAUDIO.SYS is repeatedly called with cat 05h, function 48h = "PRT_ACTIVATEFONT". I have already read that this IOCTL is also sent to other drivers. However, there is nothing that could be done against it.

[w.m.brul]

Replying to erdmann:

Please try sn1059.zip. I now have USBAUDIO.SYS properly installed in the system. It now properly registers with USBD.SYS. This is necessary so that USBD.SYS can call USBAUDIO.SYS to request service for any USB devices of audio class type.

This one does give sound on my OS/2 Warp 4.0 NL system. The Logitech H340 Headset operates at 44.100 Hz. sample rate. The system sounds are not produced correctly. Due to the sample rate? The ecs.mpg sound is produced correctly with some distortion.

[w.m.brul]

mciaudio.cmd shows information about the waveaudio devices

[Lars Erdmann]

Ok, thanks for the REXX script files. I currently have the problem that I only have a USB microphone but let's see if we can make some progress anyway: 1) can you take a debug log when you play the cuckoo.wav file and post it here ? That will give me some idea of what code paths are hit. By the way, does the cuckoo.wav file play ok or not, see 2)
2) What are the "system sounds" else then playing a .wav file ? That said, what do you mean with "not produced correctly" ? Can you describe the effect ? Does that mean it does not play at all or that it sounds funny or loops or whatever ?

There is some odd code in USBAUDIO.SYS that reverses the sign bit of the data. For once it's implemented inefficiently and I wonder what the effects are ...

[Lars Erdmann]

By the way, I found this:

​http://comp.os.os2.bugs.narkive.com/EBssJsfd/trap-00d-in-usbaudio-sys-bldlevel-10-70-kernel-14-104a-uni

Questions: 1) does anyone still experience traps on bootup as was the case with the 10.70 driver from IBM ? I believe I fixed a trap that would otherwise occur when specifying any flag on the commandline of USBAUDIO.SYS. That was at least true for the DDK code ... Unfortunately no sym file exists for the 10.70 version of UNIAUDIO.SYS, otherwise I could deduce the code location ...

2) do the sounds still have the bad quality (note: "pure" is supposed to spell "poor") that the reporter mentions in his posting ?

[Lars Erdmann]

And another report from same reporter back at the time: ​http://newsgroups.derkeiler.com/Archive/Comp/comp.os.os2.bugs/2005-11/msg00014.html

[w.m.brul]

debug log of mcisound.cmd

[w.m.brul]

Replying to erdmann:

Ok, thanks for the REXX script files.

--- I have experimented in the past with mmpm and I have several tiny test programs too that exercise various functions like using a playlist, generate sound using dart. ---

I currently have the problem that I only have a USB microphone but let's see if we can make some progress anyway: 1) can you take a debug log when you play the cuckoo.wav file and post it here ? That will give me some idea of what code paths are hit. By the way, does the cuckoo.wav file play ok or not, see 2)
2) What are the "system sounds" else then playing a .wav file ? That said, what do you mean with "not produced correctly" ? Can you describe the effect ? Does that mean it does not play at all or that it sounds funny or loops or whatever ?

--- The system sounds are the ones that are played when you e.g. move an object for drag and drop. It is the same as playing a wav file. These sounds are produced. But what you hear is different from what you hear from the soundblaster. It sounds weird. Not at all what it should be. ---

There is some odd code in USBAUDIO.SYS that reverses the sign bit of the data. For once it's implemented inefficiently and I wonder what the effects are ...

--- With or without /DCONVERTER in the make file did not make it sound better. ---

[w.m.brul]

Some good news! I just tried to record using the digital audio object and that works. It records at 44.100 kHz. I can play the recorded file and it sounds well. The same distortion is heard at certain intervals just like when playing the ecs.mpg file. I blame that distortion to the fact that the Logitech H340 Headset requires a feedback endpoint to be used. I used my own build from your branch at svn1060 for this.

[Lars Erdmann]

1) Wim, I even suggest you just work on my branch as well. That will ensure that if I change something it will not only be tested by me but also by you. I'd even say you can add plenty of serial output debug info so that we have a chance to catch the place where the driver crashes in the way that the system reboots. For me this can only mean a triple fault. That said it could very well be a stack problem as the CPU attempts to push a value of zero on the stack when the double fault exception handler fires. If there is no stack left that would lead to a triple fault.

2) About "feedback endpoint": I guess I would need to look into the USB AUDIO spec but can you explain in short terms ? Is it an interrupt in endpoint that reports in regular intervals status or a notification to feed the next audio data via the isochronous out endpoint ?

[Lars Erdmann]

1) Wim, for AUDIO playback it's the "ISOSendBuffer" routine everything centers around. From what I can tell from the code, each buffer passed into USBAUDIO.SYS has to be sent to the USB device in 1 or more frames but it's not allowed to send fragments of frames. When the buffer does not contain the data for a whole number of frames, frame fractions are buffered to be sent at the next invocation. I think the code can be greatly improved in terms of performance and also readability.

2) I fixed the "while" loop in "ISOSendBuffer" size (see SVN rev 1054). eco reported that stopping/ending a playback and selecting the next file to play results in a system reboot. Can you please check and repeatedly play files and see if it eventually crashes/reboots or if this problem is now fixed ?

[Lars Erdmann]

do NOT buffer frame fragment if it's the end of stream, it's sent out immediately anyway

[Lars Erdmann]

please test svn1062.zip: it's a fix for playback (playing an audio file). There is no change regarding recording.

[w.m.brul]

Replying to erdmann:

1) Wim, I even suggest you just work on my branch as well. That will ensure that if I change something it will not only be tested by me but also by you.

My first aim is at testing your changes to reduce the turnaround time.

I'd even say you can add plenty of serial output debug info so that we have a chance to catch the place where the driver crashes in the way that the system reboots. For me this can only mean a triple fault.

I'll try to install usbaudio.sys at my eComStation 2.0 test system.

That said it could very well be a stack problem as the CPU attempts to push a value of zero on the stack when the double fault exception handler fires. If there is no stack left that would lead to a triple fault.

Who knows. It is important that ecs the original reporter responds.

2) About "feedback endpoint": I guess I would need to look into the USB AUDIO spec but can you explain in short terms ? Is it an interrupt in endpoint that reports in regular intervals status or a notification to feed the next audio data via the isochronous out endpoint ?

The proper term is 'Isochronous Synch Endpoint'. The relevant section in the USB Audio Specification is 3.7.2.2 and it says that the information carried over the synch path consists of a 3 byte packet. These bytes contain the Ff value in 10.14 format as described in section 5.10.4.2 of the USB 1.1 Specification. Ff represents the average number of samples the endpoint must produce (or consume) per frame (that is per millisecond) to match exactly the desired sample frequency Fs. The Logitech H340 Headset e.g. reports 0x0B0666 (decimal 722534) every 32 milliseconds. That value varies according to its actual need. The calculated theoretical average is (16384*44100)/1000 being 722534.4 but the master clock in the device would be slightly different and vary over time.

[Lars Erdmann]

Wim,

1) thanks for the explanation for the sync endpoint. That does make a difference 2) can you check if the sound file that you have played is A-law or u-law encoded (which also means that is 8 bits per sample) ? If yes I have a good idea of why it sounds so weird ...: ​http://en.wikipedia.org/wiki/G.711 explains which XOR mask you have to apply to those 8-bit samples for A-law and u-law encoded files. The code to XOR 8-bit data samples only in the sign bit in USBAUDIO.SYS is complete nonsense. I have almost completed an SSE optimized routine that will XOR all samples in a given buffer with an arbitrary bitmask. Just let me add it to the code ...

[w.m.brul]

Replying to erdmann:

please test svn1062.zip: it's a fix for playback (playing an audio file). There is no change regarding recording.

I have installed it on my OS/2 Warp 4.0 system and it works as well as the previous version i.e. I cannot tell the difference.

[w.m.brul]

Replying to erdmann:

2) can you check if the sound file that you have played is A-law or u-law encoded (which also means that is 8 bits per sample) ?

I have nu idea how to check that.

If yes I have a good idea of why it sounds so weird ...:

I doubt that that is the cause. The application is supposed to send the sound data in the format that the device driver can process. I think it sends the wrong format to the usbaudio.sys device driver. May be it is because I added the following line in MMPM2.INI for the USB Audio adapter: EXTNAMES=7,WAV,_AU,VOC,AU,SND,AIF,IFF Without that line it was not possible to play e.g. the cuckoo.wav file at all. There were no system sounds. I seem to recall that only the audio files recorded from the headset could be played back. I'll have to test this more...

​http://en.wikipedia.org/wiki/G.711 explains which XOR mask you have to apply to those 8-bit samples for A-law and u-law encoded files. The code to XOR 8-bit data samples only in the sign bit in USBAUDIO.SYS is complete nonsense. I have almost completed an SSE optimized routine that will XOR all samples in a given buffer with an arbitrary bitmask. Just let me add it to the code ...

[w.m.brul]

I replaced MMPM2.INI in my eComStation 2.0 test system. I got a trap in the original USBAUDIO.SYS IBM:10.070 at bootup. I replaced USBAUDIO.SYS with Lars' SVN1062.ZIP version and there was no trap anymore. Moreover the test results are the same as on my OS/2 Warp 4.0 NL system.

[w.m.brul]

Wim's homemade MMPM2.INI for testing USBAUDIO.SYS

[Lars Erdmann]

Wim,

1) would you please test SVN rev 1063 and see if that still works ok. I have rewritten the bit converter. I am not yet sure we need it but since the original code also contained that conversion code. My understanding is that the data that USBAUDIO.SYS gets passed is just the data content of a WAV file. Looking at CUCKOO.WAV I can see that the "silence" value is 0x80. But the mean/silence value should be 0x00 and 0x80 the most negative and 0x7F the most positive value. I guess that's the reason why the converter code exists.

By the way: CUCKOO.WAV is an 8-bit PCM encoded file. That should have hit the #IFDEF CONVERTER block ...

2) about trap in 10.70: did you have the /V flag specified in config.sys for USBAUDIO.SYS ? I believe the commandline was not accessible but I have fixed quite a few other things ...

3) about tweaking MMPM2.INI: it's good that you found out what to specify. However, what we need to do is reverse compile the CARDINFO.DLL that comes with the USBAUDIO package and add the extensions to the RCDATA block and rebuild CARDINFO.DLL. See "MMPM/2 Device Driver Reference" -> Modifying the CARDINFO.RC file. We need a user friendly solution ...

4) frame control via "isochronous sync endpoint": that's the next thing we should implement. I agree that this is most likely the problem with distorted sound.

[w.m.brul]

Replying to erdmann:

Wim,

1) would you please test SVN rev 1063 and see if that still works ok. I have rewritten the bit converter. I am not yet sure we need it but since the original code also contained that conversion code. My understanding is that the data that USBAUDIO.SYS gets passed is just the data content of a WAV file. Looking at CUCKOO.WAV I can see that the "silence" value is 0x80. But the mean/silence value should be 0x00 and 0x80 the most negative and 0x7F the most positive value. I guess that's the reason why the converter code exists.

SVN ref 1063 works like the previous version. Someone with the proper hardware should judge the sound produced.

By the way: CUCKOO.WAV is an 8-bit PCM encoded file. That should have hit the #IFDEF CONVERTER block ...

Yes. Although my Logitech H340 Headset indicates that it can only work at 44.100 kHz the system sends it incompatible wav files.

2) about trap in 10.70: did you have the /V flag specified in config.sys for USBAUDIO.SYS ? I believe the commandline was not accessible but I have fixed quite a few other things ...

I tested with and without the /V flag. In both cases the system trapped.

3) about tweaking MMPM2.INI: it's good that you found out what to specify. However, what we need to do is reverse compile the CARDINFO.DLL that comes with the USBAUDIO package and add the extensions to the RCDATA block and rebuild CARDINFO.DLL. See "MMPM/2 Device Driver Reference" -> Modifying the CARDINFO.RC file. We need a user friendly solution ...

You are right. The problem is that the user may plug in various usb audio devices with different capabilities. Suddenly the system sounds may sound weird. May be there should be directories 8000, 11025, 22050, 44100, 48000 etc. from which the user may select the proper sounds for the currently plugged in usb audio device. There need to be help info to the user that cover this situation.

4) frame control via "isochronous sync endpoint": that's the next thing we should implement. I agree that this is most likely the problem with distorted sound.

For the moment I regard this as a saparate enhancement to be added later. Not defect #75 that is.

[Lars Erdmann]

Replying to w.m.brul:

By the way: CUCKOO.WAV is an 8-bit PCM encoded file. That should have hit the #IFDEF CONVERTER block ...

Yes. Although my Logitech H340 Headset indicates that it can only work at 44.100 kHz the system sends it incompatible wav files.

3) about tweaking MMPM2.INI: it's good that you found out what to specify. However, what we need to do is reverse compile the CARDINFO.DLL that comes with the USBAUDIO package and add the extensions to the RCDATA block and rebuild CARDINFO.DLL. See "MMPM/2 Device Driver Reference" -> Modifying the CARDINFO.RC file. We need a user friendly solution ...

You are right. The problem is that the user may plug in various usb audio devices with different capabilities. Suddenly the system sounds may sound weird. May be there should be directories 8000, 11025, 22050, 44100, 48000 etc. from which the user may select the proper sounds for the currently plugged in usb audio device. There need to be help info to the user that cover this situation.

Wait a minute: are you saying that the USB audio device can only play ONE FIXED sample rate ? How does other audio HW deal with this situation (let's say a Soundblaster card) ? Could a Soundblaster card be programmed to use a different sample rate (or rather: playback rate) ?

Anyway CARDINFO.DLL does not deal with the sample rate issue. It just puts the right (or wrong) text strings into MMPM2.INI. I can follow your customized MMPM2.INI file and update CARDINFO.DLL accordingly.

[Lars Erdmann]

Driver with unpdated installation

[Lars Erdmann]

I have now updated the installation package.It basically reflects the changes that Wim had manually done to his MMPM2.INI file.

Eugene please test the driver and also the installation (deinstall the old driver) and please close this bug if the driver now works ok for you.

[w.m.brul]

Replying to erdmann:

Replying to w.m.brul:

By the way: CUCKOO.WAV is an 8-bit PCM encoded file. That should have hit the #IFDEF CONVERTER block ...

Yes. Although my Logitech H340 Headset indicates that it can only work at 44.100 kHz the system sends it incompatible wav files.

3) about tweaking MMPM2.INI: it's good that you found out what to specify. However, what we need to do is reverse compile the CARDINFO.DLL that comes with the USBAUDIO package and add the extensions to the RCDATA block and rebuild CARDINFO.DLL. See "MMPM/2 Device Driver Reference" -> Modifying the CARDINFO.RC file. We need a user friendly solution ...

You are right. The problem is that the user may plug in various usb audio devices with different capabilities. Suddenly the system sounds may sound weird. May be there should be directories 8000, 11025, 22050, 44100, 48000 etc. from which the user may select the proper sounds for the currently plugged in usb audio device. There need to be help info to the user that cover this situation.

Wait a minute: are you saying that the USB audio device can only play ONE FIXED sample rate ? How does other audio HW deal with this situation (let's say a Soundblaster card) ? Could a Soundblaster card be programmed to use a different sample rate (or rather: playback rate) ?

Yes, the Logitech H340 Headset handles only the 44.100 kHz. sample rate. Other usb audio devices might handle more than one sample rate. The soundblaster handles more than one sample rate. It handles I think 8000, 11025, 22050 and 44100 and may be others. There is a negotiation phase as you can see in the trace that I attached before. Moreover mmpm tries at first 22050 mono to 16-bit adapters and when the device cannot handle it, it tries 11025 mono at 8-bits. It is defined somewhere in the multimedia docs.

Anyway CARDINFO.DLL does not deal with the sample rate issue. It just puts the right (or wrong) text strings into MMPM2.INI. I can follow your customized MMPM2.INI file and update CARDINFO.DLL accordingly.

We might need user choices during the installation dependent upon their actual usb audio device.

[Lars Erdmann]

I am beginning to understand what I have to do: there is a routine called "GetBestFit" that is supposed to return the sample rate (and num of bits etc.) that the device can actually handle and that best matches the one MMPM/2 requests. If you say that a USB device can only handle one sample rate, this becomes easy: this routine should return that one sample rate. Currently it goes through some hoops to read entries from a few tables to find the one that matches best. But that does not make sense for the given situation.

[Eugene Gorbunoff]

Version: 1065 Tester: G / 3D Sound USB Audio adapter

• The user initialized MMPM, installed the package
• System sounds are defective on startup
• System player - plays OK
• PM123 reboots OS when the track is over.
• VLC - WAV - there are some scratches in the beginning, no sound. Select other file via FOC - plays good, D&D a file - it is played good.
• While VLC is playing sound, user started Firefox -> reboot of OS

[Lars Erdmann]

Eugene,

1) what is VLC ? A player ? What is FOC ? A player ? Where do I get these applications ?

2) defective system sounds on startup are a common problem. If sounds play OK otherwise I would think that your user is lacking to run: RUN=D:\MMOS2\MMFIX.EXE from config.sys. MMFIX.EXE is David's fix to this problem.

4) for "sudden OS reboot": we will need to add much more debug info so that we can find the place in the code that was last entered before this reboot happens.
Does your user's machine have a serial port and would be be able to capture debug output from a serial port (from another machine which could also be Windows running a terminal application) ?

4) Can we close this ticket and you just create a new one ? This ticket is becoming much too lengthy. Thanks.

[Lars Erdmann]

Continued in ticket #76

[abwillis]

Replying to erdmann:

1) what is VLC ? A player ? What is FOC ? A player ? Where do I get these applications ?

VLC is a player... it is a major multimedia app in the Linux and Windows world and was ported using the QT libraries to OS/2. ​http://hobbes.nmsu.edu/h-search.php?key=vlc&pushbutton=Search FOC is a File Open Dialog enhancer (not sure what the C stands for), ships with eCS starting with 2.1 I believe. ​http://en.ecomstation.ru/projects/foc/ From my reading of what he wrote you do not need FOC installed unless you want it as it says it plays fine with it and as it is a WPS enhancement means it should play fine without it as well.