https://bugs.winehq.org/show_bug.cgi?id=52220
Bug ID: 52220 Summary: TMIDI Player, Cherry: Playback with multiple MIDI ports is broken Product: Wine Version: 7.0-rc1 Hardware: x86-64 URL: https://www.vector.co.jp/soft/dl/win95/art/se038910.ht ml OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winealsa.drv Assignee: wine-bugs@winehq.org Reporter: kakurasan@gmail.com Regression SHA1: 3d57cc2863f2f9a5ace40d29317b3ff4357fd119 Distribution: ---
Created attachment 71297 --> https://bugs.winehq.org/attachment.cgi?id=71297 Sample MIDI file that uses 2 MIDI ports
When the apps are configured to use multiple MIDI ports, playback is broken if the song (MIDI file) uses multiple MIDI ports.
Downloads: * TMIDI Player: https://www.vector.co.jp/soft/dl/win95/art/se038910.html * Cherry: https://www.vector.co.jp/soft/dl/win95/art/se071842.html
Steps to reproduce: 1. Install ja_JP.UTF-8 locale 2. Execute "winetricks fakejapanese_ipamona" for Japanese fonts 3. Download TMIDI Player 4. Install/run TMIDI Player on ja_JP.UTF-8 locale 5. Open menu item "オプション(O) - MIDI設定(M)" (or press Alt-o and Enter) and set MIDI Port A and B to valid and different MIDI ports 6. Open/play the attached MIDI file
This is a regression introduced by:
commit 3d57cc2863f2f9a5ace40d29317b3ff4357fd119 Author: Jacek Konieczny jajcus@jajcus.net Date: Wed Feb 12 12:53:54 2020 -0600
winealsa.drv: Send MIDI events to port subscribers.
This way changes to the port connections made by other applications will be honoured.
Signed-off-by: Jacek Konieczny jajcus@jajcus.net Signed-off-by: Andrew Eikum aeikum@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #1 from kakurasan@gmail.com --- Created attachment 71298 --> https://bugs.winehq.org/attachment.cgi?id=71298 Expected output
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #2 from kakurasan@gmail.com --- Created attachment 71299 --> https://bugs.winehq.org/attachment.cgi?id=71299 Actual output
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #3 from kakurasan@gmail.com --- Created attachment 71300 --> https://bugs.winehq.org/attachment.cgi?id=71300 Revert 3d57cc2863f2f9a5ace40d29317b3ff4357fd119
https://bugs.winehq.org/show_bug.cgi?id=52220
kakurasan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #4 from kakurasan@gmail.com --- https://source.winehq.org/patches/data/222222
https://bugs.winehq.org/show_bug.cgi?id=52220
Jacek Konieczny jajcus@jajcus.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jajcus@jajcus.net
--- Comment #5 from Jacek Konieczny jajcus@jajcus.net --- Here is a patch I made to fix the problem without removing the functionality introduced by my previous patch:
https://source.winehq.org/patches/data/222349
BTW I found an English version of TMIDI here: https://www.vogons.org/viewtopic.php?p=296645#p296645 A bit shady, but not much more shady than downloading some ancient software from sites where I don't understand a word. And it makes reproducing the bug and testing the patch much easier.
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #6 from kakurasan@gmail.com --- (In reply to Jacek Konieczny from comment #5)
Here is a patch I made to fix the problem without removing the functionality introduced by my previous patch:
Hello Jacek. Thank you for investigating the issue and providing the patch.
It works as expected but there are two issues when using Qsynth.
As a workaround, Qsynth users need to uncheck the "Auto Connect MIDI Inputs" checkbox in the "Setup" dialog.
Issue one: When it's checked, Wine often fails to open Qsynth's MIDI ports.
The behavior was introduced in:
commit 1875887000b368cc57f2953cf8d2c043369674c6 Author: Jacek Konieczny jajcus@jajcus.net Date: Wed Feb 12 12:53:25 2020 -0600
winealsa.drv: Allow external MIDI port connection changes.
That is generally the expected behaviour of any ALSA sequencer client.
Signed-off-by: Jacek Konieczny jajcus@jajcus.net Signed-off-by: Andrew Eikum aeikum@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
Issue two: When checked, even if Wine successfully opens all MIDI ports, the playback is still broken.
The point is, the problematic "Auto Connect MIDI Inputs" setting is enabled by default.
FluidSynth has the same setting too (fluidsynth -o midi.autoconnect=1 /path/to/soundfont) but it's not enabled by default.
The (libfluidsynth's) autoconnect feature uses the ALSA sequencer port subscription too and causes the behaviors.
Even if these are really expected behaviors, most Qsynth users may get confused by them.
What do you think?
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #7 from Jacek Konieczny jajcus@jajcus.net ---
It works as expected but there are two issues when using Qsynth.
Yes, i noticed those too. I think that the Qsynth default is a bit unreasonable, but there is something wrong in wine too.
As a workaround, Qsynth users need to uncheck the "Auto Connect MIDI Inputs" checkbox in the "Setup" dialog.
Yes, that improves things a bit.
Issue one: When it's checked, Wine often fails to open Qsynth's MIDI ports.
That is the weird one, that I have not really connected to the qsynth autoconnect feature. This is definitely a bug. Maybe wine is trying to get 'exclusive' access to the MIDI port, which does not really make sense on Linux ALSA (sequencer ports are supposed to be shared unless they use special flags to prevent that). I'll investigate that.
Issue two: When checked, even if Wine successfully opens
all MIDI ports, the playback is still broken.
That I would say is 'working as intended' – when you have multiple qsynths started each with 'auto-connect ports' then all wine MIDI outputs would be connected to all the synths running. There would be the same confusing behavior with a Linux MIDI player. This won't happen e.g. with multiple hardware synthesizers, as they would not connect automatically anywhere.
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #8 from Jacek Konieczny jajcus@jajcus.net --- Created attachment 71351 --> https://bugs.winehq.org/attachment.cgi?id=71351 a hack to stop qsynth auto-connecting to wine ports
This patch will prevent qsynth auto-connecting to wine ports, but is a hack and I am not convinced it should be included in wine.
This works but not setting SND_SEQ_PORT_TYPE_MIDI_GENERIC flag on the port. This does not seem to affect port functionality, but other applications would no longer consider it a MIDI output port they can use.
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #9 from Jacek Konieczny jajcus@jajcus.net --- And here is the revised main patch:
https://source.winehq.org/patches/data/222355
This should fix TMIDI failing to open MIDI ports when QSynth auto-connect is in use.
https://bugs.winehq.org/show_bug.cgi?id=52220
kakurasan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
--- Comment #10 from kakurasan@gmail.com --- The revised patch works as expected, except for "Qsynth/FluidSynth + autoconnect" case: * Non-FluidSynth devices: OK * Qsynth/FluidSynth without autoconnect: OK * Qsynth/FluidSynth with autoconnect: * Always able to open ports: OK * Broken playback: I'm still not sure whether it's really expected
That I would say is 'working as intended' – when you have multiple qsynths started each with 'auto-connect ports' then all wine MIDI outputs would be connected to all the synths running.
Is there a way to avoid this by modifying Wine...?
There would be the same confusing behavior with a Linux MIDI player.
"aplaymidi" command (in alsa-utils) works as expected even when libfluidsynth's autoconnect feature is in use. (e.g. "aplaymidi -p [Qsynth port 1]:0,[Qsynth port 2]:0 /path/to/file.mid")
snd_seq_ev_set_subs() isn't used in the program. ("aseqnet" and "arecordmidi" use it)
Regarding the SND_SEQ_PORT_TYPE_MIDI_GENERIC hack for Qsynth/FluidSynth: * It works as a workaround * The hack should not be applied by default (See comment #8) but may be useful for some Qsynth users
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #11 from Jacek Konieczny jajcus@jajcus.net ---
"aplaymidi" command (in alsa-utils) works as expected even when libfluidsynth's autoconnect feature is in use. (e.g. "aplaymidi -p [Qsynth port 1]:0,[Qsynth port 2]:0 /path/to/file.mid")
snd_seq_ev_set_subs() isn't used in the program. ("aseqnet" and "arecordmidi" use it)
Yes, I have seen that. Indeed aplaymidi does work the way wine worked before my original changes. This is not a problem for aplaymidi, as I cannot think of a scenario where people would really need this functionality. It is just a simple MIDI player and an example tool for ALSA library.
Setting event destination directly has its advantage, that the event will only reach the very specific port, but when someone uses wine to interact with a Windows program or analyze the MIDI traffic it generates this may become a disadvantage.
- Qsynth/FluidSynth with autoconnect:
- Always able to open ports: OK
- Broken playback: I'm still not sure whether it's really expected
It depends how we look at that:
if we consider Windows application MIDI outputs just generic MIDI outputs that can be connected to whatever one wants, no matter what is the Windows application choice – then it works as expected. Qsynth auto-connecting is just unfortunate use of this option.
if we consider Windows application output port choice final, then this might be, indeed unexpected.
Either way it is understandable – both ports are connected, as qsynth is configured to auto-connect. And that will be visible on any ALSA sequencer connection list/graph.
Is there a way to avoid this by modifying Wine...?
I am afraid the only way is to revert all my changes or make the connection changes optional by using a registry key or an environment variable (both options seem like a hack).
Reverting all the changes make it impossible to tap on Windows applications MIDI traffic (useful for reverse engineering Windows software for various MIDI hardware) or change the MIDI connections (useful to make better use of application that do not provide the MIDI connectivity configuration wanted).
In my opinion wine project goal is not to replicate Windows with all its limitations, but to allow easy use of Windows applications in Linux, to get best of the two worlds. I would rather keep the flexibility of Linux with some inconveniences in some rare use cases. But I can see your arguments too.
https://bugs.winehq.org/show_bug.cgi?id=52220
--- Comment #12 from kakurasan@gmail.com ---
Setting event destination directly has its advantage, that the event will only reach the very specific port, but when someone uses wine to interact with a Windows program or analyze the MIDI traffic it generates this may become a disadvantage.
Reverting all the changes make it impossible to tap on Windows applications MIDI traffic (useful for reverse engineering Windows software for various MIDI hardware) or change the MIDI connections (useful to make better use of application that do not provide the MIDI connectivity configuration wanted).
When I want to capture MIDI traffic from such apps (including older Wine), I usually use "snd-seq-dummy" module (Midi Through) or aseqview.
Wine --> snd-seq-dummy or aseqview snd-seq-dummy or aseqview --> MIDI device +--------------------------> arecordmidi or other native MIDI app
(Some Windows MIDI apps need to change MIDI mapper registry setting)
This is not easier to use than current Wine, but not impossible.
However, IMO, we don't have to revert to the old behavior: * When the "Auto Connect MIDI Inputs" checkbox is unchecked, it works as expected * Similar confusing behavior occurs in some native apps too (at least Rosegarden) * It's enough to make it known to Wine+Qsynth users: WineHQ Wiki, World Wine News, upcoming release note, etc.
https://bugs.winehq.org/show_bug.cgi?id=52220
kakurasan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |240f2f39632a08d81e8133dde20 | |b441d8378ed0f Resolution|--- |FIXED
--- Comment #13 from kakurasan@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commitdiff/240f2f39632a08d81e8133dde2...
https://bugs.winehq.org/show_bug.cgi?id=52220
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.0-rc4.
https://bugs.winehq.org/show_bug.cgi?id=52220
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6.0.x
https://bugs.winehq.org/show_bug.cgi?id=52220
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|6.0.x |---
--- Comment #15 from Michael Stefaniuc mstefani@winehq.org --- Removing the 6.0.x milestone from bug fixes included in 6.0.4.
-
WineHQ Bugzilla