View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000485OpenMPTGeneralpublic2014-02-13 16:142014-02-14 21:06
ReporterLPChip Assigned Tomanx  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version7
Product VersionOpenMPT 1.22.07.* (old testing) 
Fixed in VersionOpenMPT 1.23.01.00 (upgrade first) 
Summary0000485: ASIO Device not stopping if hijacked
Description

If you select OpenMPT to keep the ASIO device open, and then you play sound through another device, such as XMPlay, the ASIO device gets hijacked. The other program then uses the sound and it all works without errors. OpenMPT however won't generate any sound anymore until the device is reopened. Closing XMPlay does free the device but does not make OpenMPT get the sound back. Once hijacked OpenMPT does not reinitialise the device.

In order to fix it, I have to open my settings, change the ASIO device to play on another channel mapping, hit apply and bam, I have audio again. Alternatively, I change another setting that allows me to hit apply, such as the playback frequency.

It is strange though, because I should be able to just set a different channel mapping and should be able to have 2 programs use ASIO at the same time.

This does work when I use EnergyXT 2.6 and XMPlay at the same time.

Then again, Regardless of what channel I use, EnergyXT and XMPlay both using ASIO always work.

Even stranger: I play in XMPlay first using ASIO to channel 3. Then I start playing in OpenMPT after I set ASIO there. XMPlay stops playing and OpenMPT works. I stop OpenMPT playback, XMPlay hijacks the soundcard again and OpenMPT is left with sound. The exact same happens if I test this using EnergyXT and OpenMPT.

So as far as I can tell, the problem is that OpenMPT tries to claim the ASIO device while it shouldn't need to do this.

Steps To Reproduce
  • Use another audio program that uses ASIO but does not use it exclusively, like EnergyXT or XMPlay.
  • Play something with it in a loop so you can test
  • Setup OpenMPT to use ASIO
  • Make sure the device is always open
  • If you hit play and the other program stops, its not working correctly.
TagsNo tags attached.
Has the bug occurred in previous versions?All, except when you don't check always keep open, its not as bad.
Tested code revision (in case you know it)

Activities

LPChip

LPChip

2014-02-13 16:22

manager   ~0001515

I just saw that there's a checkbox "Use device exclusively" but its grayed out. I think if you allow me to unckeck it, it would solve my problem.

I do think that not all ASIO devices can be used simultaniously though, but Creatives ASIO device can.
LPChip

LPChip

2014-02-13 16:47

manager   ~0001516

I've done a little bit of more research and it seems that Creative is one of the few who actually have ASIO in non-exclusive mode.
manx

manx

2014-02-13 16:55

administrator   ~0001517

Regarding the disabled but checked checkbox: This might have happend when converting old global sound device settings to per-device settings. This is just a GUI glitch and is now fixed as of r3709.
There is just no way to open an ASIO driver in exclusive mode (or non-exclusive mode for that matter). That's just not a parameter the ASIO API exposes in any way, so the option makes no sense for ASIO devices.
I'll later deal with the other parts of the bug report.
LPChip

LPChip

2014-02-13 18:52

manager   ~0001518

Last edited: 2014-02-13 18:53

It seems my problem happened because I had set OpenMPT to 48000 hz playback frequency, while the rest uses 44100 hz. When I set OpenMPT to this too, all works well. So for me this is solved.

Though that doesn't mean it works properly. OpenMPT just doesn't get priority at all nor does it display an error if it can't get access to the sounddevice when in use somewhere else.
manx

manx

2014-02-13 19:17

administrator   ~0001519

The way ASIO drivers behave in the case of multiple applications using the same ASIO driver or even using the device with some other API while another application is using ASIO, is totally driver specific, so I cannot really comment on what to expect from your particular driver in that case.
I can only guess how they implemented it, and the best guess here would be that the ASIO driver sends Reset/Resync/BufferSizechanged/LatenciesChanged messages to the host. OpenMPT currently does not handle any of those at all. In r3711, I added a warning in the statistics field in the soundcard settings that should show up when the driver sends those messages.
Can you try http://buildbot.openmpt.org/builds/auto/openmpt-win32/openmpt-win32-r3711.7z and check if a warning or a feature query appears there and tell us what features get used during normal operation and what after get used after the device got "hijacked". This will help me to determine which of those messages should be implemented in OpenMPT at a higher priority.
LPChip

LPChip

2014-02-14 00:52

manager   ~0001521

I've tried it out, and as far as OpenMPT concerned, there's just no audio, but OpenMPT doesn't seem to realise that stopped working.

As seeing works much better than reading, here's a short video presentation of what I experience: http://www.youtube.com/watch?v=BKnPWgJgR-c
LPChip

LPChip

2014-02-14 13:28

manager   ~0001522

Tried your new version and I have to say, it works perfectly.

OpenMPT is now exactly behaving like XMPlay and EnergyXT.

You may call this fixed, solved, completed, mission accomplished, etc. :D
manx

manx

2014-02-14 21:06

administrator   ~0001528

The has been committed as r3714 .

Issue History

Date Modified Username Field Change
2014-02-13 16:14 LPChip New Issue
2014-02-13 16:22 LPChip Note Added: 0001515
2014-02-13 16:23 LPChip Description Updated
2014-02-13 16:39 manx Assigned To => manx
2014-02-13 16:39 manx Status new => assigned
2014-02-13 16:47 LPChip Note Added: 0001516
2014-02-13 16:55 manx Note Added: 0001517
2014-02-13 18:52 LPChip Note Added: 0001518
2014-02-13 18:53 LPChip Note Edited: 0001518
2014-02-13 19:17 manx Note Added: 0001519
2014-02-14 00:52 LPChip Note Added: 0001521
2014-02-14 13:28 LPChip Note Added: 0001522
2014-02-14 21:06 manx Note Added: 0001528
2014-02-14 21:06 manx Status assigned => resolved
2014-02-14 21:06 manx Fixed in Version => OpenMPT 1.23.01.00 (upgrade first)
2014-02-14 21:06 manx Resolution open => fixed