Re: [hatari-devel] MIDI support for Windows & OSX (with PortMidi)

[ Thread Index | Date Index | More Archives ]


On 10/03/2017 11:57 PM, Simon Iten wrote:
does or how does portmidi change the way midi is presented to a usb-midi converter?

or in other words, why does portmidi on osx behave differently (“better” in my case) then linux with the standard none portmidi method?

PortMidi sends whole MIDI packages while the other one outputs the data byte-by-byte.

Which device drivers you use on Linux and which on OSX?

this is with the same atari software, same synth and same interface. driver issue on linux? (fastlane-usb motu, not fully class compliant)

Are you using the same version of Hatari?

You can build Hatari also on Linux with portmidi to compare, whether they still behave the same, i.e. is the issue in the OS / driver level.

	- Eero

On 3 Oct 2017, at 22:10, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

Le 03/10/2017 à 21:26, David Savinkoff a écrit :
----- Eero Tamminen wrote:
PS. Jari has also some questions about jitter he's seeing in MIDI output:
As a MIDI jitter testing experiment, try the following sound options:
--sound-buffer-size 10
--sound-sync true
These options affect emulation rate, and may improve the jitter.


I'm not sure this would help ; for midi output, you'd want as realtime possible behaviour, which I think is better achieved when emulation speed is not audio driven but using usleep in the main loop.
In that case if MFP expects a timer to last 1.39 sec for example under STF, then Hatari should take also exactly 1.39 sec.

Plus, MIDI programs don't necessarily use the YM2149 chip, so you would have no audio data to sync with (except playing empty audio buffers).

Put another way, I have more trust in usleep precision in that case than in syncing with an audio driver whose latency might vary depending on output sample rate or buffers size :)


Mail converted by MHonArc 2.6.19+