_Sound UDF on Windows 7 Special Folders [solved]

[Tankbuster]

Just a short question:

Does the _Sound UDf work in Windows 7 (32Bit) or not?

Autoit's "playsound" works fine, but _playsound from the udf remains silent....why?(I read once that the UDF uses a DLL call, maybe I need a new version of the udf? Where?)

It's no big problem for me, just wanted to know. I search Bugtracker and forum but didn't found a hint. I'm sure I'm not the first to try sound on Win7....

I added a short code example of my Autoit 3.3.6.1 version:

#include <Sound.au3>

local $Default,$SystemAsterisk,$WindowsLogon


GetSounds()

 Playsound("Default")
 Playsound("SystemAsterisk")


Func GetSounds()
    $Default=RegRead("HKEY_CURRENT_USER\AppEvents\Schemes\Apps\.Default\.Default\.Current","")
    $SystemAsterisk=RegRead("HKEY_CURRENT_USER\AppEvents\Schemes\Apps\.Default\SystemAsterisk\.Current","")
    $WindowsLogon=RegRead("HKEY_CURRENT_USER\AppEvents\Schemes\Apps\.Default\WindowsLogon\.Current","")

EndFunc

Func Playsound($soundname)
    $tempSoundFile=eval($soundname)
    $tempSoundFile2=StringReplace($tempSoundFile,"%systemroot%",@WindowsDir)
    ConsoleWrite($tempSoundFile2)
    _SoundPlay($tempSoundFile2,1)
    sleep(100)
    SoundPlay($tempSoundFile2,1)
EndFunc

I compile it and if I execute the file in XP I hear 2 times 2different sounds (2 times Default and 2 times SystemAsterisk), same exe in Windows 7(32Bit) only 2 sounds are played.

For me no big deal, I will use the playsound function. I was just surprised when I transferred my app to Win7 and no sound was played.

Edited July 6, 2010 by Tankbuster

[Melba23]

Tankbuster,

The latest version of Sound.au3 is the one distributed with AutoIt - so you already have it.

I have not heard of any problems with the UDF in Win7. Simple question - can you play other sound files using the UDF?

M23

[Tankbuster]

Yes, and by testing your suggestion I found the problem.

The Space in the filename is not handled correct (by my function call ?)

#include <Sound.au3>
#AutoIt3Wrapper_Change2CUI=Y

ConsoleWrite("TEST1:_soundplay sound without Space in filename"&@CRLF)
_soundplay("Gong.wav",1)
ConsoleWrite("TEST2:_soundplay sound with     Space in filename"&@CRLF)
_soundplay("Gong 1.wav",1)
ConsoleWrite("TEST3:soundplay sound without Space in filename"&@CRLF)
soundplay("Gong.wav",1)
ConsoleWrite("TEST4:soundplay sound with     Space in filename"&@CRLF)
soundplay("Gong 1.wav",1)
Exit

So I shorten things up, and used a "GONG.WAV" and a copy of it "GONG 1.WAV".

Result in XP:

TEST1-4 OK , Sound is played

Result in Win7:

TEST 1 OK, Test 2 Fail, Test 3 OK And Test4 OK

Any guess? So _soundplay works, now my question changes to :

Long file names in _soundplay? (in the meantime I will search the forum.....)

(BTW: in the original post the path to the file was: "C:\Windows\Media\Landscape\Windows Ding.wav" - just with a space between WIndows and DING - I will search wiki to find out who started way back to allow space in path and filenames...grr ;-) )

//edit: I just added the consolewrite in my example

Edited July 5, 2010 by Tankbuster

[Melba23]

Tankbuster,

_SoundPlay handles spaces in file names without any problem. I helped write the UDF and there is nothing in there to make spaces a problem.

Perhaps a Win7 thing, but I cannot see why it should be.

By the way, as far as I know AutoIt has never allowed spaces in full paths; you must put in the backslash - and you normally need to add one if you concatenate path and filename.

M23

[Tankbuster]

I don't want to bother you but isn't it strange?

So I tested just a little bit more, and I found the next hint:

In the soundfile function: _SOUNDPLAY (line 212)

If _SoundPos($aSndID, 2) = _SoundLength($aSndID, 2) Then __SoundMciSendString("seek " & $aSndID[0] & " to start")line

And now the strange or the cause:

I added some console write just before the if statement:

In XP I got reported on my Sound wav file:

Position:0

Length:5408

And in Win7

Position:0

Length:0

So the problem exists in the Function that determines the length of the sound file.

I looked a bit closer and found in line 349 the line:

Local $iSndLenMs = Number(__SoundMciSendString("status " & $aSndID[0] & " length", 255))

and here in my test system: $iSndLenMs is not set in Win7 (in XP it returns the correct length).

In the next step I added a output to: __SoundMciSendString

and here I added a _arraydisplay($iRet) just right after the first function line.

So to summarize the testing:

1) The filename on the command "set xxxx time format miliseconds" in XP the "GONG 1.WAV" is displayed as "set G6G37R~B.WAV time format miliseconds" while in Win7 it is: ""set GONG 1.wav time format miliseconds"

Maybe this breaks the DLL call, as the space is transferred to the call in Windows7 without translation to 8.3?

2) next on "status GONG 1.wav position" the Array item $iRet[2] is empty (while in Xp it returns a 0)

3) on "status GONG 1.wav length" it return also a empty string while XP return me 5408 as length

Could it be that the DLL call does not work with spaces?

Or just tell me I'm totally wrong and I will stop and shut up.

I do not got any deep knowledge about dllcalls, but if this is a possible error condition?

(even if it is related to my Win7 installation - If you like It could test on other systems as well)

Does anything in my post make sense to you?

Or more important you someone re-create the situation, or is it limited to my inst?

Edited July 6, 2010 by Tankbuster

[Melba23]

TankBuster,

You are not bothering me at all - in the long term absence of the original creator I have become the de facto owner of the UDF and I want it to work!

Maybe this breaks the DLL call, as the space is transferred to the call in Windows7 without translation to 8.3?

That looks like the problem to me. Would you mind doing a little more research for me?

In Sound.au3, you will see the following line in the _SoundPlay function:

If Not __SoundChkSndID($aSndID) Then Return SetError(3, 0, 0) ; invalid Sound ID or file name

The function called in this line checks that you have a valid ID for the sound you want to play - either a $aSndID array returned by _SoundOpen, or a valid filename in which case an array is created within the function to use when calling the DLL.

Could you please add the following line immediately afterwards:

ConsoleWrite($aSndID[0] & @CRLF)

so we can see what is being returned from the __SoundChkSndID() function.

When I run:

_SoundPlay("GONG.wav", 1)
_SoundPlay("GONG 1.wav", 1)

on my Vista system I get the following in the SciTE console:

GONG.wav
GONG1~1.WAV

and so we can see that the filename with a space is converted to a suitable non-space format by the FileGetShortName command in the __SoundChkSndID() function for subsequent DLL calls.

It appears this is not happening for you (you say you get "set GONG 1.wav time format miliseconds" sent to the DLL) and thus the call fails.

Just as an added check - please run this code and see what you get returned:

ConsoleWrite(FileGetShortName("GONG.wav") & @CRLF)
ConsoleWrite(FileGetShortName("GONG 1.wav") & @CRLF)

as if there is a problem with the FileGetShortName command in Win7 (which I doubt very much ) it will also show up here.

A final request - please try using _SoundOpen on the files before _SoundPlay (with the added line still in the _SoundPlay function):

$aSndID = _SoundOpen("GONG.wav")
_SoundPlay($aSndID, 1)
_SoundClose($aSndID)

$aSndID = _SoundOpen("GONG 1.wav")
_SoundPlay($aSndID, 1)
_SoundClose($aSndID)

I get the following 10-character aliases (I will explain in a subsequent post if I have to! ) returned in the SciTE console just as I would expect:

jxgmmobplw
nblbkovklz

What do you get?

Eagerly awaiting your results.

M23

[Tankbuster]

So by reading your post and recapture what I did and how I tested, it came to my mind that maybe I should use the good old DOS dir command with /X to see the short names.

(this has been done during your post writing)

so I did a "DIR GONG*.WAV /x" on xp and got:

11.08.2004  12:38            13.590 G6G37R~B.WAV gong 1.wav
11.08.2004  12:38            13.590              gong.wav

next on Win7:

11.08.2004  12:38            13.590              gong 1.wav
11.08.2004  12:38            13.590              gong.wav

Ahhh, Windows does not reports it correctly...but wait...for using the same file I used a shared NETWORKDRIVE (something like a NAS but simpler, maybe Samba or CIFs), and yes you already think about the same cause. I copied the GONG*.WAV from the NETWORK Folder to local drive and did DIR /X again:

NOW:

11.08.2004  12:38            13.590 GONG1~1.WAV  gong 1.wav
11.08.2004  12:38            13.590              gong.wav

Hurray, a shortname.

So now to your test demands (but you already got the answer, didn't you)

If I play the sound from localdrive - PERFECT ! (just like it should be, Shortname is reported and working).

Re-test with NETWORK folder - no shortname on Windows 7 (but on XP)

...... at this time I was thinking, great my fault, so dumb to not see the network issue....BUT wait ......didn't I start with Windows System sounds (see my first post)???

So let me see:

I tried again with the file - now hardcoded just simple:

_soundplay("c:\windows\Media\Landscape\Windows Ding.wav",1)

Nothing is played....grr...ok next try....

Copy the file to a new location (just md c:\Media\Landscape - copy file"

_soundplay("c:\Media\Landscape\Windows Ding.wav",1)

Hurray - wonderful sounds

One moment:

1) _Soundplay proofed to work with longfilenames AS long as the OS reports the shortname

2) The same file is played correct if it is not in a KNOWN(!!!) windows folder

So I open the folder "c:\windows\Media\Landscape\" to see what is realy inside - and windows shows me the ALIAS names of the file - something like "Windows-Logonsound" (you know in Win7 that hide all the good stuff to not shock user.....)

but not the real name like "Windows Logon Sound.wav".

Could it be that this is just like my network issue, does not provides the shortname?

Let's see

dir "c:\windows\Media\Landscape" /x

10.06.2009  23:22            19.924              Windows Balloon.wav
10.06.2009  23:22            20.968              Windows Battery Critical.wav
10.06.2009  23:22            29.328              Windows Battery Low.wav
10.06.2009  23:22            18.356              Windows Critical Stop.wav
10.06.2009  23:22            14.700              Windows Default.wav
10.06.2009  23:22            83.816              Windows Ding.wav
10.06.2009  23:22            19.924              Windows Error.wav
10.06.2009  23:22            20.446              Windows Exclamation.wav
10.06.2009  23:22            20.968              Windows Feed Discovered.wav
10.06.2009  23:22            15.222              Windows Hardware Fail.wav
10.06.2009  23:22            20.968              Windows Hardware Insert.wav
10.06.2009  23:22            19.402              Windows Hardware Remove.wav
10.06.2009  23:22            13.654              Windows Information Bar.wav
10.06.2009  23:22            39.254              Windows Logoff Sound.wav
10.06.2009  23:22            39.776              Windows Logon Sound.wav
10.06.2009  23:22             4.772              Windows Navigation Start.wav
10.06.2009  23:22            26.192              Windows Notify.wav
10.06.2009  23:22            12.610              Windows Pop-up Blocked.wav
10.06.2009  23:22            28.282              Windows Print complete.wav
10.06.2009  23:22            16.788              Windows User Account Control.wav

No SHORTNAMES - $§&!!!***### Windows

I'm not sure, but is this in Vista also the same?

So thank you for your input and help.

Could you somehow proof that I'm on the right track? (or is there no hope for me...)

ANd by chance soundplay function just playes the filename, while _soundplay tries to get the shortname, correct? (as my test showed that soundplay is able to play the sound..)

Edited July 6, 2010 by Tankbuster

[Melba23]

Tankbuster,

And I thought my post was long!

My Vista machine does the same as your Win7 one - no shortnames when you look at a filename with a space in the "\Windows\Media\" folder (I do not have the "\Landscape\" level) - either with FileGetShortName or "dir /x". So it looks as if the problem lies in Windows and not in the UDF - that makes me very relieved, even if it does not solve your problem.

Of note, I cannot find any other filenames with spaces in the "\Windows\" path, so I cannot test if the problem is wider than the "\Media\" folder.

I shall add a remark to the Help file pointing out that if you use Sound.au3 you cannot play sounds directly from a "\Windows\Media\" folder if the OS is Vista/Win7. If I find time, I shall also look into why the shortnames are not available for these files.

Thanks for pointing this out - I am always grateful for reports on possible bugs in my UDFs.

M23

[Tankbuster]

Referring the long post: I just wanted to make clear what and how I've done things - of course posts like "Does not work - help me - without example" are shorter and more entertaining (from a strange view of spectator and reader).

I have to excuse me to not use the @error returned by your UDF, but as the thing was working in XP I got on the wrong track...

Displaying your @error on an file without a shortname gives me @error=1 (play failed - which is quiet obvious

But based from the help file is "3" more correct? Or a new error code 4 = No File shortname found?

Just a suggestion.....

Local $vTemp = FileGetShortName($aSndID)
if @error then return 4

or a _FileGetShortName internal function trying to open the full name if no shortname is returned?

I know this is not correct, just as a draft.

Maybe Win7 got more from this stuff...

[Melba23]

Tankbuster,

It was a joke!

I have found that the DLL accepts filenames with spaces as long as they are enclosed in quotes. So I will have to see if I can adjust the UDF to cope with this - I can see lots of ' " ' syntax problems coming up!

I understand the error suggestion - but I hope it will not be necessary.

Keep your eyes open for an amended UDF - may I PM you to test it before hand?

Thanks again for the bug report.

M23

[Tankbuster]

It was a joke!

Just as I understood it in that way.

I have found that the DLL accepts filenames with spaces as long as they are enclosed in quotes.

I found with Google a old post, complaining that his winmm.dll call for a MP3 file (with spaces) does not work....and the asnwer was something similar. God, who invented the LFN?

Keep your eyes open for an amended UDF - may I PM you to test it before hand?

I will sent you an pm with my email. And yes, if you did the work I will take the part of the complain.....errr...tester. Feel free to give me a try.

I also got the option to test it in Win7 x86 and x64.

BTW: is it possible to edit the post header? I would like to chnage it to something better like: "_sound.au3 and not Shortfilename on special folders in win7" ???

Edited July 6, 2010 by Tankbuster

[AdmiralAlkex]

BTW: is it possible to edit the post header? I would like to chnage it to something better like: "_sound.au3 and not Shortfilename on special folders in win7" ???

The title thread? Sure just press edit on the first post, exactly like you created it in the first place.

[Melba23]

Tankbuster,

To change the title of the thread, do what AdmiralAlkex said, but make sure you choose the "Use Full Editor" option.

Anyway, now that fantastic stage of the Tour de France over the cobbles on the Franco-Belgian border ("the hell of the North" ) is finished, I have been looking at the DLL in more detail.

Testing has shown that you can ONLY use the full filename in quotes with the 'open "File_Name" alias #######' string - and that you need double quotes around the filename, singles will not do. But being able to do this means that we do not need to use FileGetShortName in the _SoundOpen function and we can use this function to "open" the sound files in the "C:\Windows\Media" folder which have spaces in the filename and no "short" names - with no ill effects for any other sound files. Once the file is opened, it can be played normally with _SoundPlay.

What we can not do easily is modify the _SoundPlay function to play such sound files using the full filename as a parameter - it would mean a major rewrite of the UDF to open and close the sound file as part of the function. I do not see this as a major problem as the sounds in that folder are pretty short for the most part - the built-in SoundPlay command can be used to play them without difficulty and Sound.au3, with its wider range of commands, is more aimed at controlling longer sound files in any case.

So as there are 2 valid alternatives available to play these Windows sound files, I am not prepared to rewrite the whole UDF to cater for them when all we need to do is change one line in _SoundOpen to open them for full use by teh other UDF commands:

; This line in _SoundOpen:
__SoundMciSendString("open " & FileGetShortName($sFile) & " alias " & $aSndID[0])

; needs to be changed to:
__SoundMciSendString("open """ & $sFile & """ alias " & $aSndID[0])

As you so kindly offered, would you please test the modified UDF on your Win7 machines - it works fine on my Vista box. If anyone else reading could test it on XP I woudl be most grateful.

If all is well, I will get the Dev team to include the modified UDF in the next release and I will add a remark to the Help page for _SoundPlay to make the point that if the sound file is located in the "C:\Windows\Media" folder it MUST be opened with _SoundOpen before use.

Again my thanks for the initial report.

M23

[Tankbuster]

@AdmiralAlkex: Thx for the hint with the FULL editor.

@Melba23:

I tested the script of the first post with the current UDF on my home Win 7 /x64 and got the same result. (no sound is played)

Added the _soundopen as suggested to my script and I changed the line you wrote, and re-run and

..... _soundplay("tada.wav") ... working !

I tested it on Win7 /X64 and XP Pro x86, both working now.

On Win7 x86 if you like I will add the result tomorrow (but I think this is now working).

Was a pleasure to help you .

I will search now MSDN for the "no shortname".......

Just a question: "Tour de France" - is this some sort of non football sport? As you know in Germany only WM2010 is a matter. If you read this post tomorrow at 22:30 and Germany lost the semi final: No, I'm not interested in football at all......(please do not sent flowers)

Edited July 6, 2010 by Tankbuster

[AdmiralAlkex]

@Melba23

Sorry, I'm just so used to using the full editor, I can't imagine someone using the quick one (when you preview the post the page updates so it's by far the simplest way to know if someone posted something while you were writing).

Anyway, I'm not sure I would call it a "major rewrite", it was only ~70 lines with my implementation (and not really any changes to the end user) although I took no concern for MustDeclareVars or such things. But I do think it's low priority, so I'm not surprised if it isn't fixed.

Here it is if anyone want to see my overheated fix. Overheated as in, my room has no ventilation or air circulation at all, I think my brain could be melting right now.

Sound2.au3

The adlib or array should probably be changed, it depends if you want low cpu usage or low memory usage. This is as best a proof-of-concept.

Edited July 7, 2010 by AdmiralAlkex

[Tankbuster]

It looks like the 8.3 shortnames are not part of the NTFS rules. It's a bonus more or less

In the past (win2000,xp) there was a key in the registry:

http://support.microsoft.com/kb/121007

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

and the values are 0 = create shortnames

1 = no shortnames

but for Win 2008 (and newer) they added new values:

http://technet.microsoft.com/en-us/library/cc778996%28WS.10%29.aspx

now a volume based setting is possible.

I thought 8.3 names are always there, so you learn every day something new....

[Melba23]

Tankbuster,

Trac ticket #1707 raised. Let us see if it is accepted.

M23