http://bugs.winehq.org/show_bug.cgi?id=20664
Summary: spurious interaction between audio units or wave devices Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net
Somehow, trying and accessing a wave device sometimes manages to stop another playing sample. Yet the second call is normally returned with 265=MCIERR_DEVICE_OPEN (mapped from 4=MMSYSERR_ALLOCATED).
To reproduce, you need audible sound.
Using my interactive MCI shell from bug #20232 comment #10, try the following
1. open long-playing-sample.wav alias a 2. open sample.wav alias b 3. play a from 0 4. play b from 0 wait
Repeat 4) playing b until a is interrupted (=you hear no more sound). If a ends normally repeat from step 3. Within less than 30 trials, a's sound will be interrupted on my single core Linux box, wither either ALSA or OSS, with or without PulseAudio in Ubuntu Intrepid.
When this happens, try 5. status a mode => "playing" 6. stop a => hangs 7. ^C
It seems more likely to happen after a has finished playing once. Or whatever Voodoo is needed.
http://bugs.winehq.org/show_bug.cgi?id=20664
--- Comment #1 from Jörg Höhle hoehle@users.sourceforge.net 2009-11-12 00:41:49 --- Created an attachment (id=24689) --> (http://bugs.winehq.org/attachment.cgi?id=24689) +wave,+mciwave,+driver log (700KB/37KB compressed)
Here's a log when this happened using OSS. Then I hit ^C
This bug is not Dan Kegel's Error in writing wavehdr. http://www.winehq.org/pipermail/wine-devel/2009-November/079717.html
http://bugs.winehq.org/show_bug.cgi?id=20664
Raymond superquad.vortex2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2@gmail.com
--- Comment #2 from Raymond superquad.vortex2@gmail.com 2010-09-26 23:32:04 CDT ---
trace:wave:OSS_WaveOutInit out wChannels = 6, dwFormats = 000FFFFF, dwSupport = 0000006C
trace:wave:OSS_OpenDevice (0x7e3e5164,1,(nil),0,-1,-1,ffffffff) trace:wave:OSS_WaveInInit (0x7e3e2120) /dev/dsp trace:wave:OSS_OpenDevice (0x7e3e2120,0,(nil),0,-1,-1,ffffffff) trace:wave:OSS_RawOpenDevice (0x7e3e2120,0) trace:wave:OSS_RawOpenDevice open_access=O_RDONLY trace:wave:OSS_WaveInInit /dev/mixer: trace:wave:OSS_Info Formats=0004b1f9 ( AFMT_MU_LAW AFMT_U8 AFMT_S16_LE AFMT_S16_BE AFMT_S8 AFMT_U16_LE AFMT_U16_BE ) trace:wave:OSS_Info Caps=00003201 trace:wave:OSS_Info Revision: 1 trace:wave:OSS_Info Duplex: false trace:wave:OSS_Info Realtime: true trace:wave:OSS_Info Batch: false trace:wave:OSS_Info Coproc: false trace:wave:OSS_Info Trigger: true trace:wave:OSS_Info Mmap: true trace:wave:OSS_Info Multi: false trace:wave:OSS_Info Bind: false
trace:wave:OSS_WaveInInit in wChannels = 6, dwFormats = 000FFFFF, in_caps_support = 00000020 trace:wave:OSS_WaveInInit (0x7e3e2574) /dev/dsp1 trace:wave:OSS_OpenDevice (0x7e3e2574,0,(nil),0,-1,-1,ffffffff) trace:wave:OSS_WaveInInit (0x7e3e29c8) /dev/dsp2 trace:wave:OSS_OpenDevice (0x7e3e29c8,0,(nil),0,-1,-1,ffffffff) trace:wave:OSS_WaveInInit (0x7e3e2e1c) /dev/dsp3 trace:wave:OSS_OpenDevice (0x7e3e2e1c,0,(nil),0,-1,-1,ffffffff) trace:wave:OSS_WaveInInit (0x7e3e3270) /dev/dsp4 trace:wave:OSS_OpenDevice (0x7e3e3270,0,(nil),0,-1,-1,ffffffff) trace:wave:OSS_WaveInInit (0x7e3e36c4) /dev/dsp5 trace:wave:OSS_OpenDevice (0x7e3e36c4,0,(nil),0,-1,-1,ffffffff) trace:wave:OSS_WaveFullDuplexInit (0x7e3e3b20) /dev/dsp trace:wave:OSS_OpenDevice (0x7e3e3b20,2,(nil),0,-1,-1,ffffffff) trace:wave:OSS_RawOpenDevice (0x7e3e3b20,0) trace:wave:OSS_RawOpenDevice open_access=O_RDWR trace:wave:OSS_WaveFullDuplexInit Analog Devices AD1981B
Are you using OSS v4 or ALSA OSS emulation ?
since I don't hink your ad1981B support 6 channels capture if you are using ALSA OSS emulation
http://bugs.winehq.org/show_bug.cgi?id=20664
--- Comment #3 from Raymond superquad.vortex2@gmail.com 2010-11-15 20:11:35 CST --- (In reply to comment #0)
Somehow, trying and accessing a wave device sometimes manages to stop another playing sample. Yet the second call is normally returned with 265=MCIERR_DEVICE_OPEN (mapped from 4=MMSYSERR_ALLOCATED).
To reproduce, you need audible sound.
Using my interactive MCI shell from bug #20232 comment #10, try the following
- open long-playing-sample.wav alias a
- open sample.wav alias b
- play a from 0
- play b from 0 wait
you can hear both wav if you use wineesd.drv
wintest.exe appear twice (12350:out0) and (12350:out1) in pavucontrol
http://bugs.winehq.org/show_bug.cgi?id=20664
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|spurious interaction |the MCI devices badly |between audio units or wave |re-enter the player loop. |devices |
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2011-03-05 09:42:04 CST --- It turned out that this is a bug in mciwave after all. Since 2000-01-09 the way to start an async thread that enters mciPlay|Record recursively has been broken, allowing WAVE_mciPlay|Record to stomp over an already playing loop, breaking havoc with the device.
I've prepared an interim patch, pending my current rewrite of the player thread invocation mechanism first in mciseq (to fix bug #22978). Other MCI drivers may follow later.
http://bugs.winehq.org/show_bug.cgi?id=20664
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #5 from Austin English austinenglish@gmail.com 2011-03-07 12:53:06 CST --- Should be fixed by http://source.winehq.org/git/wine.git/?a=commitdiff;h=fc1e8e79c207a4eadc9832...
http://bugs.winehq.org/show_bug.cgi?id=20664
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2011-03-18 14:39:22 CDT --- Closing bugs fixed in 1.3.16.
-
wine-bugs＠winehq.org