[RFC] winecfg audio driver test
This is a proof of concept patch that adds a simple audio test to winecfg. All it does is use PlaySound to play a wave file. I am using LoadLibrary("winmm.dll") and FreeLibrary to change drivers. You must press the apply button for the driver change to take effect. There is no error recovery for a missing winmm.dll. The wave file name is in the rc file so a different file can be played for each language. This is probably overkill. I'm not sure where to put the wave file so the program will only work when the wave file is in the current directory. The wave file can be found here: http://home.earthlink.net/~reif/winecfg.en.wav or you can rename any old wave file to: winecfg.en.wav. Comments please? Index: programs/winecfg/En.rc =================================================================== RCS file: /home/wine/wine/programs/winecfg/En.rc,v retrieving revision 1.54 diff -p -u -r1.54 En.rc --- programs/winecfg/En.rc 27 Oct 2005 11:24:02 -0000 1.54 +++ programs/winecfg/En.rc 12 Nov 2005 04:21:54 -0000 @@ -157,13 +157,14 @@ BEGIN COMBOBOX IDC_AUDIO_DRIVER,70,18,85,85,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP PUSHBUTTON "Autodetect",IDC_AUDIO_AUTODETECT,170,20,49,14 PUSHBUTTON "Configure",IDC_AUDIO_CONFIGURE,170,40,49,14 - PUSHBUTTON "Control Panel",IDC_AUDIO_CONTROL_PANEL,170,60,49,14 + PUSHBUTTON "Test",IDC_AUDIO_TEST,170,60,49,14 + PUSHBUTTON "Control Panel",IDC_AUDIO_CONTROL_PANEL,170,80,49,14 - GROUPBOX " DirectSound ",IDC_STATIC,8,75,244,120 + GROUPBOX " DirectSound ",IDC_STATIC,8,95,244,120 - LTEXT "Hardware Acceleration: ",IDC_STATIC,15,85,90,10 - COMBOBOX IDC_DSOUND_HW_ACCEL,100,83,150,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP - CONTROL "Driver Emulation",IDC_DSOUND_DRV_EMUL,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,15,100,230,10 + LTEXT "Hardware Acceleration: ",IDC_STATIC,15,105,90,10 + COMBOBOX IDC_DSOUND_HW_ACCEL,100,103,150,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP + CONTROL "Driver Emulation",IDC_DSOUND_DRV_EMUL,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,15,120,230,10 END @@ -197,6 +198,9 @@ BEGIN IDS_WINECFG_TITLE "Wine configuration" IDS_THEMEFILE "Theme files" IDS_THEMEFILE_SELECT "Select a theme file" + IDS_AUDIO_FILE "winecfg.en.wav" + IDS_AUDIO_DONE "Done playing: " + IDS_AUDIO_ERROR "Couldn't play: " END Index: programs/winecfg/Makefile.in =================================================================== RCS file: /home/wine/wine/programs/winecfg/Makefile.in,v retrieving revision 1.15 diff -p -u -r1.15 Makefile.in --- programs/winecfg/Makefile.in 24 Aug 2005 10:59:40 -0000 1.15 +++ programs/winecfg/Makefile.in 12 Nov 2005 04:21:54 -0000 @@ -4,7 +4,7 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = winecfg.exe APPMODE = -mwindows -IMPORTS = comdlg32 comctl32 shell32 ole32 winmm shlwapi uxtheme user32 advapi32 kernel32 +IMPORTS = comdlg32 comctl32 shell32 ole32 shlwapi uxtheme user32 advapi32 kernel32 C_SRCS = \ appdefaults.c \ Index: programs/winecfg/audio.c =================================================================== RCS file: /home/wine/wine/programs/winecfg/audio.c,v retrieving revision 1.15 diff -p -u -r1.15 audio.c --- programs/winecfg/audio.c 3 Nov 2005 19:31:45 -0000 1.15 +++ programs/winecfg/audio.c 12 Nov 2005 04:21:54 -0000 @@ -52,6 +52,13 @@ static const char* DSound_HW_Accels[] = NULL }; +static HINSTANCE hWINMM = 0; + +HDRVR (WINAPI * pOpenDriverA)(LPCSTR lpDriverName, LPCSTR lpSectionName, LONG lParam); +LRESULT (WINAPI *pSendDriverMessage)(HDRVR hdrvr, UINT msg, LONG lParam1, LONG lParam2); +LRESULT (WINAPI *pCloseDriver)(HDRVR hdrvr, LONG lParam1, LONG lParam2); +BOOL (WINAPI *pPlaySoundW)(LPCWSTR pszSound, HMODULE hmod, DWORD fdwSound); + /* Select the correct entry in the combobox based on drivername */ static void selectAudioDriver(HWND hDlg, const char *drivername) { @@ -89,19 +96,19 @@ static void configureAudioDriver(HWND hD HDRVR hdrvr; char wine_driver[MAX_NAME_LENGTH + 8]; sprintf(wine_driver, "wine%s.drv", pAudioDrv->szDriver); - hdrvr = OpenDriverA(wine_driver, 0, 0); + hdrvr = pOpenDriverA(wine_driver, 0, 0); if (hdrvr != 0) { - if (SendDriverMessage(hdrvr, DRV_QUERYCONFIGURE, 0, 0) != 0) + if (pSendDriverMessage(hdrvr, DRV_QUERYCONFIGURE, 0, 0) != 0) { DRVCONFIGINFO dci; LONG lRes; dci.dwDCISize = sizeof (dci); dci.lpszDCISectionName = NULL; dci.lpszDCIAliasName = NULL; - lRes = SendDriverMessage(hdrvr, DRV_CONFIGURE, 0, (LONG)&dci); + lRes = pSendDriverMessage(hdrvr, DRV_CONFIGURE, 0, (LONG)&dci); } - CloseDriver(hdrvr, 0, 0); + pCloseDriver(hdrvr, 0, 0); } else { @@ -116,6 +123,26 @@ static void configureAudioDriver(HWND hD } } +static void loadWinmm() +{ + hWINMM = LoadLibrary("winmm.dll"); + if (!hWINMM) { + WINE_ERR("winmm.dll not found\n"); + /* FIXME do something */ + } + + pOpenDriverA = (void*)GetProcAddress(hWINMM, "OpenDriverA"); + pSendDriverMessage = (void*)GetProcAddress(hWINMM, "SendDriverMessage"); + pCloseDriver = (void*)GetProcAddress(hWINMM, "CloseDriver"); + pPlaySoundW = (void*)GetProcAddress(hWINMM, "PlaySoundW"); + + if (!pOpenDriverA || !pSendDriverMessage || !pCloseDriver || !pPlaySoundW) + { + WINE_ERR("winmm.dll not all entries found\n"); + /* FIXME do something */ + } +} + static void initAudioDlg (HWND hDlg) { char *curAudioDriver = get_reg_key(config_key, "Drivers", "Audio", "alsa"); @@ -125,6 +152,8 @@ static void initAudioDlg (HWND hDlg) WINE_TRACE("\n"); + loadWinmm(); + pAudioDrv = getAudioDrivers (); for (i = 0; *pAudioDrv->szName; i++, pAudioDrv++) { SendDlgItemMessage (hDlg, IDC_AUDIO_DRIVER, CB_ADDSTRING, @@ -272,6 +301,33 @@ AudioDlgProc (HWND hDlg, UINT uMsg, WPAR configureAudioDriver(hDlg, (char*)pAudioDrv[selected_driver].szDriver); } break; + case IDC_AUDIO_TEST: + { + WCHAR wave_file[MAX_PATH]; + WCHAR format[] = { '%','s','%','s',0 }; + WCHAR title[64]; + + LoadStringW(GetModuleHandle(NULL), IDS_AUDIO_FILE, wave_file, sizeof(wave_file)/sizeof(wave_file[0])); + LoadStringW(GetModuleHandle(NULL), IDS_WINECFG_TITLE, title, sizeof(title)/sizeof(title[0])); + + if (pPlaySoundW(wave_file, NULL, SND_FILENAME)) { + WCHAR done_msg[MAX_PATH + 64]; + WCHAR wave_done[64]; + + LoadStringW(GetModuleHandle(NULL), IDS_AUDIO_DONE, wave_done, sizeof(wave_done)/sizeof(wave_done[0])); + wsprintfW(done_msg, format, wave_done, wave_file); + MessageBoxW(NULL, done_msg, title, MB_OK); + pPlaySoundW(NULL, NULL, SND_FILENAME | SND_LOOP); + } else { + WCHAR error_msg[MAX_PATH + 64]; + WCHAR wave_error[64]; + + LoadStringW(GetModuleHandle(NULL), IDS_AUDIO_ERROR, wave_error, sizeof(wave_error)/sizeof(wave_error[0])); + wsprintfW(error_msg, format, wave_error, wave_file); + MessageBoxW(NULL, error_msg, title, MB_OK); + } + } + break; case IDC_AUDIO_CONTROL_PANEL: MessageBox(NULL, "Launching audio control panel not implemented yet!", "Fixme", MB_OK | MB_ICONERROR); break; @@ -305,6 +361,10 @@ AudioDlgProc (HWND hDlg, UINT uMsg, WPAR SetWindowLongPtr(hDlg, DWLP_MSGRESULT, FALSE); break; case PSN_APPLY: + /* unload the current sound driver */ + while (FreeLibrary(hWINMM)); + /* load the new driver */ + loadWinmm(); apply(); SetWindowLongPtr(hDlg, DWLP_MSGRESULT, PSNRET_NOERROR); break; Index: programs/winecfg/resource.h =================================================================== RCS file: /home/wine/wine/programs/winecfg/resource.h,v retrieving revision 1.33 diff -p -u -r1.33 resource.h --- programs/winecfg/resource.h 27 Oct 2005 11:24:02 -0000 1.33 +++ programs/winecfg/resource.h 12 Nov 2005 04:21:54 -0000 @@ -39,6 +39,9 @@ #define IDS_WINECFG_TITLE 13 #define IDS_THEMEFILE 14 #define IDS_THEMEFILE_SELECT 15 +#define IDS_AUDIO_FILE 16 +#define IDS_AUDIO_DONE 17 +#define IDS_AUDIO_ERROR 18 #define IDD_MAINDLG 101 #define IDB_WINE 104 #define IDD_ABOUTCFG 107 @@ -136,9 +139,10 @@ #define IDC_AUDIO_AUTODETECT 1300 #define IDC_AUDIO_DRIVER 1301 #define IDC_AUDIO_CONFIGURE 1302 -#define IDC_AUDIO_CONTROL_PANEL 1303 -#define IDC_DSOUND_HW_ACCEL 1304 -#define IDC_DSOUND_DRV_EMUL 1305 +#define IDC_AUDIO_TEST 1303 +#define IDC_AUDIO_CONTROL_PANEL 1304 +#define IDC_DSOUND_HW_ACCEL 1305 +#define IDC_DSOUND_DRV_EMUL 1306 /* appearance tab */ #define IDC_THEME_COLORCOMBO 1401
Robert Reif wrote:
This is a proof of concept patch that adds a simple audio test to winecfg. All it does is use PlaySound to play a wave file. I am using LoadLibrary("winmm.dll") and FreeLibrary to change drivers. You must press the apply button for the driver change to take effect. There is no error recovery for a missing winmm.dll. The wave file name is in the rc file so a different file can be played for each language. This is probably overkill. I'm not sure where to put the wave file so the program will only work when the wave file is in the current directory.
The wave file can be found here: http://home.earthlink.net/~reif/winecfg.en.wav or you can rename any old wave file to: winecfg.en.wav.
Comments please? 1/ why don't you store the wave in the resource file ? (PlaySound has the ability to play a sound from the resource file) 2/ in order to change drivers, one could also look at the installed drivers from winmm and setup the wave mapper to point to the desired one for playback. that would prevent from loading/unloading winmm for each driver change 3/ I'd also update the drivers' list with a status: - non present: the driver cannot be used in current system - available but not loaded: winecfg detected it as present, but winmm couldn't load it - loaded: winecfg detected it as present and winmm did load it.
A+ -- Eric Pouech
Eric Pouech wrote:
Robert Reif wrote:
This is a proof of concept patch that adds a simple audio test to winecfg. All it does is use PlaySound to play a wave file. I am using LoadLibrary("winmm.dll") and FreeLibrary to change drivers. You must press the apply button for the driver change to take effect. There is no error recovery for a missing winmm.dll. The wave file name is in the rc file so a different file can be played for each language. This is probably overkill. I'm not sure where to put the wave file so the program will only work when the wave file is in the current directory.
The wave file can be found here: http://home.earthlink.net/~reif/winecfg.en.wav or you can rename any old wave file to: winecfg.en.wav.
Comments please?
1/ why don't you store the wave in the resource file ? (PlaySound has the ability to play a sound from the resource file)
I considered that but the trick is to come up with a universal test sound that anyone would recognize as either playing properly or playing with some type of distortion (speed, noise, breakup, ...).
2/ in order to change drivers, one could also look at the installed drivers from winmm and setup the wave mapper to point to the desired one for playback. that would prevent from loading/unloading winmm for each driver change
That would require all available drivers to be loaded. By driver, I'm talking about ALSA, OSS, Jack, ..., not sound card one or two. Enumerating the available sound cards and testing them individually could also be added. I could unload the wine driver directly (winealsa.drv, wineoss.drv,...) and load the new one but I didn't know how robust that would be so I just let winmm.dll do all the work. I'll try unloading the drivers directly and see what happens.
3/ I'd also update the drivers' list with a status: - non present: the driver cannot be used in current system - available but not loaded: winecfg detected it as present, but winmm couldn't load it - loaded: winecfg detected it as present and winmm did load it.
ok
Robert Reif wrote:
Eric Pouech wrote:
Robert Reif wrote:
This is a proof of concept patch that adds a simple audio test to winecfg. All it does is use PlaySound to play a wave file. I am using LoadLibrary("winmm.dll") and FreeLibrary to change drivers. You must press the apply button for the driver change to take effect. There is no error recovery for a missing winmm.dll. The wave file name is in the rc file so a different file can be played for each language. This is probably overkill. I'm not sure where to put the wave file so the program will only work when the wave file is in the current directory.
The wave file can be found here: http://home.earthlink.net/~reif/winecfg.en.wav or you can rename any old wave file to: winecfg.en.wav.
Comments please?
1/ why don't you store the wave in the resource file ? (PlaySound has the ability to play a sound from the resource file)
I considered that but the trick is to come up with a universal test sound that anyone would recognize as either playing properly or playing with some type of distortion (speed, noise, breakup, ...). and ? I was refering to where storing the sound, or do you intend to let the user chooses the sound he/she wants to play ??
2/ in order to change drivers, one could also look at the installed drivers from winmm and setup the wave mapper to point to the desired one for playback. that would prevent from loading/unloading winmm for each driver change
That would require all available drivers to be loaded. By driver, I'm talking about ALSA, OSS, Jack, ..., not sound card one or two. Enumerating the available sound cards and testing them individually could also be added. I could unload the wine driver directly (winealsa.drv, wineoss.drv,...) and load the new one but I didn't know how robust that would be so I just let winmm.dll do all the work. I'll try unloading the drivers directly and see what happens.
I had more in mind something around: - get list of drivers likely to be loaded (as winecfg does) - make the registry key for those - load winmm with those settings - then use the mapper to move from driver to driver (yes, you'll have to deal with multiple audio channels on the same card) A+ -- Eric Pouech
On Sat, 12 Nov 2005 15:08:04 +0100, Robert Reif <reif(a)earthlink.net> wrote:
This is a proof of concept patch that adds a simple audio test to winecfg. All it does is use PlaySound to play a wave file. I am using LoadLibrary("winmm.dll") and FreeLibrary to change drivers. You must press the apply button for the driver change to take effect. There is no error recovery for a missing winmm.dll. The wave file name is in the rc file so a different file can be played for each language. This is probably overkill. I'm not sure where to put the wave file so the program will only work when the wave file is in the current directory.
The wave file can be found here: http://home.earthlink.net/~reif/winecfg.en.wav or you can rename any old wave file to: winecfg.en.wav.
Comments please?
why not use a simple musical wav , a couple of seconds and it's as good for all languages.
If this test is to allow the user to determine sound quality (or to check for errors) I would agree that a short musical sound would work better than one with just voices. You also will eliminate any need for multiple sounds based on language. The default KDE startup sound comes to mind as a possible choice. I believe that Gnome also has a short test sound that is a guitar being strummed. Either would work well. Or if you would like, I would be happy to record something for this purpose. Randall Walls wino(a)piments.com wrote:
On Sat, 12 Nov 2005 15:08:04 +0100, Robert Reif <reif(a)earthlink.net> wrote:
This is a proof of concept patch that adds a simple audio test to winecfg. All it does is use PlaySound to play a wave file. I am using LoadLibrary("winmm.dll") and FreeLibrary to change drivers. You must press the apply button for the driver change to take effect. There is no error recovery for a missing winmm.dll. The wave file name is in the rc file so a different file can be played for each language. This is probably overkill. I'm not sure where to put the wave file so the program will only work when the wave file is in the current directory.
The wave file can be found here: http://home.earthlink.net/~reif/winecfg.en.wav or you can rename any old wave file to: winecfg.en.wav.
Comments please?
why not use a simple musical wav , a couple of seconds and it's as good for all languages.
Randall Walls wrote:
If this test is to allow the user to determine sound quality (or to check for errors) I would agree that a short musical sound would work better than one with just voices. You also will eliminate any need for multiple sounds based on language.
The default KDE startup sound comes to mind as a possible choice. I believe that Gnome also has a short test sound that is a guitar being strummed. Either would work well. Or if you would like, I would be happy to record something for this purpose.
Randall Walls
Sure, something less than 10 seconds that would sound bad if played wrong would be great.
Molle Bestefich wrote:
Robert Reif wrote:
Sure, something less than 10 seconds that would sound bad if played wrong would be great.
How about white noise at maximum volume? That sounds bad when played wrong.
It also sounds bad when played right ;-) How would you know if an artificially produced sound effect were played back a the wrong sample rate or sample size if it sounds unnatural to begin with. Something like the guitar sound in the Red Hat sound card testing program would be ideal.
On Sun, 13 Nov 2005 03:59:04 +0100, Robert Reif <reif(a)earthlink.net> wrote:
Molle Bestefich wrote:
Robert Reif wrote:
Sure, something less than 10 seconds that would sound bad if played wrong would be great.
How about white noise at maximum volume? That sounds bad when played wrong.
It also sounds bad when played right ;-) How would you know if an artificially produced sound effect were played back a the wrong sample rate or sample size if it sounds unnatural to begin with. Something like the guitar sound in the Red Hat sound card testing program would be ideal.
I think it was a joke. However there is nothing unnatural about white noise there are many examples: waterfall, compressed air escaping, TV with the aerial pulled out (not so natural) , etc. I'm not sure this can or needs to be an effective test of the bit rate but a guitar snip (acoustic) sounds like a good choice.
Ask and ye shall receive. http://csr.slightofcode.com/wine/testsound1.wav Approx 15 sec long. This is just straight guitar, direct input. No effects, no EQ, no compression. Should be about as clean as you can get it. Randall Walls wino(a)piments.com wrote:
On Sun, 13 Nov 2005 03:59:04 +0100, Robert Reif <reif(a)earthlink.net> wrote:
Molle Bestefich wrote:
Robert Reif wrote:
Sure, something less than 10 seconds that would sound bad if played wrong would be great.
How about white noise at maximum volume? That sounds bad when played wrong.
It also sounds bad when played right ;-) How would you know if an artificially produced sound effect were played back a the wrong sample rate or sample size if it sounds unnatural to begin with. Something like the guitar sound in the Red Hat sound card testing program would be ideal.
I think it was a joke. However there is nothing unnatural about white noise there are many examples: waterfall, compressed air escaping, TV with the aerial pulled out (not so natural) , etc.
I'm not sure this can or needs to be an effective test of the bit rate but a guitar snip (acoustic) sounds like a good choice.
participants (5)
-
Eric Pouech -
Molle Bestefich -
Randall Walls -
Robert Reif -
wino＠piments.com