[Bug 20664] New: spurious interaction between audio units or wave devices
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(a)winehq.org ReportedBy: hoehle(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20664 --- Comment #1 from Jörg Höhle <hoehle(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20664 Raymond <superquad.vortex2(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2(a)gmail.com --- Comment #2 from Raymond <superquad.vortex2(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20664 --- Comment #3 from Raymond <superquad.vortex2(a)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
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
you can hear both wav if you use wineesd.drv wintest.exe appear twice (12350:out0) and (12350:out1) in pavucontrol -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20664 Jörg Höhle <hoehle(a)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(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20664 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #5 from Austin English <austinenglish(a)gmail.com> 2011-03-07 12:53:06 CST --- Should be fixed by http://source.winehq.org/git/wine.git/?a=commitdiff;h=fc1e8e79c207a4eadc9832... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20664 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> 2011-03-18 14:39:22 CDT --- Closing bugs fixed in 1.3.16. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org