_SoundOpen Doesn't Work

[RealisT]

Windows XP Home - SP3

Tried to run the sample script given in the AutoIt documentation for the function _SoundOpen(). I get error code 1 with the explanation "There is a problem with the device driver."

What device?

What driver?

What do either of these have to do with launching Windows Media Player?

All I know is that I can manually launch WMP 11 just fine. So why can't AutoIt do it?

Thanks

[Melba23]

RealisT,

A few people recently have been reporting this problem.

What type of file are you trying to open and what is its full path? Does it play with the native SoundPlay command (note NO underscore)?

M23

Edit: Added a question.

Edited November 8, 2010 by Melba23

[AdmiralAlkex]

_SoundOpen does not start WMP. Press [Jump to Function Prod] (CTRL+J) and you will see MCI.

[RealisT]

I'm using the given sample script, and it uses a standard Windows wav file:

@WindowsDir & "\media\Windows XP Startup.wav"

SoundPlay plays this file just fine.

I confess I don't understand the suggestion:

"Press [Jump to Function Prod] (CTRL+J) and you will see MCI."

Press CTRL+J where? (i.e., in what app?) CTRL+J does nothing relevant in WMP, IE, or SciTe.

WMP or not, my question still stands: what device or driver is needed to open a sound file? The files themselves open just fine manually. So is this really a device/driver problem after all?

Thanks

[trancexx]

That's the message from down below. It's irrelevant in meaning for you, don't even think about it.

The problem is scheduled to be fixed with some of the new releases of AutoIt by adjusting _SoundOpen() function.

AdmiralAlkex meant SciTe (full version).

[Melba23]

RealisT,

As you are trying to play a "\Media" file with spaces in the name, try the quick fix for _SoundOpen I posted here.

So far we have only noticed the problem on Vista and Win7, perhaps there is a new driver which affects XP as well. Please let us know how you get on.

M23

[RealisT]

The issue is occurring regardless of file location and regardless of spaces in the filename.

Guess I'll have to wait for the next AutoIt release.

[Melba23]

RealisT,

Sorry we could not help. It is probably no consolation to you to know that it works fine for me.

M23

[AdmiralAlkex]

The issue is occurring regardless of file location and regardless of spaces in the filename.

Guess I'll have to wait for the next AutoIt release.

Wait, if you don't have the problem that is fixed, then what are you waiting for? And if you had it, then Melba linked to the solution. I don't see anything to wait for.

You confuse me.

Edit: Waaaait some more. Was the only file you tried? Is that the original file from Microsoft? Couldn't it just be that this particular file is bad somehow? You should try some random files in different locations, if all fails then I would assume that MCI or your soundcards driver is broken somehow. Try updating DirectX and sound driver.

Edited November 9, 2010 by AdmiralAlkex

[RealisT]

I have tried different files, different paths, different filenames (w/ or w/o spaces). I have tried both native and homemade files. The problem does not lie with the files. Nor can I blame the sound card; sounds are generated just fine on my system, and the files play fine, too, when opened in any way except through AutoIt.

BTW, the files play OK programmatically via VBA.

I am unfamiliar with the MCI. Would that be a generic dll file which can simply be repaired or replaced? Would fixing this affect other software's functionality?

Looks like addressing the MCI or DirectX are next best options...

(Don't mean to confuse anyone by saying I'll have to wait for a new AutoIt release. At this point, forums historically 'give up the chase' for the problem and start telling me to 'buy new hardware', 're-install windows', and nonsense like that. So either I wait for a new AutoIt release with modified _SoundOpen functionality or something unusual happens to resolve the issue.)

Thanks, everyone.

[Melba23]

RealisT,

As AdmiralAlkex has pointed out, the next AutoIt release will just incorporate the quick fix I linked you to - so do not pin your hopes on that.

As I pointed out above a few people have had this problem lately, but we are no closer to finding a solution that we were at the beginning. That is why he suggested looking at your DirectX and sound drivers.

The Sound UDF uses the Media Control Interface (MCI) to do everything, via the mciSendStringW function within winmm.dll. So I can only imagine that there is something different (note I did not say wrong) about the MCI on the setups that cannot use the UDF.

If you ever do find a solution, please let us all know.

M23

[trancexx]

This is wrong.

RealisT need to post a simple reproducer. Upon that he will be properly advised on what to do to make the script work as intended.

Saying that something doesn't work without actually posting the code (and attempts on fixing) is adding to many new variables to an equation that should have maybe only two.

[RealisT]

All,

The code IS in fact provided in this thread; as stated earlier, this is the example code given on the _SoundOpen page of the online AutoIt documentation.

I have given many links to this, but the URL is http://www.autoitscript.com/autoit3/docs/libfunctions/_SoundOpen.htm. Only the filenames have changed, though the given filename was tried, too.

Thanks

[iamtheky]

This plays music for me

#include <Sound.au3>

;open sound file : must be modified if run under Vista
$sound = _SoundOpen(@WindowsDir & "\media\Windows XP Startup.wav")
If @error = 2 Then
    MsgBox(0, "Error", "The file does not exist")
    Exit
ElseIf @extended <> 0 Then
    $extended = @extended ;assign because @extended will be set after DllCall
    $stText = DllStructCreate("char[128]")
    $errorstring = DllCall("winmm.dll", "short", "mciGetErrorStringA", "str", $extended, "ptr", DllStructGetPtr($stText), "int", 128)
    MsgBox(0, "Error", "The open failed." & @CRLF & "Error Number: " & $extended & @CRLF & "Error Description: " & DllStructGetData($stText, 1) & @CRLF & "Please Note: The sound may still play correctly.")
Else
    _soundplay($sound, 1)
EndIf
_SoundClose($sound)

[trancexx]

...Only the filenames have changed, though the given filename was tried, too.

Thanks

Only the file names are what's important.

File names are the thing that causes the problems.

Given filename most likely shows the problem.

What filenames?

[RealisT]

This is not the same issue as the one(s) already identified by other people relating to filenames.

The filenames are fine. The paths and filenames have no spaces, they have no special characters. They are short. They are not native Windows files. They are not in Windows or in Windows\Media folders but in folders of my own creation (again, no spaces, no special characters, no length concerns at 30 characters or so). Example: "C:\PaulsHTML\AudioVisual\DoubleTake.wav". Unless the function can't handle capitalization, the names & paths are not the problem.

I do believe this is a separate issue, I'm sorry to say.

Thanks

[iamtheky]

is the wav small enough to post, maybe the container is malformed? having it succeed or fail at someone elses hands may shed more light on the issue.

[AdmiralAlkex]

Then upload the file somewhere so we can see it.

[ripdad]

$sFile = FileOpenDialog("Choose File", @ScriptDir, "All Files (*.*)")
If Not $sFile Then Exit

MciPlay($sFile)

Sleep(3000); plays 3 seconds then closes

MCI_Command('stop', 'mySound')
MCI_Command('close', 'mySound')

Func MciPlay($media)
    Local $Init = MCI_Command('open', '"' & $media & '"', 'alias mySound')
    If @error = -1 Then ErrorMsg(-1); dll error
    If $Init <> 0 Then ErrorMsg(1); On "OPEN" <-- WINMM doesn't recognize the media
    $Init = MCI_Command('play', 'mySound', 'notify')
    If @error = -2 Then ErrorMsg(-2); dll error
    If $Init <> 0 Then ErrorMsg(2); winmm error
    ErrorMsg(0); Success
EndFunc

Func MCI_Command($command = '', $alias = '', $string = '', $MCI_Rtn = '')
    Local $MCI_Msg = DllCall("winmm.dll", "dword", "mciSendStringW", "wstr", $command & ' ' & $alias & ' ' & $string, "wstr", $MCI_Rtn, "uint", 128, "ptr", 0)
    ;$MCI_Msg = DllCall('winmm.dll', 'long', 'mciSendStringA', 'str', $command & ' ' & $alias & ' ' & $string, 'str', $MCI_Rtn, 'long', 128, 'long', 0)
    If @error Then Return -1
    If $MCI_Msg[0] <> 0 Then Return -2
    SetError(0)
    Return 0
EndFunc

Func ErrorMsg($eMsg)
    MsgBox(8256, 'MCI', 'Error Message: ' & $eMsg); If error 1, bad media or winmm has no codec for it
EndFunc

; NOTE: There ARE different types of wavefiles and each has it's own codec

- Edit - Tip: You can convert the file to something that winmm will recognize - perhaps an mp3. - (smaller too)

Edited November 11, 2010 by ripdad

[RealisT]

By request, attached is one of the sound files which does not open with SoundOpen (which is all of them).

This is an mp3, to demonstrate that the issue is not related to filetype (in terms of extension). All files tested open OK manually and open programmatically OK with other languages, but not via AutoIt.

I am convinced that the problem is not related to choices of file or filename, and no one has given me reason to think otherwise yet. Still, I know little about "containers" of sound files, so perhaps something is awry with them after all. But if that's the case, then it is the case with every sound file I have, whether is was acquired or created by me. No offense, but an AutoIt function quirk is far more likely.

Thanks

Flippy.mp3